This is the secret level (E1M9) that you'd normally encounter after E1M3. By this point in the regular progression you'd have found a shotgun, chaingun, rocket launcher, and probably some armor. Starting this level with just a pistol (and it looks like maybe U-V or Nightmare difficulty) is just begging for a buttwhipping.
This is why I like Doom and Doom II, you can just level skip to a level on Ultra Violence and just start blasting, It's good for a quick game compared to War Craft 2.
E1M5, E1M7 are also good levels to skip to on Ultra Violence and start blasting, Using respawn on Ultra Violence also makes it interesting for E1M5 and E1M7.
Didn't realize that was a thing. Was using the keyboard the whole time. Took a few tries to figure out how to strafe... and then just kept the spacebar pressed the whole time, and cleared the CAPTCHA. :)
I was able to do it without this, but this made it much easier. However, it would be much better if the strafing keys were on the left side of the keyboard. You can bunch your hands together and use your left hand for <, >, and space, but it's awkward.
They are, kinda. The default Doom keybinds have ctrl as the fire key, space as the "use" key, and alt as a modifier that turns left/right arrows into strafing. So when you play like that, your left and right hands are separated.
Yeah, amusingly, I use a keyboard that doesn't have arrow keys. I've bound them to a different layer, but that doesn't work well with this setup.
If this implementation supported the now-standard WASD (which was absolutely used by some high-level Doom players back in the day) AND if it allowed me to fire using the left mouse button (again, like the original game), then it would have been relatively easy to prove that I'm a human. :)
Not sure if wasd was used by high profile Doom players. You see, there weren't many keybinds. You had ctrl and alt for shoot and strafe (fun thing to do was press del casually on a player's keyboard, like Russian roulette, then be like 'WTF crash?'), and you had the arrow keys for movement. Then you had 4 keys for weapons in Wolf3d and some more in Doom. Swapping those required travel, but IIRC swap wasn't instant. So, no crouch, no jump, no look up or down, not even reload IIRC. Games utilizing wasd were usually multiplayer games. One would sit left, with wasd. One would sit right, with arrow keys.
Vanilla Doom had a configuration file where one could redefine key bindings (there was 10 total) to anything player wanted. But, yes, I believe custom configs were uncommon (even mouselook was frowned upon amongst the players I knew[1]) and modern gold standard of WASD+M only became a thing after Descent and Quake 1.
[1]: For a childish reason - being considered not a "true" way of playing. Although maybe that had some rational roots too, because back in the day mices weren't particularly good - bulky with heavy balls and imprecise with lint-hungry rollers and simple low-resolution sensors.
Option what. I am trying to solve a captcha on a mobile phone. I have 4 buttons on left of screen (equiv to wasd) and on right I can shoot. If I go back the imp (IIRC that was its name) cannot hit me, so I can easily shoot the cannon fodder coming from the right. Gg. But no strafing!
I can relate to a lot of what you've said here. I've built a similar super-generalist profile in software engineering and have spent the last decade in startups.
Compared to my peers/friends in larger companies, I've always had far less politics/BS to deal with at work. I would not say its non-existent; sometimes all it takes is one bad hire, and the smaller the startup the more outsized the impact of the bad apple. So in that sense, impact is a double-edged sword.
On the other hand, I've been able to build a super-generalist profile because of the startups I've worked at. Backend-engineering, frond-end stuff, DevOps, hands-on data-center experience, automated QA, SRE, growth hacking; you name it and I've probably checked that box off at some point in the last 10 years; mostly because I've been able to cultivate good relationships within the company to be able to move around different roles. This would be impossible in a large company, even with a lot of personal connections. A few jumps are possible, but not the kind I'm describing above.
The smaller size of startups also means that you have fewer people between yourself and key decision-makers. I've had the good fortune of being able to work directly with/report to CXOs for over half a decade, which IMO provides a lot more exposure to understanding how a business operates. I would not trade that for working with mid-tier management in most large companies.
With regards to not being appealing to large companies, I'd say that is not true. I've known folks who've moved from startups to FAANG companies in their mid-40s without any issues. The experience always counts. You may lack some of the specialization, but you can always compensate for that with breadth of experience.
Ultimately it boils down to what you want to accomplish. If your goal is to eventually start your own business, working at startups is a great way to get the requisite experience. It is definitely not a walk in the park though. Being able to work with little to no direction, constantly changing goal posts, and the lack of any structure does take its toll on you slowly, but surely. However, I can say from personal experience that I don't regret it one bit.
I understand and empathize with the sentiment here. Interviews have a skewed power-dynamic. A handful of people, or sometimes even a single person, can make or break your chances at what you feel is your dream job, and there is nothing you can do about it. It is an extremely frustrating place to be in, indeed.
I've had people with half my years of experience, ask questions that were likely from an algorithms course they took during their (under)grad school days, with little regard for its applicability to the role. These are the kinds of red flags I look for, and while I am yet to walk out of an interview, I do make it a point to provide feedback to the recruiter, along with my decision to withdraw from the process.
It is also pretty telling when a company fails to account for the candidate's experience. At best, it shows a lack of experience with recruiting; at its worst, it is a good indicator of poor culture. Having a person with 10+ years of experience write a quick-sort algorithm is unlikely to produce a good result; mostly because any engineer with that kind of experience would not really write a sort function by hand, unless working on a very low-level system (and even those are mature enough to have an optimized sort function readily available for use).
Like interviewing, conducting an interview is a skill that needs to be developed, and any good company would take measures to ensure it does a good job of it. Recruiting, after all, is a pretty expensive affair.
You've likely dodged a bullet there. Count your blessings, and move on to greener pastures. :)
I'm curious about the legality of such practices. Your employer needs to authorize what you do on your own time and dime? What country/state are you located in?
This is a bandaid that avoids solving the harder problem of trust/spam. It is such design patterns that make a fundamentally open/federated protocol more centralized, exacerbating the problem.
Personally, I think the use of proof-of-work like methods can mitigate the problem by a large extent, making it computationally expensive to spam users. This was one of the original goals of what has now become the "blockchain" revolution. Is anyone aware of any projects that are still implementing similar (open) systems?
I am happy to be proven wrong here (not an expert) but IMHO there is not much hope or solving the open decentralised communication problem with email at all. It seems that something like Matrix.org presents much more promise in this area. I also host my own Matrix server, but sadly not everyone I need to communicate with uses Matrix....
About time this happened. I experienced this with the ACLU, of all the entities out there using this dark pattern. Enable subscriptions online to donate to the ACLU, but if you changed your mind, you have to get the phone to cancel. Needless to say, I just let my credit card expire.
I started my Nix journey a little over a year ago, and I regret not having switched sooner. A package-manager that also ships an operating system that can be customized from the bootloader up, using a purely functional programming language is the perfect configuration management tool!
It does have some rough edges, and I did lose some hair figuring things out early on, but it has been getting better with each passing day. Pretty much the entirety of my setup at home is now built by Nix and runs NixOS, including my Macbook Air (runs NixOS on ZFS), and two Mac-Minis that PXE-boot a custom NixOS served by a Raspberry Pi 4 running a custom NixOS configuration that also acts as a firewall connecting wirlessly to my ISP's router. The Mac-Minis also double as build machines which makes for a pretty smooth experience when I'm building anything on my work laptop (a 2020 Macbook Pro running Big Sur) that I dock with my CinemaDisplay, which is wired thru an unmanaged switch to the rest.
So far I haven't missed any packages that I could not find in nixpkgs, or customize just the way I wanted to. The community is pretty responsive and quick to merge any pull requests for fixes/upgrades. I would whole-heartedly recommend switching to Nix/NixOS/Nixpkgs.
Same. I've been meaning to take the time to learn and switch to NixOS for several years now, and finally had some time to do it this past spring.
I haven't been this happy and giddy with a new piece of technology since I completely eliminated Windows for Ubuntu back in 2009.
There was a learning curve that took several months, but now that I've got everything I had on Ubuntu running smoothly on NixOS, I could never go back. And this for my daily driver, not a server or anything.
My favorite part is how it enables rapid experimentation with different build configurations, without any concern about borking the current working build.
If the new build breaks something, a single command rolls it back to the prior working build.
If the new build crashes the system, just reboot and choose the prior working build in GRUB. When you're logged back in, call the rollback command to point the system back to the working build.
This makes learning and testing both Nix itself and your particular system build faster, easier, stress-free, and just downright fun, which is invaluable.
Declarative, deterministic, immutable OS builds is a significant step out of the tarpit of software complexity.
I switched to NixOS half a year ago. The reason? I fell in love with literate programming (I use [1]); being able to write (and read) your whole OS configuration is the dream!
There are few bad sides to NixOS though.
The community consists mostly of programmers, which means I am missing some creative tools (mockups, mindmaps, ..). In the future I will be able to provide/build them myself, but it is not a smooth transition from my previous arch setup.
Also the whole documentation sucks: There are three (!) official manuals + the home-manager manual + Nix pills + YT + random blogs where I have to piece everything together.
Still I find NixOS superior to every other OS (windows, linux) I have tried so far. I just feel free and am not afraid to fuck up anything [2], as I can just go to a previous generation when it doesn't boot.
Lastly, I can save my whole config in git and am free to try new tools -- If I don't like them, I just remove their line in my config. No more chasing after random install folders! (Except in home..)
I really like the idea of NixOS, but there not being a single clear guide of how to set everything up (and the messy documentation) is the biggest thing holding me back. I also really don't like wasting so much time on tinkering with my system the way I used to do.
But I'm seeing so much Nix news these past few weeks, I guess it'll be better in a few years!
I think you can get going with little to no knowledge. Setup the system, choose a few cool options and packages, and go rebuild. Simple as that.
The difficulty comes from the advanced topics. Modularizing your setup, writing your own packages, generally going off the beaten path.
I did not do any of that (yet). I will in the future, but I am fine with my low-level setup. One machine, one user. A bit later I moved to Nix Flakes (which is just an additional wrapper file around the previously written config) and added a few overlays.
My trick: I downloaded every single public "NixOS" dotfile repository I could find, and then just used "ripgrep" to find anything I was interested in.
Another cool trick I read is setting up a VM to test a small config and get a feeling for it, and then decide if yo want to proceed.
NixOS' saving grace when it comes to the learning curve is that experimentation is extraordinarily safe, thanks to the declarative config and rollback functionality. If you don't know what you're doing, you can pretty painlessly get away with just fucking around.
Not just that. The ability to enter a sandboxed shell environment, play around with as many packages as you can get your hands on, and then exit back to my clean machine is my absolute favorite feature!!!
SO many times in the past, I'd be concerned about installing new things because they'd break my otherwise pristine developer environment. Yes, rvm/nvm/virtualenv and others help, but they fail to hold a candle to the nix-shell!
>I really like the idea of NixOS, but there not being a single clear guide of how to set everything up (and the messy documentation) is the biggest thing holding me back.
Yeah this part is messy, and why I always disclaim that I had a learning curve of several months to make the transition. However, my system setup is a little more complex than the standard install - mirrored ZFS root drives on dual m.2 drives, with mirrored boot partitions. That wasn't in the docs, needed a blog post to explain it [1].
>I also really don't like wasting so much time on tinkering with my system the way I used to do.
I've found that once you get everything configured to your liking, you spend similar or less time tinkering than on other OS's, just because the entire system config is captured in a single config file now. There's some up-front learning and work required, but after that it's smooth sailing.
Anyone looking into transitioning to NixOS should take a leisurely weekend and just read through all three of those first. Being at least familiar with all of what's there will make getting up and running a lot smoother.
>The community consists mostly of programmers, which means I am missing some creative tools (mockups, mindmaps, ..). In the future I will be able to provide/build them myself, but it is not a smooth transition from my previous arch setup.
Any time you need a package that's not in nixpkgs, feel free to submit a packaging request for it:
Especially if you explain that it's a popular tool in the creative community, that kind of thing is useful for the Nix packaging team to be made aware of. Even if someone doesn't package it right away, there's a good chance it will make it into the next 6-month release cycle.
That sounds like a nice way to do it, too. I heard about it before, but don't know R, so I didn't really consider it.
The reason I chose lmt is that it correctly keeps the markdown language syntax of the code blocks. That means I can put my literate config into my Zettelkasten [1] or [2] and watch it pretty-print in the browser.
There are also literate [3] and org-babel [4], but I don't think they are future proof. .lit is a random format and .org basically requires Emacs+orgmode.
For lmt/markdown: I believe yes, to the extend the editor allows for it. It is seemingly just like regular mardkown code blocks. I get the correct syntax high-light in the ``` code blocks. I don't have lint/LSP setup yet (currently moving to Neovim), so I can't say anything about that.
Literate/.lit: I don't know, I guess not.
Emacs/orgmode: Yes, this also does syntax highlight. And you can edit the code-block in a separate window as if it was a "real" source code file. I've been using this for almost two years now. Personal opinion: I don't think the benefits of Emacs outweight the cons.
"not afraid to fuck up anything" likely refers more to the ability to rollback the system to any (non-deleted) previous revision of the system configuration, directly from the bootloader, which means you can easily recover even from a broken kernel.
This applies regardless of whether you are packaging/updating something in the package set yourself, or using something that someone else packaged.
No, you can get the installer directly from the NVidia website, but only for selected platforms. If you're on a different platform, you'll have to wait until somebody ported (read: hacked) the release (or do it yourself).
Hate to make a boring me-too comment, but I feel the same: I've been using it a bit over a year, and I wish I had started even sooner. Now I've got two laptops and a NUC, plus two odroid-hc4's, all on NixOS. All the system configuration that used to be half-broken ansible and a pile of scripts (plus all the one-off hacks that weren't even captured anywhere) is now nice pure nix configuration. I've nix-ified builds for a bunch of personal projects too.
Yeah, it took a few months to learn, and there are still lots of rough edges, but going back to a non-Nix linux distro would feel like going back to windows. I agree with the sibling comment that it makes me feel happy and giddy, like no other technology I've learned recently.
> So far I haven't missed any packages that I could not find in nixpkgs, or customize just the way I wanted to.
And it's honestly not that hard to package things that aren't yet Nixified. Any C project is easy - I've learned more about cmake from mkDerivation that anywhere else.
And overlays make it easy to make tweaks to a build without straight-up forking. Beautiful!
> I've learned more about cmake from mkDerivation that anywhere else.
This is something I find really fascinating about Nix (or more precisely nixpkgs) that gets overlooked a lot: it is essentially a giant database that documents how different build tools work, how different projects are built, and so on, in an exhaustive and consistent manner.
That can be an extremely valuable resource to have in your back pocket, even if you're not actually using Nix!
I always think it's worth mentioning explicitly that NixOS makes it not just possible to put everything including the root file system on ZFS, it makes it completely easy.
It's not unique at that though. FreeBSD has had this for a decade. And Ubuntu is adding it now as an installer option.
PS: I do like the idea of NixOS and its USPs which are indeed unique :)
For me what's stopping me is the learning curve. I don't mind learning per se but if I put the time in it I'd like it to be for something that's useful in more places. Like ansible.
What's interesting about NixOS' seamless NixOS support is that ZFS can't be included in the Linux kernel, and so that kind of integration takes more work with Linux distributions, so relatively few distros have it down pat.
BSDs don't face that kind of integration challenge, since they can just ship ZFS support directly in their kernels. They have recently faced an integration challenge of their own, though: rebasing their ZFS implementations on OpenZFS (f.k.a. ZFS on Linux).
Anyway ZFS is great and I hope OpenZFS' multiplatform support gets so good it can become popular on Linux, *BSD, and macOS all at the same time. :D
Can you elaborate a bit more on why ZFS is great? I am currently thinking about doing "one final install" for my system, and am undecided between BTRFS and ZFS.
I noticed that most "hip" people use ZFS, but based on my meager research it seems actually recommended and designed for "big" data-center setups.
Why is ZFS good for small PC setups?
---
If am being honest I just want something that works reliably, is easy to extend and doesn't require maintenance. Maybe ext4 is good enough?
If you have a single disk, BTRFS is probably as good as ZFS for you.
ZFS is mature and featureful, and it's easy to performance tune specific subdirectories using 'datasets' (on BTRFS you can do some of the same stuff with 'subvolumes'). It has good utilities for backup, including over the network. It always supports up to date, efficient compression (these days, zstd). It's good at pooling, so you don't need LVM if you want to be flexible about 'partitioning'.
One genuine advantage it has over BTRFS other than stable softraid support is that it's cross-platform among Unices, including (in incipient form) even macOS. So experience you gain in administering it would be transferable that way. (OTOH, Windows has a pretty mature BTRFS driver, but ZFS on Windows is even more recent (and difficult) an effort than ZFS on Mac).
Truthfully, ext4, BTRFS, and ZFS are all fast and stable, and once you set them up your filesystem, you'll probably hardly think about it. (If you go with ext4, I'd set it up on LVM to make it easier to extend or 'repartition' in case you wanna structure things differently or add another distro or whatever.)
Linux's heritage and continued use as a server OS makes it rich with fast, reliable, flexible, feature-complete filesystems. All three of your options here are better than what's on offer on any Windows or Mac desktop, so you kinda can't go wrong, so don't overthink it. Just pick something you feel like learning or whose documentation strikes you as agreeable and interesting. Whatever you choose will serve you fine until your disk dies or you get bored. :)
> I don't mind learning per se but if I put the time in it I'd like it to be for something that's useful in more places. Like ansible.
Depending on whether you mean "used by more people" or "applicable to more problems"... if the latter, tools like morph or NixOps might be of interest to you, which essentially extend Nix to "across multiple remote machines", which means that de facto you end up with an orchestration tool like Ansible or Puppet.
>It's not unique at that though. FreeBSD has had this for a decade. And Ubuntu is adding it now as an installer option.
Right, but FreeBSD isn't Linux, if you want both ZFS and the Linux ecosystem, then I would argue NixOS is the best at that right now.
I tried Ubuntu and ZFS recently in a VM just to see how it worked. The installer handles a simple, standard ZFS config just fine. But if you want to do anything more complex, then you're doing manual configuration, at which point it's better to just use NixOS, where all the manual config is done in the main NixOS config file.
#MeToo. I am using two OSX machines and two remote Linux machines for my day-2-day private/work related stuff.
Nix+home-manager allows me to have all productivity tools consistently available across all platforms with minimal effort [1].
Dotfiles/shell config lives in a separate folder [2] and is not managed in nix.
Tangent: Secrets are are encrypted with git-crypt (https://github.com/AGWA/git-crypt) and live in the same repo [3]. I generate GPG keys for every new host I am working on and check in the public keys to the repo as well, then "approve" them from an authorized host using `git-crypt add-gpg-user ... && git push` [4]. This gives strong encryption without managing passwords by hand. [Copy of private key is kept in bitwarden as backup].
Getting the hang of Nix took me a while. I wrote-up my journey to get the latest-gratest emacs installed here [5]. But now I am over the bump, and it's adding value to my workfows. E.g. I switched some projects from docker to nix-shell for lightweight virtual-envs, e.g. [6].
I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.
[0] which are already an overengineered and under-delivering solution in my opinion.
> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.
This is fair, but keep in mind that package managing is only a small part that what Nix solves, and it is a much superior solution than anything else that I know (Docker for example is not really reproducible because you can't trace all dependencies; this seems like a philosophic issue but I saw some containers breaking because some dependency inside the container was updated without nobody knowing).
If we take NixOS, it also solves the issue with configuration, and with some auxiliary tools it also solves issues with deployment. You have alternatives for both of the issues too, but the fact that NixOS is much more integrated than any tooling (like Ansible, Puppet, etc) means you have much more flexibility. Also, don't forget atomic upgrades and fallback.
Eventually, instead of "wasting time", NixOS starts to save time by becoming the most reliable OS you ever used: you will never waste time anymore reinstalling your system from scratch, or if your hardware broke, you will never waste days trying to get your system to the same way it was. Also, because nixpkgs is enormous, you also tend to save time by not looking at "oh, this program seems cool, how can I install it on my computer since I never heard of this XYZ language?", and them installing the package manager from the language in 5 different ways because you have no clue. And even when you need to package the program yourself, nixpkgs has many abstractions that makes it much easier.
So instead of wasting time, Nix and NixOS is an investment. You may choose to invest your time right now to save later or not. Either way is fine.
Just to finish the topic, I fully concur yo you that we as a community needs to have better documentation.
That's absolutely fair, I don't think either the parent or the NixOS devs implied in any way that it should be the right fit for everyone or 100% of the Linux distro market share is the end goal.
For me, the benefits outweigh the quirks of the language. As my alternatives to manage multiple machines consist of: wonky Bash scripts, similar tooling but bolted-on on top of the distro and with no built-in rollbacks (Ansible, Puppet, etc.), or trying to get everything right manually, Nix does not seem like the worst out of this bunch.
What I'm hearing is "I really don't like the way traditional systems are designed and I don't want to have to learn anything new!"
Nix is different, unapologetically so, that's the issue. And if it had to be more orthodox to win over a few more itinerant users that would make the whole thing pointless.
I'm not asking it to be more 'orthodox', I'm asking to not have to spend months scouring poor documentation to learn a new language and toolchain to gain the very few benefits Nix provides over the existing systems. If Nix is so inherently complicated it cannot deliver that, then why would I want it?
Ultimately I want less complication in my life, not more, and Nix very much does not provide that from what I can see.
Traditional systems have complexity too. Its just not up front.
I like to compare it to fossil fuels and global warming. Traditional systems get one started quick, but eventually build a large fragile system that gets harder to fix/rebuild the longer it goes on.
Nix is different, it forces you to do your work upfront. But once setup, you pretty much can (and to my attestation do) forget it is in place. You do have to learn setting a anything a and everything. But you only do it once. If the house burns down, you don't need to remember what you had. You don't need to remember what to setup in what order. You don't have to find out you forgot something in the middle of something else. In other words, the onus is no longer on you.
That last sentence is incredibly liberating. I stopped worrying having black screens after updates and pretty much stopped having rescue disc, because rescue functionality comes built in the system. It sounds cultish, and it kinda is, but as I said in previous comment on Nix, it is the worst system management tool, except all the others.
Oh, I use Nix because it does provide less complication in my life. It's just necessary to wrap your head around a few core principles first, which can be a little mind-bending when you start out (no fixed /usr locations? huh?)
It is like saying I don’t want spending months to learn git to gain the very few benefits of a version control system. I much prefer to share my code with my coworkers via usb-sticks. Yeah this is less complicated in the short term.
I honestly don't want to learn git precisely because there are version control systems that accomplish the things I need in a much simpler way. I only bother using git at all because some FOSS projects I've worked with use it. Hell, my impression is that most people who use git don't bother really learning it, they just keep a recipe book of how to branch, commit, etc. and then rely on stack overflow to un-fuck the repo after they accidentally blow it up.
I could not agree more. Most people, IMO, are workflow junkies! It doesn't matter how good/bad/ugly the tool is; if it works, it stays forever! And git is a perfect example of a tool that is complex, but survives because it became the gold-standard for FOSS.
Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?
Yes and for the same reason: people don't want to deal with systems that are overly complex for their needs, and OS configuration (especially in Linux) tends to have a ludicrous amount of needless complexity.
But the thing about Nix is that it just adds even more complexity. As was mentioned elsethread, in order to be effective with Nix you need to understand all the complexities of Nix and Linux. And the thing about Linux is that we have a ton of adequate recipe books out there already.
Complexity exists and is going to get worse with time. The root cause is the prevalent software development paradigm: millions of developers/teams working simultaneously on different parts of the software stack, with an imperfect understanding of an ever-evolving system. "Needless" therefore is a matter of perspective. Reasonable defaults and recipes are a proposed way of dealing with said complexity, but what is reasonable is again based on imperfect understanding, and is therefore only going to work under specific conditions that are not written in code.
Nix offers a way to easily customize and override said "reasonable defaults" across packages written in different programming languages and compiled using a variety of build toolchains. Doing so requires using a common language for expressing defaults and overriding them. IMO, that is not adding complexity, but taming it to make it reasonably easy for individual developers and teams, small and large.
I'd argue that the traditional stack relies on way too many tools, each designed for a limited purpose, and making a LOT of assumptions about the target system. This IMO is far more complex than learning one language and framework.
> But the thing about Nix is that it just adds even more complexity
It absolutely doesn't. I'm someone who is fairly fluent with Nix, and in comparison the complexities of running a non-trivial docker-compose setup gives me nightmares. Luckily I basically never have to worry about that though.
Nix operates at the cusp of some of the most complex and obscure parts of the technology stack: operating systems, compiler toolchains, and package managers. These inherently complex components require a fair bit of commitment to fully comprehend in order to be used well. You can get a lot of mileage skimming through some tutorials to become productive, but to really utilize it to its full potential requires a fair bit of investment. You don't have to be an automotive expert to drive a car, but if you're looking to race, it behooves oneself to invest the time it takes to gain the expertise.
Nix takes a very different approach to system configuration than the traditional ways. Because it treats the entirety of the operating system (bootloader, kernel, user-land, services, account management, etc.) as a single composable unit, it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone. The deviation from the Unix Filesystem Hierarchy is, IMO, required to make systems more composable and maintainable, and is inherently a good thing in the long run. Portable development environments eliminate "works-on-my-laptop" scenarios and ensure everyone on the team is always in sync with each other and CI/CD. Reproducible builds that can be rolled back after a botched deployment are a huge win. And delivering all of these features in a single tool requires breaking some of the old rules, and that is always met with resistance due to the inertia of "it works fine for me".
To be honest, there is no reason why you should give up what works well for you. Having said that, for those that are looking beyond the traditional tools like shell-scripts, Ansible, Chef, Puppet, and others, Nix offers all that is needed to easily build and maintain composable software stacks. Docker comes close to delivering some of the same features as Nix, but comparing the two is a bit like comparing system configuration using shell scripts to Chef/Ansible.
Yes; one does have to learn a new language and its idiosyncrasies. But that is also true of things like Rust. As a seasoned C programmer, I am able to write "good" C code. But that is not a statement about C's ability to scale to larger teams. Rust requires developers to give up their old ways of thinking and "give in" to the Rust-way. The longer you fight the borrow-checker, the more painful it gets. But once you give in, you are able to write code that is safer for use within large teams, thus delivering more momentum in the long run. It is not that it can't be built with C; it requires a communal way of thinking about software complexity that is forged by experience and tempered by camaraderie, and tools like Rust and Nix are excellent supplements.
I do agree with you that the documentation leaves a lot to be desired. I've always considered the FreeBSD Handbook to be the gold-standard for technical documentation and Nix has its work cut out to reach that stage of maturity. But I have full confidence in the Nix community's ability to deliver.
> it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone.
On the other hand, one of Nix's greatest strengths is that in many respects, its innovations are conservative. It brings software building and distribution forward in terms of reproducibility and isolation (like containers do) but (unlike containers) also retains the traditional package management virtues of granularity, efficiency, and sharing common resources (dependencies) when possible.
> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to [do development work]
This is pragmatic.
Nix somewhat reminds me of the kinds of mindsets that enjoy learning Vim/Emacs, or learning how to use 40%-sized keyboards like the Planck. -- I think it takes curiosity to be interested in that kindof stuff.
I agree. I love the idea of Nix. At least what I think is the idea - basically Bazel as a package manager. But the actual implementation is inaccessible.
If someone could make a user-friendly implementation of the Nix concept I think it would be very popular.
While there are definitely a lot of remaining documentation and usability issues with Nix as it stands today, the core model is far from 'overengineered' - if anything, it's orders of magnitude less complex than the organically-grown cobbled-together pile of tools and conventions that 'traditional' distros are made out of.
Nix having a well-defined, complete, specified-upfront, coherent model doesn't make it 'overengineered'; it just means that the tools were designed from the start to help you manage the complexity of system management, rather than just kind of leaving it implicit and letting the end user and/or packager deal with the fallout later through an ever-growing collection of workarounds and patches and scripts.
It's completely valid to decide that NixOS is not (yet) for you due to the learning curve that still exists; I frequently warn people away from NixOS (when they are not prepared to deal with that) for this precise reason. But please don't conflate that with 'bad design'.
> [package managers] are already an overengineered and under-delivering solution in my opinion.
This is kinda nuts to me. Every time I use a system that doesn't offer proper package management, it makes me wish I had a decent package manager. What do you think is better than a modern package manager for solving the same problems?
This super interesting to me as I am currently PXE booting Ubuntu which is a pain every two years when I switch the new LTS release. Do you have some pointers or configs to your setup?
There’s a small amount of homelab stuff I need to spend the time porting to nixos. Grafana is in there, for example, but pihole is not. I currently run a weird mix of VMs because of this, and I’d like to make that more homogenous.
