Year of the Linux on the desktop might never come, but we do have Linux on everything else. Servers have been mostly Linux since at least -00, smartphones have been mostly Linux since about 2010, various embedded devices have been mostly Linux, if they need a full OS, since about 2000 I guess and now Linux has a serious bid in game consoles also.
I use PopOS as a daily driver. Linux gaming has picked up quite a bit, to the degree that the Steam Deck runs on it. Linux now comes as part of Windows. QEMU is now running on any developers Mac who uses containers. Anecdotally, my girlfriend (who is not a technologist) is now a Linux power user, to the extent of fully customizing her Gnome environment.
If that isn't Linux on the desktop, then yeah, it may never come.
Personally, I would say that Linux lacks two things:
1. Cross platform integrations. The way MacOS can intelligently switch AirPods over or share with your tablet is nice. Linux doesn't really have that.
2. DirectX that's compatible with Windows DirectX. That would slay Windows gaming. For now, there's Proton.
> 1. Cross platform integrations. The way MacOS can intelligently switch AirPods over or share with your tablet is nice. Linux doesn't really have that.
KDEConnect (and its compatible Gnome counterpart) is pretty good, though I understand it's not exactly what you asked
> 2. DirectX that's compatible with Windows DirectX. That would slay Windows gaming. For now, there's Proton.
Well... I'm not sure why you'd want that specifically, or what you mean by that. There's DXVK which is a compatible implementation, and which you can use natively. There's also gallium-nine, and the wine implementation of DX (including VK3D for DX12). All are pretty feature-complete, can be used for native apps, and there are a few more alternatives (like ToGL, which Valve developed a while back).
I'll have to give those a shot and see if they work on games not running in Proton. My criticism is a bit dated to the last time I did this assessment for the purposes of discussion. Thanks for the callout!
gallium-nine can't really be targetted however. While most distribution with AMD or Intel graphics will have it enabled as part of Mesa, it can't be used for nvidia (unless... well, you could theoretically use zink to run that on top of vulkan as well). It's DX9 in any case.
Winelib has been a thing for a veeery long time, I think it was always possible to build a native executable and link against Wine's DX->OGL translation layer.
If you wanted to try out out, Nobarra, a Fedora based distro which has been tweaked for gaming. It’s done by the person who does the glorious egg roll Proton version.
> Anecdotally, my girlfriend (who is not a technologist) is now a Linux power user
I got my 80+ grandmother-in-law onto a System76 and she has been having a hoot "learning things." For reference, her tech aptitude has involved phone calls where I remind her to plug things in. And, as a bonus, it makes her completely immune to tech support scams.
- Dropbox on Linux hard-locks when trying to sync some files that happily get synced on Windows and macOS
- Google Drive doesn’t even have a good client and you must resort to 3rd-party tools like OverGrive
- Spotify has had broken shortcuts for more than a year now
- Many of Linux it’s file managers still don’t support file thumbnails
- system sleep is still unreliable (one could say broken?)
- power management on laptops is atrocious without deep manual tweaking
- sound on laptop speakers is atrocious without a Pulse EQ profile
- it often still feels like a hodge-podge of different projects slapped together, which it is. Distros that try to tackle this (Elementary) receive nothing but scorn
I like running Linux, but pretending it’s even halfway as user friendly as macOS or even Windows is just deceitful, either to yourself or, even worse, to others.
Hopefully Valve’s hard push into Linux might get 3rd-party developers to improve their Linux clients, because Steam Deck users will be too big a usergroup to ignore.
My Lenovo Legion laptop gets an hour and a half more battery life on PopOS than Windows 11 for casual uses (gaming is about the same but I don't do that on battery). No tweaking or arcane config needed, this is just a plain, regular out of the box experience from a fresh Linux install. If I boot Windows, it will randomly lose the correct time while sleeping and sometimes power itself off. No amount of BIOS or Windows tweaking has resolved it. On the Steam Deck side, Linux sleep seems to work perfectly, I never experience the device struggling to wake from sleep or restore itself and it doesn't drain the battery over night on a whim either. OTOH my wife's Surface laptop with Windows seems pretty great too.
In my experience, if it's not made by Apple you can't trust it to handle power management without hands on experience to prove it first.
The only two issues you mention that are real have nothing to do with Linux itself but third-party support. As you even acknowledge there a multiple functional third party cloud drive clients.
The other complaints like not all file managers have thumbnails is like complaining not all windows apps have tabs. There are great file managers in Linux with thumbnails and they are the defaults in not the major window managers.
Spotify shortcut works fine but maybe you were using a broken package?
I never had an issue with Pulse but Pipewire is the new king on the block and works so smooth.
Third party support has a lot to do with how Linux works though. There's a reason Valve basically abandoned the idea of native Linux games and invested in Proton instead, for instance. It's because everything above the kernel in Linux is kind of a garbage fire when it comes to consistency and compatibility. You usually can't even run a binary compiled for Ubuntu 20.04 on 22.04 despite them theoretically being the same OS two years apart.
Driver support is hindered by the lack of stable driver ABI, basically forcing drivers to be FOSS and mainlined. Granted, this also has some advantages.
Valve isn't abandoning the idea of native Linux games. It is up to the game manufacturer. There are probably about 150 games in my Steam library with native support.
I think the issues you are referring to about compatibility have to do with dynamic compilation and something like glibc, which mostly is a compilation risk that you end up taking but the only times I've encountered it the other packages were already available in my distro and so it was just a matter of updating packages. That is why you should find a distro that is quick to update.
> The only two issues you mention that are real have nothing to do with Linux itself but third-party support.
If you don’t think sleep or power management issues on Linux are real you should do a cursory google. You not having the flu doesn’t mean the flu doesn’t exist and isn’t running rampant.
Also, third party support is critical. The majority of user would not want to use Linux if it didn’t have any access to Dropbox, Spotify, Slack, Discord, VLC, or any of the other creature comforts people expect to be able to use these days.
> Spotify shortcut works fine but maybe you were using a broken package?
Ctrl + right and Ctrl + left (next & previous track) are broken and have been for a long while now. Again, do some research.
> I never had an issue with Pulse but Pipewire is the new king on the block and works so smooth.
Pipewire uses PulseEQ. Also, this has nothing to do with what I mentioned (internal speakers not automatically being EQ’d with a ‘small speaker’ EQ). If you ever hear a MacBook, you’ll be flummoxed by how good it sounds in comparison to the tinny sound of your laptop. EQ is king.
> If you don’t think sleep or power management issues on Linux are real you should do a cursory google.
It's probably terrible on unsupported hardware. Having used Linux-compatible hardware for a while now though, neither of these are an issue.
> majority of user would not want to use Linux if it didn’t have any access to Dropbox, Spotify, Slack, Discord, VLC
Good thing all of those programs are natively packaged for most distros, then.
> Ctrl + right and Ctrl + left (next & previous track) are broken and have been for a long while now.
...because Spotify migrated it's shortcuts to the more technically-correct MPRIS implementation. If you want shortcuts, set them globally and Spotify will respect it.
I'm not going to make the argument that 'everyone should use Linux', but it makes me sad listening to software developers level outdated complaints against the ecosystem. Linux is fine these days, if you don't edit video or do intensive creative work then I see no reason to avoid it.
> Having used Linux-compatible hardware for a while now though, neither of these are an issue.
I have a laptop with that is specifically designed to support out-of-the box and the first thing I had to do with the stock PopOS was disable sleep and hibernate because it reliably crashed the system. Even "Linux-compatible" hardware is extremely hit-or-miss.
> It's probably terrible on unsupported hardware. Having used Linux-compatible hardware for a while now though, neither of these are an issue.
Even on supported hardware there are often tons of snags. You either get a ‘blessed’ device (XPS, some Lenovos, System76, Framework) or trouble lurks. And note that many many more devices are considered ‘supported’!
> ...because Spotify migrated it's shortcuts to the more technically-correct MPRIS implementation. If you want shortcuts, set them globally and Spotify will respect it.
And yet most of the other shortcuts work fine. I also don’t want global player control, because it always ends up activating on the program I don’t want it to.
I also don’t want to have to configure shortcuts manually. They should work out of the box.
Imagine how laughable it would be if Davinci or Darktable or Krita asked you to set all shortcuts yourself.
> Good thing all of those programs are natively packaged for most distros, then.
And yet they nearly always have rough edges the other platforms don’t seem to have. See my Dropbox problem. Or Discord running on such an old Electron that it creates problems with Wayland. No, Webcord isn’t a solution as it is missing a bunch of features and in maintenance mode.
> but it makes me sad listening to software developers level outdated complaints against the ecosystem
I’m getting so irate because they’re not outdated problems. You’re plugging your ears and going
‘la la la la’ thinking that if you don’t acknowledge the problems a lot of others are having, they don’t exist.
It's fascinating behavior. I remember having an issue a while ago and describing it on a forum and the linux defenders literally told me that the issue doesn't exist and I am just making things up. They would simply ignore reality that didn't conform to their belief that linux is the holy grail and is beyond criticism. Psychologists would have field day with these people.
What was the issue? It seems like a lot of people that say things like this are so vague that they really just want to complain but not provide enough information to allow anyone to help.
I can't help notice your post history is just a bunch of Linux bashing without any details about what doesn't work.
What are you running like a 5 year old distro? The only problem that actually exists that you mention is Dropbox client may have issues and an official Google Drive client doesn't exist. If you are having so many issues then it sounds like you've either chosen a poor distro or it is a user issue. None of the other issues exists for me on Arch. I've never even looked for a 'Linux-supported" laptop, whatever that means.
What are you using for GUI with Linux? Given these are complaints you have, I’m guessing you aren’t using a userfriendly / more integrated distro. Ubuntu is not totally GNU and has proprietary code, but it is pretty userfriendly.
Anyway, in general:
If you like Mac, use Gnome. That is the default in Ubuntu.
If you like Windows, use KDE. That comes default in Kubuntu.
Ubuntu is debian-based, so you need to use packages that support that if you use Ubuntu. Dropbox and Spotify both have installation instructions for using it on Ubuntu and, when I used those instructions, everything worked fine.
It is an open source dropbox client. Needs less permissions and the performance is good, it works well in linux but I had some issues on arm based Mac. Used it a year or two ago so perhaps it has gotten better.
I’m willing to bet there exists an open source solution that integrates with the Spotify SDK as well.
Sleep, power management, etc all work well for the userfriendly focused Ubuntu distros. It was a major pain point for me for a while many years ago when I started, but I found that KDE Ubuntu distro and it made everything a lot easier for me migrating to linux. Give it a shot.
I do think Valve involvement will help the landscape a lot, I just hope it doesn’t bring must-haves that are proprietary.
I’ve tried KDE, Gnome, Zorin and Elementary. All have their own sets of problems.
I know of Maestral. It uses the public Dropbox API which means any files Dropbox deems ‘grey area’ (think console BIOSes but there is a ton of stuff that gets erroneously flagged) refuse to sync.
I’m not a first time Linux user, and I can somewhat deal with these pain points, but recommending Linux to layman people, especially when telling them “it’ll work smoother and be more bug-free than Windows and macOS” is just setting them up for a world of technical pain.
In my experience, linux as a technical expert can often times get messy. I’m probably just not the sharpest tool in the shed, but I often got in my own way. The default distros work pretty well these days for a laymen, because they mostly won’t tweak it to the extent, say, I would.
You are experienced and I share some of the pain, so I won’t beat the point in. But I do think every OS has its pain points and advantages — and linux has a unique adaptability that just about anyone can find their niche in. Nothing is bug free but it might just be smoother, given advertising has infected the major corporate Oses.
I use Dropbox on Ubuntu, ipad, iphone without any trouble. I tried Google Drive a few years ago, but it could not even do the initial sync (I know because I waited 30 days for it before giving up).
Isn't Bluetooth multipoint what you're looking for re: intelligently switching Airpods? There are a decent number of non-Apple Bluetooth headphones that can do that with any manufacturer's Bluetooth capabilities (it even works switching between an iPhone and a non-Apple laptop!). For example, the extremely well reviewed Sony WH-1000XM4 can do it — those are over-ear headphones, not the earbuds, but Sony announced that they're updating the earbuds (the WF-1000XM4, to use the nearly-inscrutable Sony product name) to support Bluetooth multipoint too — as well as earbuds and headphones from Anker, Panasonic, etc.
I own the Sony headphones, and the multipoint stuff isn't great. If I as much as get a notification on my computer it'll mute my phone playing music, I can't be in "high quality audio mode" while talking (Bluetooth ext that doesn't seem implemented).
It works, but in my day2day I Bluetooth with my phone, join meetings on both Android and Linux at the same time.
I've got Ubuntu on my home machine and it is an absolute buggy mess.
I tried to right click and format on a flash drive yesterday, the button did nothing.
No errors.
No pop-up messages.
No little spinning wheel.
It did literally nothing. Did not respond, tried to click it multiple times, continued to do nothing.
I have to open up the partition manager and reform at it through there.
I've tried before to drag files from my archives into the window manager, and it doesn't work. The program's not talk to each other so you can't drag and drop between them.
I've tried to use network paths as a folder on tons of different programs, and they rarely handle it well. Best can be a problem on Windows too, but it's so much more common on Linux.
The user experience on Linux is just so incredibly buggy, you have to dig down into the command line at times to fix things, and so much stuff just doesn't work so often, or doesn't work with each other.
Linux on the desktop needs a team of like five people to actually use it every day like a normal user would, but no understanding of the command line, and then constantly complain to the developers so that all of these issues get fixed.
Until that happens Linux on the desktop will not be able to compete with Windows, no matter how many features it has. Because at the end of the day I want my operating system to just work.
I'm not going to say your complaints are invalid, but you're setting a very high bar, one that no mainstream OS clears today. I've had similar and much worse problems on all the big three platforms.
I've never had any problems on Windows similar to the ones I've had on Linux.
On Windows I have never had a button just do nothing. Not for something as simple and common as formatting a flash drive.
I've never had problems dragging and dropping between a popular windows program and the windows operating system.
Maybe it's inherent because Linux is open source and stuff just won't work together because of that, but if that's the case then Linux is doomed to never be able to compete with Windows.
> On Windows I have never had a button just do nothing. Not for something as simple and common as formatting a flash drive.
Amusing, given the amount of times ive clicked on a defunct or near-to-failing drive in windows and either had the drive disappear, or just not do anything.
The amount of times I've seen windows do absolutely fucking nothing in response to a USB, at least linux screams into a console about it
I do find, like you have, that the GUI implementations one finds with Linux tend to be weirdly deficient in very specific ways. For instance, I'm running the latest release, not LTS, of Ubuntu right now, and at this point in time, I still cannot:
-Set a different wallpaper for each monitor
-Make the OS remember where I closed a window and reopen it there
On the second one, it's possible for that to happen, but it's the app's responsibility for some reason. So Firefox does behave that way, as long as I haven't messed with my monitor layout and as long as I quit the app rather than closing the windows one after the other. Nicely nicely, Mozilla.
But my VNC app that I use for half an hour every morning? Every morning I have to move it over to the other monitor immediately after launching. There are other apps that I could try, but I haven't mustered the patience to re-solve my VNC problem when I have a lot of other things to think about as well.
It is even more aggravating that, according to the googling I have done about this, this is because of the adoption of the supposedly-better Wayland server; if I were to run X instead, apparently my window position remembering would come back. This was a solved problem, and that's apparently why it's de-solved. I have not investigated why Wayland is there, but I assume that it's for the same reasons that Systemd is there, ancient processes that have become detestable to modern programmers and needed something to replace them.
Your USB stick and network mapping issues as well, I have had many aggravated days with that stuff. I especially find that once I format a USB to linux, it requires extraordinary measures to even see it again in windows (one has to load diskpart and clean it first, which is a command line process - big deal to a Windows user). I don't know if there's anyone who could be blamed for this aspect, really, interplatform operability will always be a problem while the profit motive is a factor, and UEFI/Secure Boot makes that a minefield. It's a complex world.
Take this as you will, but I don't find I have many problems with mapped drives anymore, as long as I do it the old-fashioned way with /etc/fstab. Very occasionally I might need to run sudo mount -a in a console but that's when something else has gone wrong, network-wise. Once again, the GUI implementations are indeed troublesome, but there at least is a working solution in this case, but one which involves the console, probably.
It's aggravating, to be sure, but it's also free forever, and I have many choices I could try instead of Ubuntu/Gnome, and at some point I will (I have a lot of personal inertia on this, as many do - I've had KDE installed for weeks, haven't touched it in a good ten years now, but I also haven't had to reboot for weeks so I haven't had occasion to bother logging out). I didn't have to pay for it, I'll never have to pay for it, and at some point either someone will sort these minor irritations out, or I might even take a weekend to learn more about how these desktop environments work, and come up with a solution of my own to share and earn the love and respect of my peers.
It's a world of possibility, rather than endless rent-paying, and that is more valuable to some than this or that minor convenience.
Even just on Linux, there are multiple platforms. The big ones are KDE and Gnome. If you want to write the best possible native Linux application, you have to pick one of these and right off the bat you are losing about half of the potential Linux desktops.
I wish KDE and Gnome would merge. I don't really care which one would dominate because (IMHO) they are both excellent. Both give me icons I can double click on to launch an application and that's most of what I need from my desktop environment.
Both Firefox and Chrome use GTK under GNU/Linux, the KDE team has invested a lot of effort in keeping GTK as well supported as you could hope for. Using GTK is fine, though of course Qt allows you to ship a single application to not only Windows, GNU/Linux, and Mac, but with some tweaking Android as well.
Yeah, I have a framework laptop which is supposed to be fairly good for Linux compatability and I'm considering installing Windows. Horrible standby battery life, random lockups when I'm in the settings app, brightness keys that don't work unless you disable other features, deficiencies in non-integer scaling, etc.
Proton is actually really great for gaming, I just can't figure out how to get full screen games to render at native resolution without turning off DPI scaling across the entire system
I don't hate it. The GNU user space is built around a paradigm of source sharing and using the shared source to build a very coherent and pleasant OS. Having some kind of clear separation between that and closed software makes things more pleasant IMO.
"Coherent" is not a word often used to describe the Linux Desktop experience. How many different ways do I have to copy and paste again? Which ones are valid in which contexts?
The OS is coherent (arguably more so than most) even if the GUIs aren't necisarily. A big part of that is because most of the useful apps are shell/VTE apps. Even still it's not like other OS vendors are much better at building good UIs: How many frameworks has MS gone through just to say "screw it, write web apps?" Even Apple can't get everyone onboard with Cocoa.
Wouldn't this be more applicable to BSDs more so than Linux? One is a kernel and userland made by the same team and packaged together and the other is a kernel with a bunch of different philosophies packaged around it.
I don't want to be pedantic and write "GNU/Linux distributions" every time. People know what you mean when you write "Linux." And the result of the distribution model is something similar to the BSDs (when you pull the projects apart I'd argue they're really not so different socially.)
> Year of the Linux on the desktop might never come
I'm not even sure what that would mean practically. By brute market share, possibly not. But I've had Ubuntu as my personal daily driver for many years, and at the moment it's honestly just a much better experience than either Windows or macOS.
Microsoft and Apple seem to have turned their operating systems into advertising platforms for their other products, largely disregarding the basics of what makes a desktop actually work well.
iOS isn't Linux, and Android isn't GNU/Linux either regardless how much people keep patting themselves on the back for having the Linux kernel.
Android userspace is Java and Kotlin based, and the NDK officially only allows for Android specific APIs, C and C++ standard library as per ISO, and that is about it.
Nothing else from Linux kernel is considered part of Android's public API.
Google could move to Fucshia on a whim and only OEMs, and people that root their devices would notice, Java/Kotlin apps would work as usual without recompilation from source, while NDK code would suffice a recompile.
> Nothing else from Linux kernel is considered part of Android's public API.
Just a bunch of syscalls for apps, that yes, could be reimplemented (the number of re-implementations in the wild actually says how much Linux is becoming a lingua franca of OSes) or virtualized; the whole security model (users/selinux/seccomp) and the toolset.
A POSIX replacement for CLI and daemons, without any support for other kinds of workloads.
And for what, on cloud deployments, what matters are language runtimes and type 1 hypervisors, while GL and Vulkan are completely unrelated to Linux kernel.
Android uses the Linux kernel, which is anyway invisible to app developers, that is about it.
My Sony blue ray player and LG smarttv also run the Linux kernel, so what, doesn't change anything for the movies I watch on them, and I doubt they have contributed anything to upstream
It isn’t a Pyrrhic victory, the open source community isn’t harmed if Sony takes the code and doesn’t contribute back. Is it selfish of Sony? Sure. But it doesn’t harm the project, it just fails to help.
The open source community is in the end just a bunch of developers who share their solutions to help each other out. If other parties copy their stiff, it doesn’t make the open source community’s problems un-solved.
The year of Linux on the desktop would be a total nightmare, can you imagine a bunch of non-technical bug reports and feature requests hitting all these mostly volunteer projects? What a mess.
This seems like a total non-sequitur, unless there’s a link I don’t see?
The people try really hard to get working the systems they are interested in, and then share their results. I mean there are various wikis out there with big lists of printers and wifi dongles (thankfully less of a thing nowadays) that are listed in states of:
* I actually could try this on my side and it works
* This brand usually has drivers, good luck!
* Totally unusable.
Imagine if a company with a customer service relationship, like Microsoft, went around dropping support for reasonably recent hardware! It would be seen as a sure sign that they’d betrayed their customers and dropped all pretense of competence. But the expectations for a community project are happily different.
I have no idea what victory you are talking about. Linux dominates roughly everything, except desktop. You can go argue about your own things somewhere else.
It is not a phyrric victory for Linux itself, since this is exactly the one victory they wanted to achieve, evidenced by e.g. the reluctance to accept GPLv3.
This is not entirely true; as I argue on another thread, ChromeOS is much closer to desktop Linux than Android is. Anyway, this is orthogonal to the above point.
So. A Minecraft is an OS? It runs userspace stuff (mods).
What you are missing is that Linux on Android doesn't do what a normal OS is supposed to do:
- multiplex hardware resources
- abstract hardware
- protect software running on it from each other
Last time Android tried to control user resources it led to a gross vulnerability, because it wasn't aware another piece of software was actually managing it.
It's essentially locked in the attic of Android, while everyone else is roleplaying that Linux is still the operating system.
If you want to be this pedantic then GNU/Linux also isn't an OS. Debian is an OS, Arch is an OS. NixOS is an OS. Such statement muddy the water to the point of no longer matching at all what people mean. Because when people talk they don't use the 100% correct technical term.
So what's your point? When people say linux. You take it to mean GNU/Linux. And that honestly comes out of nowhere. At my work we use a ton of embedded devices that don't use GNU but instead use things like busybox. Everyone refers to them as Linux systems.
Android is Linux system in every single way. It's not however a GNU/Linux system. But the comment you originally replied didn't claim that.
You'd have a better argument saying Google Container Engine isn't Linux.
(Because it ain't; the "kernel" of a container running on Google Cloud is a userspace application called gVisor. It's just compatible with Linux syscalls. gVisor happens to run on Linux currently, but I don't see why they couldn't port it, you pretty much just need a KVM- or ptrace-like API, and Go platform support.)
If Valve decides to make a standard ‘game console’ - miniature gaming PC with a PlayStation-like form factor, standard hardware for game devs to target, SteamOS - then add gaming consoles to that list.
There was an interview recently with someone in Valves steam deck team who mentioned that it’s on their radar but they don’t have the manpower yet to consider it. It does seem like an obvious next step, especially if Steam Controller 2 is released.
I honestly don't see the point. The Deck is like the Switch: easy to use in both docked and handheld mode. All Valve has to do is to bundle a dock and some new controllers and they have a full fledged game console.
I'm aware. This time, SteamOS is much more mature and consumers are primed for such a move. Especially if it's more tightly controlled by Valve instead of allowing 3rd parties more leeway.
Those were capable of nothing but streaming games(didn't even have a native web browser). Why would it be comparable at all to a machine that runs games locally?
You are mistaking the Steam Link hardware with Steam Machines which were real computers made by several 3rd party vendors (Alienware, Asus, Gigabyte etc.)
Note that a defining feature of a game console is its locked-down nature, where even normal things like modding single-player games (very common on PC) are verboten. The Steam hardware is quite the opposite.
Rather than Linux rising to meet the expectations of users, I think it is more likely that Windows will continue to decline in usability until it is on par with the top Linux DEs. Dunno what to make of MacOS in this.
> it is more likely that Windows will continue to decline in usability until it is on par with the top Linux DEs
For me, that threshold has been shattered.
I'm not even going to talk about ads and similar telemetry crap.
All in all, the Windows desktop is more sluggish and loves, LOVES, to get in my way. And I'm basing this impression on my desktop: 8 core xeon, 64 GB ram, fast pcie3 nvme drive, mid-range gpu (I can comfortably play most games with full settings in FHD). Maybe not the greatest out there, but a comfortable machine still.
It may be due to animations in part, but many, many things just lag. Try to launch some app by clicking the start menu. First, it takes a while to appear, then it waits for ages until it shows my app. I only have a few apps. I know it looks for something on the internet. I don't care. It's on Windows. I never asked it to do that. On win 10, I could jump through some hoops and disable that in between updates. I don't think that's possible anymore.
The freaking control center, or whatever it's called, which pops up when you click on the sound / network icons. One out of three times it will seemingly ignore my click, even though there's an animation. And then jump up three times when I click it multiple times. Same for opening the settings up from said menu. The gear turns, but nothing happens for several seconds.
Speaking of settings, every other update it figures it should reactivate the freaking "use alt-tab to change between edge tabs". No. I don't want that. Please. stop. changing. my. settings.
Then there's the light / dark circus. Sometimes the explorer ends up in some kind of grey color for some reason. It's neither the light nor dark ones.
The task manager has a hard time figuring that my screen is quite big (4k at 100%). So it just chops off the right hand side of the memory info in the performance tab. The graph does take the whole size, though. Also, quite often, when I try to maximize it, it will take the whole screen, and end up with the bottom part behind the taskbar. I don't use any interface tweaks, everything is at its default, with a fresh install of windows when 11-22h2 came out.
Then, you decide you've had enough and what to shut down. For some reason, the task manager doesn't feel like it and will block it. There's also often, but now always, an unnamed process that will delay the shutdown.
Then, there's the whole hardware support question. I've complained about this like a broken record, but my work laptop only got full GPU support a few weeks ago. For a laptop bought in December 2021. With an 11th gen Intel GPU. Same for another similar laptop, whose webcam had only worked intermittently. Both laptops are your usual HP Enterprise fare. Both worked 100% on Linux since day one.
I have an 18 core i9 overclocked to a stable 5GHz and 128GB of RAM.
Without fail, every single time I press the Windows key and start typing, the first few letters are dropped.
Without fail, every single time I launch a new Explorer window, the file path has a slow ass green progress bar, my drives (of which I only have 4, and only one is a spinner) are place-holder icons and the available storage icons aren’t there. After very literally 10 seconds or so, Explorer finally looks right.
Meanwhile, Everything search remains blissfully instant, Explorer alternatives such as OneCommander are blazing fast, and even tools like PowerToys search (the one that looks exactly like macOS’s Spotlight search) are fast as hell. I find that one surprising because I’d assume it’s just an alternative GUI for Windows search, but I guess not?
Anyways, the point is, Windows itself isn’t even necessarily the problem (though, yes, it is a mess that I grow less and less able to tolerate). Even Windows’ first party foundational apps are completely broken.
At this point I’ve all but washed my hands of Windows. I just can’t stand it anymore. Life for me from here on out is primarily Apple hardware, as many FOSS apps and services that I can find, and Linux VMs for development.
Im planning on switching my Windows PC over to a NixOS bare metal install, and will run Windows via KVM for the rare moments when I want or need Windows. But even for gaming, which I do far less of nowadays (pretty much Souls games and the odd game of Smash), my PS5 and Switch are more than good enough.
Windows is an absolute train wreck and I have every reason to believe it’s only ever going to get worse, not better. Which sucks because though I prefer the Unix paradigm, there’s still a lot to appreciate about Windows. I wish it weren’t being driven into the ground, but here we are.
After distro-hopping for a while, I've finally settled on NixOS on ZFS root. The ability to boot into any previously working configuration if you manage to screw something up that doesn't work with your hardware or whatever (which is unfortunately still far more common on Linux than on Windows or macOS, if ever... and this feature is via GRUB and NixOS, this doesn't even touch ZFS snapshots which are yet another layer of security), as well as having all configuration be declarative (and storeable in, say, a github repo, and deterministically reproducible) is frankly "the only safe way to fly" in the Linux ecosystem IMHO.
The only trouble is, it's still definitely for power-user Linux folks. There is at least 1 fork trying to put a dent in this problem, though: https://snowflakeos.org/
I think ChromeOS is much closer to desktop Linux than Android is. Among other things, I have seen more contributions overall from ChromeOS guys than from Android guys, despite the huge differences in user numbers.
Wasn’t pretty much every battery-preserving feature made by android kernel devs? Android is just no longer in its early days to need bit kernel changes.
I absolutely disagree. The early Android was using a very simplistic approach to powersaving that was not only not a good fit compared to what desktop Linux was using, but also disagreed with the previous work that had been done for Linux from other vendors (e.g. TI).
Android did not start the craze of Linux on devices, they just surfed on it...
At least ChromeOS devices (nearly?) universally support being unlocked to allow the owner root access and to flash whatever they want; I would love for Android to have the same "developer mode". Not that I really disagree with you.
"Year of the linux desktop" has transformed from a mock into just a self-referential meme joke as nontechnical end-users moved away from desktop computers and the Windows competition started to slide into irrelevance.
The corpo world Windows market is still there, and "enthusiast" windows gaming is there, but personal computing for was mostly taken over by mobile / iPad / chromebook competition. And most of gaming of course is on mobile and consoles. The remaining corpo world use supplies mass market PC hardware to run desktop Linux on and we should keep an eye on its viability.
(Linux is of course a completely mainstream platform in the dev / maker / engineering world, windows only slightly ahead eg in stack overflow dev survey, has been working well and steadily improving for less technical users for 2-3 decades)
The traditional desktop is dead, but we’re getting app-based desktops - something look similar, but with completely different ecosystem from developer to consumer.
More and more corporations use some kind of on-line SaaS software. Those only need browsers.
What's funny, is that for a long time MS Office was one of the reasons why enterprises would stick with Windows. But now, with Office365, the web experience is better than the installed-app, one. I understand "more advanced" features aren't there yet. As someone fairly basic, I have no idea what those are, but from what I see most people do in Excel, it's just basically an easy way to get a table. That works fine on the web version.
There's also the tendency of locking down workstations, by installing all kinds of detection agents, usually billed per node.
With the two combined, I would expect more and more companies to switch to some kind of dumb terminal, that would only show a browser.
Sure, this would probably not work well for everybody, but for many office workers it would likely be perfect. Hell, even for developers, with all the "remote dev" things coming out lately.
Even if "only" 2.5% of desktops and laptops use it, that is not a small number by any stretch of the imagination -- that's like 30-50 million people. For comparison, ChromeOS has a market share of about 2.4%, and that's with a fairly concerted effort by Google to drive adoption.
Meanwhile, the Stack Overflow Developer Survey showed a massive jump from 25% of respondents using Linux last year to 40% using it this year. Even if you assume some sampling bias, that's still a huge swing.
Then you have major manufacturers like Dell shipping laptops with Ubuntu, Proton and Wine getting better and better at running Windows games and apps, projects like WSL and the Steam Deck giving more people the opportunity to try Linux out, etc.
Even if there are still flaws and barriers to adoption, those barriers are diminishing and momentum is clearly building in Linux's favor. It will only get easier to run Linux going forward.
It probably won't overtake Windows or become a huge competitor (at least, not in the foreseeable future), but I think in the near future it will become more of a "mainstream niche" like OS X was in the 2000s. Most people won't run it, but they'll probably know someone who does and it will be at least conceivable that they could run it themselves.
Google is playing the long game on ChromeOS though, by getting it into schools— those are kids who are going to hit adulthood in 10-15 years with their primary (and maybe even only) computing experiences having been iOS devices and Chromebooks.
Which is all well and good for Google, but that's just not the kind of time horizon that open source projects can work on.
Yeah. There's two camps of the "year of the Linux desktop" topic. "I want Linux to be the majority of usage share" and "I want Linux to be good enough for me to use." The 2nd goal has been accomplished for many potential users since the mid-2000s, and only increasing especially since the web has nearly killed off native application development. The first goal is one I'm not interested in, myself.
Desktops themselves are increasingly becoming 'irrelevant' for people who aren't specialists or using them for office-productivity tasks.
Judging from what I see from my family and people I meet, many homes no longer have any kind of desktop or laptop computers, and rely exclusively on mobile devices of various types.
The era of the 'home computer' will probably turn out to be a "brief" window between the early 80s and this decade. Some people who need specific functionality might have a laptop. But even there, tablets or other restricted mobile-type devices are making inroads.
As someone out of the loop on this, why is Nix so popular right now? What does it do and why are people installing it on everything? Is this something to pay attention to or is it a rehash of the 'I put linux on my toaster' 2000s-era stunts?
These aren't precisely the specified goals of Nix, but things I appreciate as a consequence of its design:
(1) If a build works on any machine, it will work on yours. Package builds are isolated and reproducible. For example, setting up Plasma is as simple as `services.xserver.desktopEnvironment.plasma5.enable = true;`, every time, in every environment.
(2) Environment configurations are declarative. You will always know what a given host or shell has installed because you have to write it down.
(3) Nixpkgs is _by far_ the largest package repository of any package manager, and packages are updated very quickly.
(4) With home-manager, software can also be configured declaratively; my preferred tmux configuration will always stay in sync across all of my machines because it's managed by Nix, not ~/.tmux.conf.
Nixpkgs is the largest repository only because they let anyone throw anything they want in there with minimal accountability. Nixpkgs is the NPM of Linux.
While I love the determinism of NixOS, their refusal to mandate strict code review, code signing, and package signing makes it unsuitable for non-hobby use cases.
I do hope to see a fork of NixOS with the supply chain integrity of OpenBSD or at the very least that of Debian or Arch.
Could you expand on those points? Specifically, what do you want to see for code or package signing? Has there been opposition to this before?
It should be trivial to sign a trusted derivation, but the signed artifact is either an out-of-band signature that has to be verified, or a new signed derivation is produced which creates problems for anything consuming the non-signed derivation.
It is trivial, but too many people want NixPkgs to be like NPM with minimal friction so random inexperienced devs that do not know how to generate a keypair can contribute. That lack of friction is why it has so many more packages than most distros, and also why you cannot trust any of them.
I tried to appeal to fix this in 2018 as a total outsider but it was endless bike shedding. Most would rather have no signing at all than use the well supported tools every other distro uses with success.
As a security engineer I lost all interest in NixOS after that. They want it to be a hobby distro run like a wiki, and that is totally fine. It just means we need to discourage it from being used in high security applications.
NixOS is a massive step forward in Linux distro design, and a massive step backwards in supply chain trust.
Git commits? That doesn't correspond to supply-chain verification, just committer verification, so it's not as big a benefit as package-signing in other distros.
Package sources? All sources in nixpkgs are verified against their content hash, which is committed along with the source. To pull off a supply-chain attack through substituting a malicious upstream, you'd create extremely obvious breakage when the package built by Hydra doesn't have the same output hash that you asked for at build time.
Binary substitutes? Nixpkgs doesn't use a "mirrors" system that is the traditional source of distro supply-chain vulnerabilities. Packages are input-addressed, so nix knows the hash of the output it wants, and all substitutes are signed in nixpkgs. So it is difficult to alter the outputs without breaking the dependency and falling back to source builds, and still more difficult to forge a signature for the altered output.
I agree that distros need to focus on supply-chain security as a core competency. I disagree that NixOS (rather, nixpkgs) needs to use the same mechanisms as other distros to attain it, especially when doing so would impact another core competency: simply having the latest packages available as soon as practicable, because outdated packages are another source of vulnerabilities.
Commits are not signed and approvers do not sign anything either. Nothing stops a malicious Github employee, bribed maintainer, or someone who simply phished Github credentials from making a fake PR as someone else then approving it themselves or serving manipulated git history only to CI/CD systems.
Major supply chain attacks like this have happened in lots of other package managers and most OS package managers at least learned their lesson and signs everything. Most package managers are blindly used in multi billion dollar applications, so they are a huge target for attack.
That will come with time. Nix has to overcome enormous barriers to adoption. Gate keeping to limit the long tail of desktop software is not going to help anybody. Better to get working software today and clean it up tomorrow.
People are using it for high risk applications today, when anyone with phished Github credentials can push any code they want. I have to push back on that.
Run it on a steam deck for gaming, sure, but it is only suited for hobby use cases at this stage of development.
Not exactly a fork, and you are probably aware, but there is at least one Nix-like system with full supply chain integrity and rigid packaging standards.
As far as I can tell, the only benefit of this scheme over content hashes and signed outputs is that Guix can serve their updates over HTTP. Otherwise it's vulnerable to the exact same scenarios as Nix: the rogue Git forge employee/maintainer can replace signatures just as easily as they can package sources.
I love Nix, but point #1 is arch specific. A lot of packages won’t build on Arm; although, many of those are simply limited because of unnecessary restrictions imposed by the package declaration.
Because Nix is a functional package manager, and functional package managers are the future of package managing (whether nix, guix, or something we don't have right now). It makes it easier to deal with supply-chain, to deal with rollback on your software updates, to distribute the same configuration everywhere…
I found NixOS (the OS centered around Nix) having similarities, in the way you configure things, with how you configure stuff in the networking world (with options that do some stuff behind the scenes you don't really care about). The difference is that with NixOS, you can dig in if you want to.
Also, once you used NixOS for a little while, it's very hard to go back to, let's say, Debian, Ubuntu, or Archlinux : manually configuring things in multiple configuration files in /etc seems really primitive.
While not designed to be a system package manager, Conan works in a very similar way for C/C++ package management, and it's great. All binary packages live in the cache folder, identified by a hash of the particular permutation of inputs used to build it. It even supports recipe revisions, so if the recipe (build script) changes, you don't have to worry about changes in the generated binary since you can use a lock file to keep using the specific revision of that build script that you know works.
pnpm for Node packages also has a similar design. Once upon a time, it cited Nix as a source of inspiration in its docs!
I hope that basic design continues to propagate. Better-behaved package management for language ecosystems is easier to work with for Linux distros, including NixOS. :)
> Also, once you used NixOS for a little while, it's very hard to go back to, let's say, Debian, Ubuntu, or Archlinux : manually configuring things in multiple configuration files in /etc seems really primitive.
I don't use nixos, but I use ansible to configure my desktop and homeserver environments. Completely different approach but same result in the end.
I am aware than Nix has so many other benefits but I'm talking about configuration management in particular.
> Completely different approach but same result in the end.
Well if you lock everything down with hashes, maybe in some sense, but other than declaring your configuration in a text file and deploying software with it, it's pretty much different (imperative approach with side effects everywhere, vs functional declarative approach).
* Nix being a real programming language (and thus allows far better composition, and abstraction)
* You can run any configuration you want, and easily jump between configurations (e.g. rollback), advantage of being stateless (well obviously to a degree, as a lot of software itself creates state, but normally you're not jumping between multiple major versions of the same software anyway).
* Great caching as every built derivation is cached in `nix/store`, thus only things get rebuild, that are actually changed
With Ansible you may achieve something similar, but afaik require way more setup and discipline to keep it clean, and the "programming" in Ansible feels rather painful, if you're used to a real (functional) programming language.
> With Ansible you may achieve something similar, but afaik require way more setup and discipline to keep it clean, and the "programming" in Ansible feels rather painful, if you're used to a real (functional) programming language.
Not to mention that templating a language that uses spaces for logic (YAML) is just useless amounts of pain for no good reason.
I used Ansible in the past for the exact same purpose and it has one major flaw: Ansible is imperative. What I mean is: if I add a line in a config file and want to rollback then I have to manually handle revert (create playbooks with `delete` flag etc.) With Nix you get this for free.
Also, with Nix you can trivially create image for your configuration (even with slightly different options, e.g. only enable ssh on 0.0.0.0 for a fresh install, but disable it after first config apply) which I find useful when working with a cloud.
A few things that are nice about it once you've "nixified" your project
- Locally reproducible CI builds and tests
- Sharable developer environments/shells
- Extremely fast and efficient Docker image generation
- Composability with other projects that use Nix. It's trivial to add dependencies.
- Not dealing with VMs like you do with Docker
There is a lot more if you use NixOS and make your whole operating system functional and declarative, but I think that's more of a niche.
Why is it popular now? I'm not sure. It still has a steep learning curve (and rough edges) but over the last 1-2 years it has perhaps gotten to a point where the documentation and examples are plentiful enough that more people are willing to try it out. Also, MacOS support has improved (but still kind of sucks) and the new flake system is more intuitive than the old nix files.
Nix makes it really simple and easy to manage several machines. Builds are declarative and reproducible. For my homelab I’ve setup a git repo with config for several VMs: Plex, Bitwarden, torrents, Samba shares, etc. Deploying is as simple as pushing a new commit and then triggering a rebuild on a specific host.
NixOS builds in “generations”. This morning I managed to screw up something and it bricked a VM. No worries, just restart the VM, boot into the previous working generation. Fix my Nix config, commit and push, rebuild again. Easy. I love it for managing my personal stuff.
What I don’t like about Nix? The Nix language kind of sucks, has a steep learning curve, and lacks decent language tooling (LSP etc). If you’re on the beaten path everything is rosy, but as soon as you need to configure something or build a package that no one else has done before, it feels like you need to reverse-engineer Nix just to figure out how to do fairly basic tasks.
Which makes it well suited for "put in effort now, to save effort later".
My favourite use case for Nix is using it to declare what tools/libraries a project needs. Nix can make a bunch of packages available on PATH, without conflicting with what's already installed. -- This is like tools like Node Version Manager, or asdf.
Another feature I like is the command "nix run ...", which is similar to "docker run ..." in that it doesn't change what's installed system-wide, but runs the command on the host (and not inside a container).
The nix-based operating system NixOS allows for declaring the system configuration, and safely rolling back from changes to the system configuration.
> Is this something to pay attention to...
Right now, the learning curve is quite steep.
It used to be that threads mentioning Nix would attract many "I tried it, but it's too hard" comments.
Popular where? On HN, because it's functional, and people around here like functional, just as they like Emacs, for instance. It's not popular in the industry, as far as I can see (also, just like Emacs).
For the record, I like Nix (and also Emacs), but I would never introduce it in my team. The learning curve is very steep, and the problems that it solves are mostly handled "good enough" by Docker, which I actually dislike, but everyone and their dog know Docker, there's pretty much zero training for new hires needed, introducing Nix simply does not make any business sense. In a small startup team of like-minded functional programming people, sure, but in a large org? I just don't see it.
It's funny how "not popular in industry" is always overstated. I can't deny it has very small marketshare. And yet, I've had 4 jobs in the last 6 years that have all used Nix. None of them "small startups" either. So you don't need to be popular to have enough for people to get paid to use it. Haskell is the same way.
Also, I ignore people openly who try to evaluate "business sense" as if technology decisions can be quantified like that. The biggest benefit of these Nix and Haskell shops is it attracts enthusiasts who in turn train and excite other hires. Which is turn adds more Nix and Haskell lifers to the world. One "bad business decision" at a time. That's my MO at least :)
I'm deploying Nix to real ROS robots right now at my day job. We're switching to it because it solves real problems associated with scaling the codebase and development team, particularly for domains adjacent to scientific computing.
Waaaay back in the day, I packaged Gazebo for Nix when I had an internship at a company that made robots. That was when I first dove in with NixOS, and decided that whatever packaging issues I ran into were just something I had to get good at dealing with and solve along the way. Nixpkgs was just a tiny reaction of it's current size back then, so I ended up packaging several things! I ended up needing quite some help in IRC at the time for Gazebo, which I remember as having a very quirky and bespoke build system. Folks there were extremely kind and helpful.
I ended up abandoning the packages when the gig ended. Sorry about that! Pretty cool that a whole ROS environment is well-supported via Nix nowadays. :D
Awesome! Unfortunately the public story is not really that great, actually. There's a single maintainer doing most of it (@lopsided98) and we rolled our own based in part on his work, which we in turn open sourced in October for a ROSCon talk, but are not able to maintain in public long term unfortunately.
So it's doable for sure, but for most mere mortals, Ubuntu LTSes are definitely still the lowest friction path to working with and deploying ROS.
I would strongly suggest you not use Nix for mission critical computing. It is suitable only for hobby use cases unless you are prepared to review 100% of all code yourself, because no one else is.
For robots you should not need more than a Linux kernel and a minimal init shim to your own custom runtime binary anyway.
Bit of an odd take, to hold Nix to that standard when other systems happily pull the entire world down from pypi, npm, cargo, and other sites of unknown review-status. I actually find it easier to audit my dependencies and their patches, build logs, etc under Nix than I ever did under Ubuntu.
> For robots you should not need more than a Linux kernel and a minimal init shim to your own custom runtime binary anyway.
This might have been true in 2005, but it is IMO not aligned to modern realities, where:
- You have a huge list of dependencies, including painful-to-package stuff like OpenCV, PCL, CUDA, Tensorflow.
- You deal with proprietary things like TensorRT, GPU drivers, and vendor tools for flashing firmware onto sensors, PLCs, and the like.
- You rely on the fault isolation and self-monitoring/healing of a multi-process architecture.
- You need to cgroup portions of the system that are critical vs being more spectulative.
- You have a bunch of asynchronous comms stuff going on, like streaming telemetry, logs, crash reports, and other assets. All of this has to be queued up and prioritized.
- You have to supply a user-ready workflow for updating the entire system down to the kernel and bootloader, with downtime measured in single-digit minutes.
None of these requirements will be met by a single binary and init shim solution.
I would never suggest trusting pypi, npm, cargo, etc. Those are all effectively remote code execution as a service. Those tools save you some time -writing- code but you still are on the hook to review it all just as you would review code from a peer. Why would strangers be trusted more than peers?
Operating systems should have a higher standard than random dev libraries. You should be able to trust they already have had a strict cryptographically enforced review process. Distros like Debian and Arch actually have a maintainer application and review process that includes verifying the maintainers cryptographic signing keys. We can cryptographically prove who authored any given package, who approved it, and who approved the approvers.
When your threat model includes supply chain attacks, the only answer is to get really really specific about what you -need- to run your target jobs and ensure it comes from well signed and reviewed sources... then review the edge cases yourself.
As for your other points...
> - You have a huge list of dependencies, including painful-to-package stuff like OpenCV, PCL, CUDA, Tensorflow.
Those could be statically and deterministically compiled into your target application binary, or at a minimum the final build artifacts included in the cpio initramfs which in turn can be statically linked into the kernel. You do not need a full package manager, init system, or even a shell.
> - You deal with proprietary things like TensorRT, GPU drivers, and vendor tools for flashing firmware onto sensors, PLCs, and the like.
Sure. An init shim can do insmod to load custom kernel modules as needed in your initramfs.
> - You rely on the fault isolation and self-monitoring/healing of a multi-process architecture.
Nobody said you have to have a single process. Your pid1 binary can spin off any other processes or threads you need and run reapers for them. A few lines of code in most languages.
> - You need to cgroup portions of the system that are critical vs being more spectulative.
cgroup system calls are very simple to perform in most programming languages
> - You have a bunch of asynchronous comms stuff going on, like streaming telemetry, logs, crash reports, and other assets. All of this has to be queued up and prioritized.
You can include any syslog binary you want for this shipped in your initramfs, or have everything bundle into the kernel stdout over a network where something external does the parsing. I do not know your requirements but there are many many ways to do that. I do not see what NixOS gives you that buildroot, busybox, or a single explicit choice of log collecting daemon cant.
> - You have to supply a user-ready workflow for updating the entire system down to the kernel and bootloader, with downtime measured in single-digit minutes.
If the entire OS is just a lean bzImage with everything you need statically linked into it, then a new one is downloaded to /boot, and then you reboot or kexec pivot. If boot fails roll back. No need for a read/write filesytem other than some fixed directories you can mount in for cache/logs.
I realize a lot of this feels like handwaiving, but I have been doing embedded linux systems for over a decade and have found there is always a path to a super lean, immutable, and deterministic/reproducible unikernels with nothing more than a few easily understood makefiles and dockerfiles.
If you ever want to chat about this stuff feel free to drop in #!:matrix.org
Lot of talk about embedded linux approaches for satellites and hsms in recent weeks.
You don't have to take on all of Nixpkgs to use Nix in that kind of context. Nix hackers have in fact spun off their own, more focused repos for such applications (e.g., NixNG, Not-OS).
It's pretty easy to audit your whole dependency tree with Nix if you want to.
> Lot of talk about embedded linux approaches for satellites and hsms in recent weeks.
There was a talk at this year's NixCon about migrating to NixOS for a weather satellite system: https://youtu.be/RL2xuhU9Nhk
Not taking away from the rest of your post, but the reason you'd trust strangers more than peers for random packages is that the strangers are often some of the best in the world at what they do and your peers are most likely not.
Most programming language package maintainers are hobbists new in their career with no idea what they are doing when it comes to security, or worse, actively malicious.
See the dozens of serious supply chain attacks or massive security oversights in recent years. The overwhelming majority of code in open source is not reviewed by anyone.
I'm talking about the most commonly used packages, not the long tail here.
Tokio for example is clearly maintained by some of the best people in the world at writing async runtimes. It is extremely unlikely that your peers would be able to do a better job at it than the Tokio team.
Someone being good at async runtimes does not mean they are versed in security. Also you have no easy proof the code that the Tokio team wrote is what actually made it into the binaries hosted by the Nix project. That is the nature of increasingly common supply chain attacks. The Nix tooling and package definitions themselves have very minimal supply chain integrity evidence. No author or reviewer signing, etc.
As for my peers, I work with some of the best security researchers in the world, and I myself have found and filed critical CVEs in widely depended on and trusted software like gnupg and terraform. I am not an expert by any means, but just a technical person willing to actually read some of the code we all rely on.
No one bothered to carefully review openssl before heartbleed.
Everyone assumes someone else is reviewing critical code with a security lens. It is always a bad assumption and it gives dangerous people that actually -do- review code a massive advantage.
If you ship you copied off the internet for a critical use case without ensuring it receives qualified review, then you are as responsible for any bad outcomes as a chef who failed to identify toxic ingredients.
The current industry standard on software supply chain integrity is about as negligent as the medical industry before the normalization of basic sanitation practices. Yeah, it takes a lot of extra work, but that is the job.
Most supply chain attacks are pretty orthogonal to whether there's a chain of trust on the git repo containing the package definitions, as far as stuff like poisoning cache.nixos.org with a backdoored binary that doesn't actually match the build definition given.
Anyway, as far as robotics in particular, no one worth their salt is treating the computer or ROS as "trusted" for the purposes of last-mile safety— we're using safety-rated lasers, PLCs, and motor controllers for the physical safety part of the equation. The computer is critical in the sense that it's critical to keep the robot driving and therefore critical for business operations, but it's deliberately not in the loop that keeps humans or property from being physically harmed.
Two things (not exhaustive). First, as the article notes, nixpgs has a lot of packages. Second, nix matches Gentoo's customizability but with good binary caching for common builds. (Kind of; that's very approximate)
Edit: I should amend: nixpkgs is already huge, and with flakes you can trivially get packages from anybody you trust (like Arch's AUR but distributed and easier), which covers even more packages.
It still doesn't have a concept akin to use-flags, which is what distinguishes Gentoo from Linux from Scratch, see https://github.com/NixOS/nixpkgs/issues/12877. The fact that Nix doesn't have these is also one reason why it's easier to cache than Gentoo packages.
Well, it doesn’t have global ones, but you can very trivially override attributes for a specific package if you want.
Flags are a great concept, but basically will exponentially increase the required build cache size, and imo having everything in the binary cache and optionally compile only some specific package is a great tradeoff.
Someone announced a fork of NixOS to add USE flags and remove Systemd ages ago on the mailing list, before the Nix community added Discourse. They called what they were starting 'The Church of Suckless NixOS'.
I never saw a sign of them after the initial announcement.
Agreed that there is nothing quite so unified and easy as USE flags for compile time options, although nix happily lets you ex. override build options per-package, and I think overlays let you do large scale changes.
I actually dropped NixOS after using it for 2 years. It's just not practical for day to day work unless you want to be messing around with Nix config or fighting shared lib issues all the time. I'm using OpenSUSE atm and couldn't be happier - yeah it's a lot more click ops, but I get to work so much faster and everything just works. Fedora is another good option. (If you want to know, the breaking point for me was trying to get QtCreator working properly on NixOS which I sunk about 2 hours into before giving up - but took me about 5 mins on OpenSUSE to install).
Nix, the package manager, is _amazing_ though, despite the wonky language. I use it for providing hermetic/reproducible environments for my dev projects. You create a shell.nix, auto load it with direnv, and the development environment is 100% replicated for everyone doing dev in that repo. Hook it into your CI too and now you have an identical dev environment everywhere. It's like virtualenv on steroids for any kind of project/tooling.
It is "just" another package manager, but with quite a few cool features. E.g. easily install different package versions in parallel, got new computer->just copy over the configuration and nix takes care of the rest, want to make a docker container out of this app-> here you go. Neat, hence popular.
Well, it is “just” a package manager in that all previous ones couldn’t really be called that as they were fundamentally faulty.
Nix is the first package manager that actually solves dependency hell properly.
Nah, not really. Neither the first, nor properly, e.g grafting. Not saying it is not good at that, but not even nixOS claims this as a main selling point.
The binary cache works by signing, not sure if this is what you mean? By default you get the “upstream” channels as a trusted store, but you are free to add new ones and only ones that you added their keys of. Pretty sinilar to PPAs.
Nix does blind automated signing of binaries which only helps prevent the cache from being mutated between builds. It does not ensure the code that went into those builds was accurate.
Nix allows for composability in the OS, which is nice for automation and reproducibility.
Recently a new and even bigger advantage to composability has appeared. ChatGPT. If you can think up a configuration of an OS you can ask ChatGPT to create it with Nix (or other frameworks for other relevant cases) and then nearly all the work is already done for you. I find this workflow to be even better than GitHub Copilot.
Steam deck is interesting here because it leaves me wondering about what I could ask Nix to configure on it. I don't know very much about steamos.
I think a lot of people love the principles behind Nix -- I love them enough I've tried (and failed miserably) to install and use it as my regular Linux on 3 occasions.
This is a good analogy, right down to Git's painful UX. Nix is powerful and difficult to understand. Often you'll find yourself in a spot where either you need to take hours or days to understand some fundamental component, or you can just paste a magic incantaion you found soewhere and move on. Good luck googling, it's almost as if they designed the Nix language to be unsearchable. When you do find an answer, it's often 3 years old and completely obsolete. Definitely recommend having a chat window open with other Nix users while working with it. When starting a meaningful project with Nix, make sure you're not on a deadline.
I like Nix, a lot. But I'd currently recommend it for a pretty narrow type of user/use case. Like Git.
I have to agree regarding the UX, though I would like to add that it is the language per se that is complex, but its standard lib/“nixpkgs” lib.
Also, not sure I can see where would you not recommend git? Is that a typo? It sure has a bad UX, but it is the lingua franca of version management either way, that even junior devs will have to fight to understand to become even remotely useful. And this might well be the case with nix as well.
I would not recommend git for organizations with monorepos, and not for companies that need to store large binaries (like games; git-lfs is a start but still a royal pain). Also I probably wouldn't recommend git for projects that are significantly more media than code. Depends on the team.
Git dominates open source, yes, but I wouldn't call it a lingua franca in general. Most companies I've consulted with were doing just fine with something else.
Time to start shilling it where you work. It has a pretty steep learning curve but it's worth it most of the time. In some industries (e.g. Haskell-adjacent industries) almost everyone uses Nix.
An alternative: I’ve made a little setup script to quickly install nix, home-manager and flakes in the Steam Deck’s desktop mode. No extra permissions required.
Nix is one thing, but going all-in on NixOS would have been better.
NixOS is a more ideal fit for a “steam OS fork”, frankly, than Arch, other than the fact that “Steam on NixOS native” only runs 1/3 of the games in my (large) library that “Steam on Flatpak on NixOS” does (and I wish I had time to help get it there, but I have an 18 month old kid who consumes all available time and energy!)
What a mismatch of goals. The Steam Deck is meant for games and the steam platform tries to provide a single unified system library that games play under. Nix is all about creating a new custom system library environment for every single application.
Well that's what Steam does too. Creates a whole new Wine prefix with specific tweaks for this specific game to make it work. Pretty similar if you ask me.
Nix is a great fit for the Steam Deck because it lets you install additional software safely, with no risk of mucking up the base system, and because it has a HUGE set of packages, so most things you might want are already going to be there.
