The problem here is it is not a unit of length or a unit of area. It is a count. If you have a grid of 10 gummy bears by 10 gummy bears you have 100 gummy bears. Not 100 gummy bears^2. A pixel is a desecrate thing, not a continuous value like meters are and it is not used to measure area. For that you need to know the length and spacing of a pixel.
I would not worry about virtual memory usage. Virtual memory can include memory mapped files and does not indicate actual ram usage - only the address space that the program has opened at some point. There is little point in worrying about it.
IMO the best thing is to just start using it. You will start to pick things up fairly quickly then. Puzzles don’t often ingrain different ways todo things and often focus on weird or niche things that don’t come up as often. They can be a nice supplement to not a substitute for just using it in real world usescases.
I do also find it helpful to read the shortcut keys on their site to get a feel for what is available. You won’t remember everything but it can be useful to know what is possible. Then when you hit a problem you may remember reading about something that can help and go look it up again.
Of course it is opt in. Why would it not be? Microsoft have opted in automatically on your behalf. Soon you will only be able to opt in, for your convenience, as too many people were accidentally opting out. /s
That’s what happens when you make it expensive to import anything and don’t have any domestic manufacturing for computer components.
If it is working then there is no need for a reinstall. If you cannot live without it for a day then you might want to not mess with it.
At the same time this is Arch so you can create a new partition and install from your current system into that. And only switch over when you are happy with it. It can be useful to go through the install process occasionally to ensure you can still set it up if something ever does happen to your system. Or to ensure you are configuring things with the latest recommended settings and packages.
But there is no need to wipe your current system to go through that process.
Just dont format the drive when installing a new distro. BTRFS or not you can delete the system folders manually first if needed but I believe that some if not all distros will delete the system folders for you (at least ubuntu used to do this last I tried). And if not you can do it manually.
It does not matter if you have a separate partition or not for /home installers won’t touch it if it already exists except to create a new user if needed. Remember, all the installers do is optionally format the drives, mount them then install files into those drives. If you skip the formatting and manually do that partitioning (or using an existing partition layout) it will still mount and write to the same places regardless of it they are separate partitions or not. So a separate partition does not add any extra protection to your home files at all.
But regardless of what you do you should ALWAYS backup your home data anyway. Even with separate partitions or subvolumes the installer can touch or delete anything it wants to and you can easily click the wrong button or accidentally wipe thing. At most preserving your home saves you from restoring from a backup it should not be done instead of backup.
The readme for smol has an example for stdout. I assume stdin is the same:
let mut stdout = Unblock::new(std::io::stdout());
io::copy(stream, &mut stdout).await?;
And there is more information about how to use it for reading/writing on the Unblock docs.
By far the most important thing is consistency
This is not true. The most important thing is correctness. The code should do what you expect/want it to do. This is followed closely by maintainability. The code should be easy to read and modify. These are the two most important aspects and I believe all other rules or methodologies out there are in service of these two things. Normally the maintainability side of things as correctness is not that hard to achieve with any system of rules out there.
You must resist the urge to make your little corner of the code base nicer than the rest of it.
Uhg. I really don’t like these words. I agree with their sentiment, to a degree, but they make it sound like you should not try to improve anything at all. Just leave it as it is and write your new code in the same old crappy way that it always has been. Which is terrible advice. But I get what they are trying to say - you should not jump into a area swinging a wrecking ball around trying to make the code as locally nice as possible at the expense of the rest of the code base and other developmental practices around.
In reality there is a middle ground. You should strive to make your corner of the code base as nice as possible but you should also take into account the rest of the code base and current practices as well. Sometimes having a little bit better local maintainability is not worth the cost of making the code base as a whole less maintainable. Sometimes a big improvement to local maintainability is worth a minor inconvenience to the code base as a whole - especially for fast moving parts of the code base. You don’t want something that no one has touched in 10 years to drastically slow down current features you are working on just to keep things consistent.
Yes consistency is important. But things are far more nuanced than that statement alone. You should strive for consistency of a code base - it does after all have a big effect on the maintainability of the code base. But there are times that it hampers maintainability as well. And in those situations always go for maintainability over consistency.
Say for instance some new library or an update to a library introduces a new much better way of working. Your code base is full of the old way though. Should you stick to the old way just to keep up with consistency? If the improvement is good enough then it might be worthwhile. Ideally if you can you would go though and update the whole code base to the new way of working. That way you improve things overall and keep consistency of the code base. But that is not always practical to do. It might be better to decide that the new way is worth switching to for new code, and worth refactoring old code when you are working in that area anyway but not worth the effort of converting the whole code base at once. This makes maintainability of the new code better, at the expense of old less used code.
But the new way might not be a big enough jump in maintainability of new code that it is worth sacrificing the maintainability of the code base as a whole. Every situation like this needs to be discussed with your team and you need to decide on what makes most sense for your project. But the answer is not always that consistency is the most important aspect. Even if it is an important aspect.
Consistency as a means to correctness still means correctness is the more important aspect. Far too many projects and people that go hard on some methodologies and practices lose sight of their main goal and start focusing on the methods instead. Even to the point were the methods are no longer working toward the goal they originally set out to accomplish.
Always have the goal in mind, once your practices start to interfere with that goal then it is time to rethink them.
There is no problem with having home on a different disk. But why do you want swap on the slower disk? These would benefit from being on the faster disks. Same with all the system binaries.
Personally I would put as much as possible on the faster disk and mount the slower somewhere that the speed matters less. Like for photos/videos in your home dir.
/boot can be anywhere though if you are getting a grub error that suggests the UEFI firmware is finding grubs first stage but grub is having issues after that. Personally I don’t use grub anymore, systemd-boot is far simpler as it does not need to deal with legacy MBR booting.
Most packages managers can run arbitrary code on install or upgrade or removal. You are trusting the code you choose to run on your system no matter where you get it from. Remember the old bug in ubuntu that ran a rm -rf / usr/.. instead of rm -rf /usr/... and wiped a load of peoples systems?
Flatpacks, Apparmor and snaps are better in this reguard as they are somewhat more sandboxed and can restrict what the applications have access to.
But really if the install script is from the authors of the package then it should be just as trustworthy as the package. But generally I download and read the install scripts as there is no standard they are following and I don’t want them touching random system files in ways I am not aware of or cannot undo easily. Sometimes they are just detecting the OS and picking relevant packages to install - maybe with some thrid party repos. Other times they mess with your home partition and do a bunch of stuff including messing with bashrc files to add things to your PATH which I don’t like. I would never run a install script that is not from the author of the application though and be very wary of install scripts from a smaller package with fewer users.
What you have listed is a good start. https://www.rust-lang.org/learn has additional resources as well once you have gotten through those.
Also if you are looking for a replacement for find that is not a full tui then take a look at fd which works more like what the author expected from the find commad - fd <pattern>.
My point is the different levels of just working are subjective, not objective. I personally have spent far more time fixing bugs or just reinstalling ubuntu systems then I have over the same period for Arch systems. So many of my ubuntu installs just ended up breaking after a while where I have had the same Arch install on systems for 5+ years now. Could never get a Ubuntu system to last more then a year.
Everyone has different stories about the different OSs. It is all subjective.
You can cherry-pick examples of problems from every OS. That is my point. They all have issues that you may or may not encounter and quite a few that would make people from other OSs scratch their head and think what the hell the devs are thinking. Pointing out one issue of one OS does not change any of that.
Which is proven by the other replys to your comment - others dont find this issue to be as show stopping as you do and just live with it or dont use it at all. How many issues do you do the same for on your favorite OS?
There is no perfect OS that just works for everyone. They are all software so they all have bugs. People how say an OS just works have never hit those bugs or have gotten used to fixing/working around or flat out ignoring them.
This is true of all OSs, including Windows, Linux and MacOS. They are all differently buggy messes.
Linux is the buggy mess that works best for me though.
Once had a missing semi colon at the end of a c header file. The compiler kept complaining about the c file and never mentioned the header. Not all errors lead you to the right place.
Though most of the time people just don’t read them. The number of problems I have solve for people by just copy pasting the error they gave me back to them…
Just because your bowser is not caching does not mean something else between you and the server is not caching as well.
In a way that seems to be what the paper is showing evidence for. Basically they looked at what happens if you disable the optimizations the LLVM compiler does when it knows something is undefined (and thus should not appear in a well written program). And they claim to have found minimal performance regressions of which can largely be mitigated in other ways.
And that has been the biggest argument for having UB in C/C++ - to let the compilers optimize things in ways that you cannot do if everything was well defined. This might have been true in the past when we had a lot more variation in CPU designs but this paper seems to conclude that is no longer the case. Thus raises the question as to why do we need so much UB in C/C++ any more if performance is not a bit issue for modern programs using modern CPUs.