Yup. It’s a bit of a pain, but you don’t have to use the connect app. Devices and data can be accessed with direct USB connection as standard storage. You will lose some features and I think firmware updates become difficult (or impossible?)
I believe they can be used offline, at least the last time I used Garmin I was able to set it up such that I could sync it to Golden Cheetah. It took some jumping through hoops and an older watch version to get it work, as I recall. For serious runners and hikers, the hardware is better than Apple.
I'm only a casual fitness tracker so the Apple Watch fits my needs better.
I'd say not much: you update the channel, run nixos-rebuild switch, fix all the warnings/errors due to renamed/changed options until it succeeds and you're done. If you have a database like postgres you may have to do a schema upgrade manually, since the default version is updated every 4/5 releases or so.
It's very rare to find something that prevents you from directly updating. Nixpkgs tries very hard to no require new Nix features, so it evaluates with even Nix versions from a decade ago. Also, NixOS options and packages are frequently changed, but the automatic migrations (mkChangedOptionModule, mkRenamedOptionModule, alias, etc.) are never removed in practice.
Since the binary cache has never been cleared since its creation (2002?), it should actually be easy to install a super old NixOS release and upgrading it to the latest to see what happens.
By the way, there are LTS versions of NixOS, just not officially supported. See https://docs.ctrl-os.com/.
And when it happens, that there are new Nix features used in Nixpkgs, then you can download the closure for the new Nix executable, directly from the build farm, and update your OS from this new Nix version.
> a rolling release like NixOS is exactly the opposite of an LTS distro
NixOS is not rolling release. This is a common misconception. You can use the unstable channel, which is a rolling release, or the regular channels which get released twice a year. These are really stable and move very slowly. You can also mix and match, running software from different channels.
> I actually wonder what would happen to a NixOS installation frozen in time for 5 years that then you want to update to latest all of a sudden
I have done this recently as I kept an airgapped machine, which I decommissioned, connected to the Internet and updated to the latest channel. Everything worked just fine. I just had to change a couple of options in my configuration which had become outdated. Nix is functional, so it's much less prone to all stateful issues that plague other package managers.
Technically it's not rolling but you get substantial updates during the stable channel lifetime, unlike Debian or Ubuntu. And when the stable channel is deprecated (every 6 months) you need to manually change it and get a bigger version bump of most softwares all of a sudden. There is no LTS concept where you can leave almost on autopilot a distro version for 5 years.
I've only been running NixOS (in any serious capacity) for three years, but I have installed it on every computer that I am allowed to install it on now.
It has been the most headache-free Linux I've used, simply because I'm less scared to play with and fix stuff. The fact that rollbacks are trivial and snapshots are automatic, and since everything is declarative in a text file anyway, I am way braver. If I do something like screw up the video driver, or the wifi driver or make it so the system doesn't boot anymore, all I need to do is reboot and choose a previous generation.
> simply because I'm less scared to play with and fix stuff.
The main reason of a LTS distribution is not having to play around and fix stuff. Install something once, and it keeps running without any changes, but still gets security updates.
Yeah, but I find that particularly with laptops, even with LTS releases, there's almost always something you need to fix.
For example, there's a weird quirk with my laptop that if I am using a USB keyboard and stop typing for more than a minute, it "powers down", and if when I start typing again it misses the first four or five characters, which is very annoying.
The solution involved putting a few boot parameters and then it works fine and as expected, but I would be reluctant to do that with Ubuntu or really any non-NixOS distro, because if I screw up a boot param I get into a situation where the computer won't, you know, boot, meaning I'm stuck screwing around with grub commands and trying to fix things, which is annoying. With NixOS, if I screw things up it's like a minute of rebooting and choosing the old generation.
Not to mention that if you have a non-declarative OS, it can be hard to know what exactly is on the computer. When I ran an Ubuntu LTS server, I eventually had installed dozens of packages that I don't think were being used but it was hard to know for sure which ones were necessary and which ones weren't. When I'm using NixOS all the packages are unambiguously in the configuration.nix. "Uninstalling" a program (including its transitive dependencies) is just removing that package out of the configuration.nix and rebuilding.
I have nothing against LTS releases, but I do think that at least for laptops (which can have kind of arcane hardware quirks) it's better to use NixOS.
I would never put a LTS system on a general purpose desktop.
This would only make sense for some corporate environments, where the hardware purchases are aligned with the driver support of the LTS distribution. And even then it's questionable.
LTS distributions are mainly used on servers or on (network) appliances.
I run nixOS as well on my home infrastructure (gateway/firewall, a couple of internal servers).
But I have had, uh, non-trivial breakages happen also when I upgrade the system itself to the next yearly release. Non-bootable kernel kind of breakages.
But I will give you that I can just boot from the generation before the upgrade, and it works again. So there's that :)
I have run NixOS for about eight years on server and desktop and been a nixpkgs maintainer. Yes, most of the time I would agree with you. The fact that you get warnings in the terminal for a lot of incompatibilities and changes when upgrading is a really nice touch and upgrades tend to be smooth. I do not use rollbacks much, but when you do need them they are really handy. Having every configuration in a single file makes you more bold to play around with configurations, which felt really empowering when I first got into NixOS, as I knew it could roll things back and I no longer had to keep notes on how each box was set up to refer to in the case of a reinstall or migration.
However, I have had one machine become unbootable as it could no longer mount its encrypted disks after an upgrade, forcing me to mount a rescue image remotely, mount the disks manually, lift the data out, and do a complete reinstall (migrated the box to OpenBSD at that time). Similarly, NixOS once messed up systemd (or vice versa) so badly that I could not even reboot without forcing a power cycle. Lastly, I have had a package break for my use cases by maintainers enabling so many custom flags by default for a package that they enabled one I have never seen enabled by any other packaging team and that then broke RTSP in "funny" ways. Ubuntu did tend to break things like graphics between releases at times back when I used it, but I have never had any other distribution or operating system throw curve balls like the three things I mentioned here.
My general impression of NixOS is that the core is solid, but that nixpkgs just has such a large number of things that it supports that the maintainers struggle to test them all and can not anticipate the interactions between all the packages and options. The default Julia package being so broken that it produced incorrect mathematics due to nixpkgs' insistence on allowing you to swap out the Blas library and also having turned off the unit tests for example springs to mind. This was shipped to end users for a long time before I noticed it by accident by enabling the unit tests and stepped in to clean it up. It all feels very "Gentoo", which was indeed an inspiration for NixOS by the way.
Now, return to that last sentence in the first paragraph that I wrote about feeling empowered to tinker, ultimately, I feel like you should try to resist that urge as it is what pushes you into the untested fractal of possible configurations that NixOS allows you to explore. My other main operating system is OpenBSD, where the mentality is "Stick to the defaults or suffer the consequences"; with NixOS, I feel like everyone's box is more or less a tailored suit, which comes with both its ups and downs.
Eh nix flakes are a nightmare to configure. Far more verbose than a docker compose. They rely on some caches which keep pre-compiled packages and you better make sure you have the caches with the particular flakes you need set up. Yikes
Earlier today, I tried to run a simple nix tool a colleague made. 3 hours into the build, it crashed. Something about a missing python import? I ran the exact same ‘nix develop’ again. 2 hours later, it worked.
Keep in mind: this was just a simple rest server. But for some reason it needed to (nondeterministically) build the word from scratch to send that single request.
Why are these sockets "ruled out"? Pipeline/layer parallelism doesn't need high bandwidth between nodes, and tensor parallelism has middling performance unless you have very fast networking and very slow compute. It all depends on what you're doing.
You are correct that bandwidth requirements depends a lot on the exact workload. And that in specific cases, it might be doable to have AM5 for multiple RTX6000Pro. The parent mentioned workloads that are general, and broader than inference-only. In that case I would consider spending a bit extra on the motherboard to ensure that PCIE bandwidth is not an issue.
Yes! Formal specs could be where the understanding of what exactly the system is supposed to do gets laid out - and ideally coupled into the verification process that the code produced actually does what it is supposed to (and nothing else...). That would be a big change!
Good clothes can be definitely stitched. Some brands even offer free or reasonably priced repairs. Patagonia or Citizen Wolf are two examples that spring to mind, and it's even more common once you cross a certain price point. Same applies to good hardware, but you need to do some research before buying.
I am afraid Google's business model is incompatible with this approach as they have almost no customer service because it doesn't "scale". Actually, what they are doing is turning customer service costs into externalities, i.e. environmental waste.
This is happening in large parts of the EU as well. It's pretty mind blowing. Since the mid 2010s, the new build construction rate has slowed down to alarmingly low levels. A few years before that, there was an oversupply, yet they kept building. It's totally intentional.
Unsurprisingly, affordability is so bad. In lots of major cities, a one-bed rental takes around 50% of a mid-career post-tax salary. You have become an indentured servant for whatever real estate fund owns your property. Lots of regulatory capture behind the scenes.
Ironically, some parts of the UK, including Home Counties, are now much better than most EU, including Scandinavia, with lots of shared ownership and affordable housing schemes. It's really easy. Increasing the supply of homes, in particular first homes, and preventing predatory tactics to constrain supply.
> languages really don't matter. Just pick up the details for the paradigm
True. The best programming books also reflect this ethos. Some people think Introduction to Functional Programming (1989) by Bird & Wadler is the best programming book ever.
The language-specific details (Miranda) are limited to a three-page appendix! The rest of the book is language agnostic, provided that your target language is functional.
AFAIK, they even have some watches with no radio hardware so that they can be used in sensible environments.
reply