It’s basically the same time I started using Linux somewhat more. I didn’t go Windows-free until 2007 though and then returned to Windows because I needed it for something with my Master’s thesis. I kind of shudder at the thought how my old setups looked under the hood. You learn a lot in 18 years… Probably copy-pasted a lot of shell commands back then. But UT2k4 in its OpenGL glory was worth it
Most interesting development. This is obviously still into the future but I also always had the impression that Redhat did a lot of work on the XOrg server. With this I think it’s actually dead once they no longer support RHEL 9 and older.
I won’t miss it, granted it’s not a bad implementation, but the design is showing its age. Apart from Wayland that I use, I’m also looking at Arcan’s progress from time to time. Obviously rather niche at the moment but projects like these make the ecosystem interesting.
Really looking forward to this release! Good stuff, another (minor) possible improvement for wine would be native pipewire support. But this is definitely more interesting
Simplified, there’s two layers to data protection, physical and logical. Linux or basically any correctly configured modern operating system provides logical protection, i.e. access under the running OS is only granted to authorized users. Granted you can still put holes in here, e.g. a webserver is misconfigured and allows access to any user to all files it can read. However, from the OS perspective, everything is fine, as the webserver can still only read what it’s allowed to.
Data encryption protects data at rest, i.e. when no operating system enforcing the logical protection is running. The case has already been described so I’m not gonna repeat that here.
It’s important to understand that in general, these two measures are completely seperate from each other. Device encryption won’t help against logical attacks, and logical protection won’t help against offline attacks. You need both if you can’t rule out an attack vector completely (i.e. your server sits in a secure safe that can’t be opened by anyone not authorized to, then encryption might not be necessary).
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 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.
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 assume you’re talking about X over SSH? That’s possible with Wayland via Waypipe. Also I’m not sure why RDP would require X, just a compositor being able to forward the video over network (which is perfectly possible with Wayland) and accepting inputs over network as well, which to my knowledge isn’t part of Wayland. Quick check says Gnome already offers RDP and that’s Red Hat’s DE.
As pointed out, they don’t use it. However, there are loose plan for KWin to migrate to wlroots one day, and in fact a hostile fork exists that is exactly that (KWinFT). So a compositor can make use of wlroots to implement Wayland functionality, sway for example does exactly that, unsurprisingly since they’re sister projects by the same author.
It should be noted that libwayland (mentioned in the patch notes) also exist, and wlroot actually depends on it, so I guess libwayland is like the lower level stuff while wlroots saves you some work to integrate libwayland into your compositor; the motto is “Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.”