There was a time when Nixpkgs was smaller than the AUR. And, until recently, Nixpkgs was larger than the AUR but still smaller than the combination of the main Arch repos with the AUR.
As it turns out, the current total package count for Arch and the AUR is 85,819.
For nixpkgs unstable, that number is 88,768.
NixOS 23.05 Stable has 83,740.
And considering the mention of 9,147 new packages and 4,015 removed packages, that would mean that 23.11 would have a total of:
88,872 packages. This is more than the current figures for Nixpkgs unstable, but this is going off data from separate sources (NixOS devs and repology, with repology still being slightly outdated)
And, as such, I think it’s fair to say the winner is (drumroll please)…
The USER for having such incredible distributions, giving him the vast breadth of choice for what distro matches their workflow best.
To be fair, the level of support for packages in nixpkgs is inconsistent. My config has a number of backported packages overlaid on top of nixpkgs where upstream is not up to date enough for me.
Package count is interesting to look at, but it doesn’t really give a good picture of software availability. Distributions will split or combine packages differently. For example, the AUR has both binaries and source versions available for many packages.
For fun and learning. It’s just another tool to go with file level backup.
And the backup for this is 40mb and really fast, but backing up files even when compressed would be hundreds of GB, maybe terabytes, and then you’re paying for that amount of storage online somewhere, uploading for hours…
Picture this: you open and edit one of your documents and save it.
The filesystem promptly allocates some blocks and updates the inodes. Maybe the inode table changed, maybe not. Repeat for some other files. Now your “inode backup” has a completely different picture of what is going on on your disk. If you try to recover the disk using it, all you will achieve is further corruption of the filesystem.
For example once I had a bad cable, and it did a kinda sneaking silent damage. Let’s say 5 or 50 broken files every day. And only after some weeks I noticed some of them, and there was hardly a chance to identify them each day. And sometimes there was damage to the file system, too. It took a while find the root cause.
Today I use ZFS with redundancy and it does the recovery all by itself and my sleep is so much better :-)
“Proper backups” imply that you have multiple backups and a backup strategy. That could mean, for instance, that you would do a full backup, then an incremental/differential backup each week and keep one backup for each month. A bad cable would cause you trouble, no doubt, but the impact would be lessened by having multiple backups points spread over months.
Redundancy is not backup. Read that again.
Redundancy is important for system resilience, but backup is crucial for continuity. Every filesystem is subject to bugs and ZFS is not special. Here’s an article from a couple of days ago. If you’re comfortable with no backups just because you have redundancy, more power to you. I wouldn’t be.
Sure, all the work you do between the moment of the filesystem failure and the last backup is gone. There’s nothing that can be done to mitigate that fact, other that more frequent backups and/or a synchronized (mirror) system.
Backups are just a simple way to keep you from having to explain to your partner that you lost all the pictures and videos you took along the years.
Many modern laptops no longer support S3 sleep at all. It is likely to be an issue with the bios rather than a linux project. On my laptop, with Ryzen 7 5825U, I had to give up on S3 and use s2idle. Also had to pass "pcie_aspm=off" as a kernel parameter because it would take ages to wake the ssd without it. Overall works ok. Not as good as S3 but better than nothing.
So to check what suspend states your laptop supports run cat /sys/power/mem_sleep. It should print something like s2idle shallow [deep] with the option that is enabled having [] around it. To change the enabled option run echo "s2idle" > /sys/power/mem_sleep. https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate has more info.
I haven't really noticed much of a difference. I figured it was probably worth actually being able to wake the laptop from sleep rather than having to restart it every time.
First, it is generally a bad idea to manually install software in package based distro. It can break something in your system (providing install.sh script is quite uncommon, it means that developers can do something uncommon and unexpected). Even if everything will go fine, once after system update the program you installed will get broken dependencies and stop working. Better search for prebuilt RPM package.
Then, answering your question: to build against libraries you need to install corresponding -devel packages. In Fedora their names can differ from the library name (e. g. not libglvnd-devel, but glvnd-devel, you need to search them yourself). For wayland-scanner you need wayland-devel as you can find here or with command dnf provides ‘*/wayland-scanner’.
As far as I’m aware the only options to install GSR as a package are AUR/yay (not available on fedora as far as I understand) or flatpak (unable to resolve permission issue), so I do think a manual install is the best option. This is a gaming system so GSR breaking is no huge deal.
Thanks for the tips regarding manual installation! I did not know about -devel packages or about the dnf provides command. They will probably prove to be very useful!
If you’re going to install from source at least change the compile config options so the prefix defaults to /opt/program-name.
You can further integrate with the system by adding the /opt/program/bin/ and sbin/ dirs to the PATH variable, and add lib/ to /etc/ld.so.conf but it should not be needed normally — only if other programs need to compile against this one.
You can also simplify integration by making common dirs for example /opt/.bin and /opt/.lib, adding only those to PATH and ld, and symlinking binaries and libraries from all /opt programs to them.
I’m new to NixOS. Do I have to do anything extra to update NixOS? Or do I just update my flake and run nixos-rebuild switch --flake like I normally do to update packages?
If using flakes you could just for instance add another input. You can also set the input URLs to specific states of the nixpkgs repository by eg referencing specific commits. Then, you should be able to just, e.g., pick Firefox from unstable, another package from the current stable channel, and maybe a broken package from a pull request fixing said package.
If you are not using flakes you can also add system wide channels. IIRC you can then import these channels into your configuration.nix and select packages from the corresponding channels. But here the channels/inputs are not part of configuration itself in contrast to when using flakes.
When not using flakes, nixos-rebuild switch --upgrade is equivalent to apt update; apt upgrade. The equivalent to dist-upgrade is nix-channel add $NEW-CHANNEL-URL nixos and then performing a regular update.
I’m a bit confused about what you actually want? Do you just want to update your packages, but stay on the same NixOS version? Just continue like before. Do you want to stay on your current version, but use some packages from the next version? That should also be possible if you somehow include that channel in your configuration.nix (though I don’t know how this would work in practice).
Personally, I just run with unstable though, then the releases aren’t that important.
I think unstable and the fixed versions use the same Firefox package, so you wouldn’t gain anything. The difference is rather in libraries that get used and how the distribution does things. For example, the changes listed in nixos.org/manual/nixos/stable/release-notes#sec-r… just appeared mostly one by one for me; one day, I wanted to update my system and got the error that the fonts option got renamed, so I had to change my configuration.
The fonts.fonts and fonts.enableDefaultFonts options have been renamed to fonts.packages and fonts.enableDefaultPackages respectively.
While when using a fixed point release, these changes won’t happen. Only when you switch releases. That’s what “unstable” refers to.
You need to update your inputs so that you’re using the 23.11 branch of nixpkgs instead of the old one. In my experience, a couple of things will break, but there’s usually warnings about it.
If you are using flakes you should check your flakes’ inputs (probably the one called nixpkgs) and then change the URL to match the channel for 23.11. Finally, you should of course rebuild your system.
I’m rocking two dailys right now. Tumbleweed and Nixos. I jabe tumbleweed on my work laptop as well as one laptop at home. Rock solid go to that I trust for all the things. I started using nix on a number of other machines at home a few months back, and I’m really really enjoying it!!
Early 2000’s I took a class in highschool called “What’s in the box”. A buddy of mine and I would hangout after school just talking and building computers. He showed me Lindows. I specifically remember looking at the clock in the dock, and thinking… “Wow!!! Look how you can customize the clock so much!”
It stuck with me. Shortly there after I dabbled with Suse. Then moved to Ubuntu. By 2005 I was almost exclusively using Linux on all my machine. Had one machine running windows for gaming, but the other machines I had were all Linux.
Personally I’m not a fan of dual booting. Admittedly it’s been many years since I have evn tried (now that virtualization is what it is), but when I did, grub would always break on me. It just wasn’t worth the hassle. Now to think of having to reboot to switch just makes me cringe. Lol
Yeah, it’s a terrible thing that you have to do this to get your city into the weather app, but I simply love the fact that you can do that, whereas on some proprietary system, you might wait months for the fix.
KDE is very receptive to community help! I can only think of one specific example in KDE history where a developer dragged their feet in the mud about a change the community wanted/submitted pull requests for, and thats the vertical HTML indicator bar in kmail.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.