• 10 Posts
  • 400 Comments
Joined 2 years ago
cake
Cake day: June 10th, 2023

help-circle
  • As an actual M1+Asahi user and a gamer: Asahi is not there yet. Right now, if you’re on macOS, Crossover (or Porting Kit) and/or Parallels is able to run more games and with better performance compared to Asahi (using krun + FEX). Also, Steam on macOS (non-native) is much more peformant compared to Asahi, where it’s currently slow and glitchy.

    But that will all change in the future once the Vulkan driver and TSO patches are ready. FEX is also seeing a lot of improvements, so by the end of the year, there’s a good chance that gaming on Asahi would be much better than macOS.




  • Multiple times a day, basically whenever I’m bored. Sometimes I get so depressed when there are no updates, that I install some random package or build something from source, so I can look at some text flying across my terminal, and look at all the cool stuff happening on my PC. I also have a journalct -f and btop running all the time as it’s interesting to see what’s happening behind the scenes.


  • So basically:

    1. Update your system, don’t reboot yet
    2. mkinitcpio.conf --> make sure you have microcode after the autodetect in the HOOKS line
    3. /etc/mkinitcpio.d/<kernel>.preset --> remove the line ALL_microcode=(/boot/*-ucode.img)
    4. systemd-boot users: arch.conf --> remove or comment out the initrd /amd-ucode.img (or intel-ucode.img) line
    5. Run sudo mkinitcpio -p <kernel> to generate your new initrd, and then reboot

    Optional: run grep microcode /proc/cpuinfo before and after the reboot to verify that your microcode version hasn’t changed after the reboot - which means that the new microcode loading method is working correctly.

    On a tangential note, the above is a perfect example of why I don’t recommend Arch (and so-called “easy” derivatives like EndeavourOS) for newbies (ie people who don’t RTFM / keep up with Arch news / inspect their .pacnew files etc). Feel free to link this post in your future internet arguments. :)



  • matching other programs and platforms

    Actually, Ctrl+C is the interrupt hotkey for pretty much every CLI app/terminal on every platform. Try it within the Command Prompt/PowerShell/Windows Terminal, or the macOS terminal - they’ll all behave the same.

    The use of Ctrl+C as an interrupt/termination signal has a very long history even predating the old UNIX days and DEC - it goes back to the days of early telecommunications, where control characters were used for controlling the follow of data through telecommunication lines. These control characters, along with regular characters, were transmitted by being encoded in binary, and this encoding scheme was defined by ASCII (American Stanard Code for Information Interchange), published in 1963.

    In ASCII, the control character ETX (meaning end-of-text; represented by the hex code 0x03) was used to indicate “this segment of input is over”, or “stop the current processing”.

    Now what does all this have to do with with Ctrl+C you ask?

    For that, you’ll need to go back to the days of early keyboards. Keyboards back then generated ASCII codes directly, and when a modifier key (Ctrl/Shift/Meta) on a keyboard was pressed in combination with another key, it modified the signal sent by the keyboard to produce a control character.

    Specifically, pressing Ctrl with a letter key made the keyboard clear (set to zero) the upper three bits of the binary code of the letter, thus effectively mapping the letter keys to control characters (0x00 - 0x1F: the first 32 characters on the ASCII table).

    • The ASCII code for ‘C’ is 0x43 (binary 01000011).
    • Pressing Ctrl+C clears the upper three bits, resulting in 00000011, which is 0x03 in hex.

    And would you look at that, 0x03 is the code which represents the control character ETX.

    The use of ETX to interrupt a program in digital computers was first adopted by the TOPS-10 OS, which ran on DEC’s PDP-10 computer, back in the late 60s. It’s successor, TOPS-20 also included it, followed by the RSX-11 (on the PDP-11), and VMS (on the VAX-11).

    RSX-11 was a very influential OS, created by a team that included David Cutler. It influenced the design of several OSes that followed, such as VMS and Windows NT. Cutler later moved to Microsoft and became the father of Windows NT. Early NT did not include a GUI, so it was natural to adopt existing terminal operation standards, including the use of ETX. In fact, NT’s internals were so similar to VMS that a lawsuit was in the works, but instead, MS agreed to pay off DEC millions of $$$.

    Also, when UNIX first came out (1969), it ran on DEC hardware, and so they followed the tradition of using the ETX signal to stop programs. This convention flowed to BSD (1978) which was based on UNIX, and NeXTSTEP (1989), which was based on BSD. NeXTSTEP was developed by NeXT Computers, which was founded by Steve Jobs… and the rest is history.

    Therefore, Ctrl+C is something that’s deeply rooted in history. You don’t just simply change something like that. Sure, you may be able to remap the keybindings, but it’s actually hardcoded into many programs so you’ll run into inconsistencies - that is, if you used the standard remapping tools built into GNOME/KDE etc.

    If you want to truly remap Ctrl+C, you’ll want to do so at a lower level (evdev layer) so that it’s not intercepted by other programs, eg using tools like evremap or keyd. But even then, it’s not guaranteed to work everywhere, for instance, if you’re inside a VM or using a different OS, or in a remote session. So it’s best to remap the keys at the keyboard layer itself, which is possible on many popular mechanical keyboards using customisable firmware like QMK/VIA.




  • This isn’t exactly true. My guess is your app profiles are either bloated, and/or your measuring your RAM usage incorrectly/unfairly.

    On my M1 MBA for instance, a fresh profile of LibreWolf (+ child processes) uses 514 MB. Compare this with a closed-source browser like Opera (fresh profile) which takes up a massive 1183 MB. Vivaldi uses a but lesser RAM compared to LW, but it’s still a comparable amount (486 MB), whereas the new and fancy Arc browser uses 587.3 MB.

    Now, LibreOffice on the other hand does take up more RAM than MS Office by default - 475.4 MB - but it works a bit differently to MSO, because LO uses a single binary for all office applications, unlike MSO where each office application is it’s own app. But if I were to open a blank Word, Excel and PowerPoint documents, and a blank LO Writer, Calc, Impress documents, they use approximately the same amount of RAM in total (~750 MB).



  • Parent comment is wrong. The default UX used in Ubuntu may actually be confusing for newbies, as it’s quite different compared to Windows. Just check some screenshots or videos and you can see for yourself. I’d instead recommend going for a distro which uses a more familiar UX (ie the Desktop Environment).

    Perhaps a distro which uses KDE, XFCE, Cinnamon, MATE or LXQt by default (these are “desktop environments” (DE) - which is a collection of the desktop shell components (eg start menu, taskbar, dock etc) plus default applications that go with it eg the file manager, document viewer etc). A desktop environment like the ones I mentioned above, in their default settings, should be familiar to most Windows users. Now whilst you can install any DE on any distro, it can be a daunting task for newbies, plus, the settings might not be optimal for you. So it’s better to go with a distro that comes with such easy-to-use DEs by default. Examples of such distros include Linux Mint and Zorin. These, by default, should look quite familiar to you, and should be even more easier to use than Ubuntu.

    Both Mint and Zorin are based on Ubuntu, so most of the documentation for Ubuntu should be relevant to Mint and Zorin as well. But if you’re not sure, just include quotes for your distro when you’re doing a web search, eg how do I do this in Linux "Mint" will ensure you’ll only get results with “Mint” in the page.











  • Yes, you can indeed install them in Windows as well. sfreerdp is the main server binary, and wfreerdp is the main client.

    Here’s a full explanation of what each file does:

    1. freerdp-proxy.exe: This executable is a proxy server for RDP sessions. It’s used to forward, or ‘proxy’, RDP traffic between a client and a server. This can be useful for security, auditing, or network architectural reasons.

    2. sdl-freerdp.exe: This binary is a version of the FreeRDP client that uses the Simple DirectMedia Layer (SDL) for its graphical output. SDL is a cross-platform development library designed to provide low-level access to audio, keyboard, mouse, joystick, and graphics hardware. This makes sdl-freerdp.exe useful for systems where a lightweight or more compatible graphical output method is needed.

    3. sfreerdp-server.exe: This is the server component of the FreeRDP project. It allows a Windows machine to act as an RDP server, accepting connections from RDP clients. This can be particularly useful for testing or for setting up remote desktop services on systems where a full-fledged RDP server isn’t available or desired.

    4. wfreerdp.exe: This executable is the standard FreeRDP client for Windows. It’s used to connect to RDP servers from a Windows machine. It provides a wide range of features and options typical of RDP clients, such as support for different color depths, audio redirection, and file system redirection.

    5. winpr-hash.exe: This tool is part of the Windows Portable Runtime (WinPR) library, which is a part of FreeRDP. It’s used to create a NTLM hash from a username and password pair. The created hash can be outputed as plain hash or in SAM format.

    6. winpr-makecert.exe: Also part of WinPR, this executable is used to create certificates. Certificates are crucial in secure communications, such as those used in RDP sessions. They are used to establish trust and encrypt data. This tool can be used to generate certificates for testing or for specific secure communication requirements within the RDP framework.