I've bounced off Nix a couple of times and figured that the problem is that it was too different. A lot of Linux distros (especially post-systemd) have a fair number of similarities and it's pretty easy to translate knowledge between them. NixOS _probably_ works very similarly, but it's also got this additional declarative configuration layer on top, which is the point of using NixOS, and it's got its own special way of doing things.
You can't translate Linux knowledge to a NixOS config directly, you need NixOS' documentation to understand the "NixOS Way" of doing things, and the NixOS way of doing things does not translate into other distros. And the documentation is difficult to understand and at times seemingly arbitrary.
You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. Other Linux distros help you learn Linux in general and inform your understanding of Linux system construction, but NixOS is its own thing. Plenty of people learn NixOS anyway, and more power to them, but it's definitely pushed me away.
> "and understand that you are only learning NixOS, it won't help you use anything else"
So — for one thing — in my personal case, it helped me at one time when I was experimenting with kernel build flags. With the caveat that finding how to change them was (surprise surprise) typically non-trivial in Nix in the first place... so it may be a feeble counterpoint... but still, after I found how to do it, NixOS made rebuilding new OS with different kernel flags absolute breeze, with basically 0 worry if I bork something (I mean, except maybe going to deep hardware params hacking such that would risk fraying some electronics) — I'd always automatically be just one GRUB entry away from a previous working configuration. (Though also useful to have `git commit`ed the previous /etc/configuration.nix from before I made some risky change, so that I could easily go tweaking again from there.)
I've had a similar experience with systemd itself. While you could go and read through the systemd docs to understand all of its nooks and crannies, you can actually learn the important bits by reading through the source for NixOS's modules (which are linked directly from https://search.nixos.org/options). You start to see patterns of which options they set in the units, and pretty quickly build up the knowledge you need to write your own. This is also aided by the fact that the repository is one giant git repo hosted on GitHub that you can search, clone, tweak, atomically deploy from a local branch. It buys you so much flexibility when experimenting.
This is something that is coming to traditional Linux as well though, with zfs snapshots. I've had it for a long time on FreeBSD. I just snapshot before I do something big.
I see the benefit of declarative configuration as an admin at work where we need to set up many systems the same way. For home desktop use I don't really see the point, I don't think it's a tech that fits perfectly in every scenario. Like most technologies there's usecases where its benefits shine and the drawbacks are irrelevant, and others where it's the opposite.
For example I often come across software that isn't packaged for my OS and I like to just compile them and try them out without having to do the whole packaging routine.
As to "home use", personally I'm successfully keeping my dotfiles & $HOME/bin/ scripts managed with Nix + home-manager. Becomes useful when changing jobs, and also makes it easier to share new config tricks between work & home machine. Regardless if Linux or Mac.
edit: in particular, going just Nix (not NixOS) on work machine(s) allows me to fall back to apt-get/brew quickly when a particular tool is not (yet) on Nixpkgs.
> For home desktop use I don't really see the point
Lucky that you don't need to run NixOS as your OS to get a lot of the advantages from it then. I use debian for my boring desktop applications but have Nix available to me for when I need any e.g. development tools.
This is what I used to think, but after twenty years of running Linux, and at least twice that many reinstalls, I very much appreciate an OS that doesn't eventually bitrot underneath me.
"Just install this one package to get CUDA working"... no. If I do that, then in two months when I want to do something else I'll find my OS is no longer capable of being used that way. And in four, when I want this specific version of CUDA working again, I don't remember how. The instructions probably wouldn't work anymore anyway.
NixOS allows me to put in down in terms of code, and the code practically never stops working. It's also immortal -- I've never needed to reinstall it. If I did, it'd be painless, but that's only ever happened in case of hardware failure.
> I thought it was always going to remain poorly integrated into the Linux ecosystem.
Interestingly, NixOS excels at ZFS integration.
Because NixOS builds everything from source with transparent binary caching, always upgrades your system as an integral while, and performs upgrades atomically, you'll probably not even notice that ZFS isn't in the mainline kernel as you use it. NixOS will never upgrade your kernel to one that's incompatible with whatever version of ZFS is in the repos, and it'll never leave you in a partially upgraded state where your new kernel is installed, but your new ZFS modules are not— even if you pull the power during an upgrade.
To my knowledge, the integration with the kernel is still not very good. As someone else mentioned in a reply, there are large swathes of the Solaris kernel with duplicate functionality included in the Linux kernel solely to support ZFS, because native integration is too difficult in face of the licensing and maintenance issues.
It remains a kludge rather than something that can really be thought of as an integrated Linux solution. Even if it works okay in some situations.
Is the Solaris Porting Layer really due to a licensing issue or just a ZFS portability issue? FreeBSD's ZFS implementation reportedly has a similar portability shim.¹ The new OpenZFS implementations for Windows and macOS each have their own Solaris Porting Layer, too.
If what you want is just snapshotting and you want something that's in the mainline kernel, I guess there's BTRFS. Bcachefs seems to be coming along nicely, but who knows when it'll really be ready.
I can ignore the licensing for my personal stuff (and some work might be able to, too) but from a technical perspective I find the SPL translation layer and fs caching overhead much greater pill to swallow. It’s basically bolting on Solaris as a 2nd memory system just for zfs. I really hope this hack is recognized for what it is sooner rather then later…
> This is something that is coming to traditional Linux as well though, with zfs snapshots. I've had it for a long time on FreeBSD. I just snapshot before I do something big.
This has been available on traditional Linux for quite some time with btrfs snapshots.
> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else.
This is kind of true on a surface level, but NixOS experience can be super helpful for setting up other distros because it turns Nixpkgs into a repository of high quality examples and demos that are always up to date.
Once you learn some basics of reading Nix code and how the NixOS module system works, the Nixpkgs repo itself becomes an excellent cross-distro resource on how to configure Linux software, much like the Arch and Gentoo wikis. I often consult Nixpkgs on how to do things in Linux for the purposes of configuring another distro or helping another user to do so! :)
The NixOS way of doing things (a layer on top of plain config files) is inevitable once configuration management is taken seriously: one needs to be able to merge configuration values from multiple source files; for example, a generic role plus some more machine-specific role, working together to produce one systemd unit or file in /etc. The modules in nixpkgs effectively make it possible to combine configuration values to produce most of the config files that Linux applications want.
If one weren't using NixOS to do it, it would be done with your own templates and configuration management, and probably without the huge advantage of being able to rebuild a whole immutable system without leftovers from prior configurations.
Doing programmatic configuration with a traditional distribution isn't difficult. I've got a python script that starts with a tree of config files and a top level file that says what files to consider per-machine. Each config file is run through Jinja2. Some templating even pulls data from a LibreOffice spreadsheet [0]. By default the script only pushes files that haven't been remote, so if you do deviate and edit a config file on a machine you can diff it to merge those changes back into the centralized config before overwriting.
Having said that, I'm moving towards NixOS for reasons detailed in another comment.
[0] It's ugly but it works. I'd love to find a lightweight curses-based data structure editor.
Where is the evidence for this? Where is the evidence that you can and should mix config management all of the way down the OS stack? How many containerization concepts do we need? Docker, lxc, VMs, and now NixOS? If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. I'm open to nicer restructuring of the Linux fileystem, but this is really re-inventing the wheel trying to polish over ugly parts that are ugly for a reason. Keep useful abstractions separate!
One problem that NixOS solves is to be able to use different tools on the same host in different versions easily(1) and in a reproducible way(2). Docker containers can be used to solve 1), but they are in some sense overkill and quite a few uses cases. If you are a developer who only wants do use different compilers then Docker containers are not really ideal, because they also enforce process isolation. Also there is the popular believe that Docker containers also solve 2) that is not really completely true. Yes you can run a Docker image in a reproducible way on different machines, but cannot necessarily reproduce the Docker image, at least not with the standard Docker tools. You can use Nix to create Docker images in a reproducible way.
> If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again.
The basic concept of Nix is (a) use the `--prefix` argument of ./configure scripts to keep things apart, and (b) use the `PATH` end var to choose what we want to run.
In comparison, containers are much more recent, require more invasive changes (i.e. support from the kernel), etc.
Personally, I like using containers to run binaries. Putting a whole Linux/Busybox installation inside one seems to defeat the point though...
This is why I feel efforts like Fedora Silverblue might end up becoming mainstream in the years to come rather than esoteric projects like NixOS.
I personally dislike both projects though, when it comes personal desktops. Silverblue is heavily influenced by Flatpak and I don't expect RPMs for GUI applications to survive in Fedora. NixOS needs you to learn Nix which is a pretty steep learning curve and like you said, that knowledge probably won't translate anywhere else. You're probably better off investing your time learning things like shell/python scripting, Ansible, and Docker/podman.
Flatpak and the likes are similar enough to Apple's "bundle" concept where you put all the versions, dedicated libraries and frameworks inside the bundle for your 'thing' that you want to distribute. It has been proven to work well (or well enough). I suppose the additional technology behind overlays/bindmounts etc. is different since a Darwin bundle is practically just a directory with some predetermined layout but the experience is the same.
Once it doesn't depend on (yet again) a daemon, registry, and other system-level components but is understood by the shell (or DE) instead, you get a user experience that something like Nix cannot deliver (or at least, not without cutting down on the whole "learn this language to then learn those features to then get work down" thing).
The bundle concept applies more to AppImages than to Flatpak. Flatpak downloads common runtime libraries and packages and uses them to run all GUI packages in a sandboxed environment using bubblewrap. OStree is also involved.
I dislike Flatpak because it encourages package maintainer obsolescence. I heard a guy from OpenSUSE saying in a MicroOS presentation that why create, manage, and use RPMs when we can just use Flatpak. I also don't want to touch Flatpak anymore because people from GNOME are involved in it.
I have to admit that Flatpak's runtime deduplication is impressively good, despite preferring the Nix approach.
It's a shame to hear that kind of talk coming from the openSUSE world when Zypper did so much to raise the bar for high-level Linux distro package management tools. :(
openSUSE does an awesome job getting a hell of a lot of mileage out of RPM, from the vendor-based repo management to BTRFS snapshots to the huge and powerful (cross-distro!) automated build service.
> It's a shame to hear that kind of talk coming from the openSUSE world when Zypper did so much to raise the bar for high-level Linux distro package management tools. :(
Yeah, I don't think it'll last in the foreseeable future judging by how these distros are jumping on the Flatpak/Snap bandwagon. For these distros, package management might as well be dead.
I expect a few distros, such as Alpine Linux and Arch Linux, to remain relatively free from the influence of Flatpak and that's what I'll continue to use on my personal machines.
right now NixOS is for a small subset of geeks(who are ok with using custom functional language for pretty much all configuration) but it's entirely possible to make a GUI based like a SUSE configurator based on nix, and with mature enough nix ecosystem it will work flawlessly an be powerful and simple to use for the end user
For the end user it doesn't matter if a GUI is using some nix-thing in the background. It could just was well run dpkg/rpm behind the scenes and as long as the result is the same it really doesn't matter.
This is also why Nix and NixOS painted itself in a corner; the presented value is only relevant if you are hacking away at it. When you have a smooth GUI experience it really no longer matters what the technical goodness underneath is.
I think the point is that Nix makes it a lot easier (in some ways) to build a more reliable system GUI, rather than other package managers because of declarativity being a first-class feature.
Users shouldn’t have to care what their GUI uses underneath, but it could be the difference between building your own pseudo-declarative layer (which you now have to maintain in perpetuity and handle all the small edge cases), or getting something that is already declarative as the backend and simply generating a config file from the GUI (https://github.com/nix-gui/nix-gui).
EDIT: Also composition. Users could, if they wanted to, augment the GUI generated configuration using the built-in Nix features for composition with config files, which is a lot easier than trying to do the same with traditional system managers.
I doubt a user wants or cares about any of that. User story:
As a User I want to select an application to run so that I can use the application.
This applies to practically everything, if you want to play a game, you don't want to dick around with installers, managers, layers, configurations etc. Just point and click, that's all it should need.
My main point was in the first paragraph. Users care about reliability and I was justifying why I think Nix has the potential to be a more reliable base for a GUI than other options.
I also do think certain users will care about e.g. extensibility/composabilty, as soon as they have to do anything outside of the officially blessed path. Having the ability to compose things nicely is pretty useful. It’s the difference between having to recreate the entire GUI configuration manually and just being able to dip into the config for the (likely small) non-standard part of the system.
While I agree with that, operating systems like macOS and Windows have shown that ease of use still beats other features when a user simply wants to 'do' something.
As good (or as bad) as the technical underpinnings can be, as long as the user gets what they want most of the time they are fine with it.
Nix is one big advantage of course and that is that is isn't a commercial endeavour beholden to markets and income. So it doesn't really matter what general users might want or think (at least not at this stage). We also still have the same problem that is always present and that is content availability. If a user wants to install a Netflix client but none is available, it doesn't matter how good the tools are. Even the best UX can't help when the desired content isn't available.
Nix isn't a package manager, it's a system for making ad-hoc, repeatable computing environments.
The "package manager" paradigm doesn't fit Nix that well, which is why it's a painful experience when you come to it from the angle that it's another Linux distro.
(IMO it makes more sense to think of Nix as "declarative Docker that doesn't need Linux namespaces".)
Thisss! I'm very disappointed that most people seriously misunderstand what Nix is.
Some calls it just another package manager and others dare to call it another Docker... while i'm screaming in horror internally.
Nix is pretty unlike the package managers of most popular distros, but it's not so dissimilar to other source-based package managers, like Gentoo's Portage. The basic idea that you have a giant monorepo of build recipes and a tool that automatically builds packages from source according to it is the same.
It's absolutely true that you're missing out if all you do is use `nix profile install` like you might use `apt-get install`, though.
The projects do rely heavily on Nix for infrastructure stuff, and I have to explain it to unprepared developers often.
The best angle is to explain it as "like Python venvs, except works for any combination of programming languages". That sets for correct expectation for feature set and complexity.
P.S. The single biggest huge blocker is lack of support for nix-shell in VSCode and JetBrains IDEs. Every other complaint is a minor trifle in comparison.
> The single biggest huge blocker is lack of support for nix-shell in VSCode and JetBrains IDEs. Every other complaint is a minor trifle in comparison.
> No, not really. [...] [E]xplaining it as "like Python venvs, except works for any combination of programming languages" [...] sets for correct expectation for feature set and complexity.
That's definitely a good description of the development environment use case, for people who know what Python venvs are for. It's also accurate, as far as Nix is about Nix profiles. Nix profiles are like Python venvs.
But all or close to all of the packages in Nixpkgs work just fine even if you have no profile at all set up for them— they behave correctly even if you invoke them directly from their paths in /nix/store. If you look at the install target as `/nix/store` rather than `/nix/var/nix/profiles/...`, then `nix-build` is just a source-based package manager in the ordinary sense which:
• installs each package to a unique, content-addressed-ish prefix
• uses the Nix language and Bash like Homebrew uses Ruby, Portage uses Ebuilds + Bash, MacPorts uses Tcl, etc.
• happens to have a really good build caching story
And your tools that build Nix profiles (`nix-env`, `nix profile`, `nix-darwin` and `nixos-rebuild`) aren't doing package management in the sense of building or installing anything, but instead just build convenient facades (out of symlinks) for accessing all of those packages installed to /nix/store in a more convenient way. The venv-like properties of those facades (symlink forests) just emerge from the one-prefix-per-package strategy of the underlying package manager. (In the case of profile managers that manage services, they also run some activation scripts.)
All of that is not to say that what I outlined above would be a better strategy for describing Nix to developers who just want to take advantage of environments that their DevOps team has prepared for them. I think you've settled on a really good explanation, for the reason that you outline.
If you're the Nix guy at work, you probably already understand what I wrote in this post, and have good reasons for preferring to present Nix to the developers that you support in the way you do. What I want to point out is more for the benefit of others, especially people who've done packaging or sysadmin work with other distros but maybe don't get how Nix works, maybe because they're turned off by all the FP jargon.
The lesson is this: there is an old-fashioned, familiar sort of package manager underneath the tools Nix users interact with. The essence of how that package manager is different from what came before can be boiled down to a single sentence: each variation of every package gets installed to a unique prefix. Once you have that, you can do wonderful things like build in snapshot-free rollbacks; allow unprivileged, per-user installation of packages; or generate venv-like per-project environments; and all of the other cool things Nix enables. Nix's complexity and power both follow from that one tweak, from what it took to get there on the one hand (the concept of derivations and various properties of the Nix language) and what it buys you once you have it (polyglot, venv-like setups and lots of other goodies).
The knowledge is one thing, because you can always learn how to do things the "Nix way" (either by reading the incomplete documentation or tinkering for hours until the thing works).
But the real problem is that software does not understand nix either.
For example loads of scripts expect /bin/bash to exist, but on NixOS it is missing. Want to run a random python script from github? Well that's a bummer, because there is no nix version of a random library this script uses. Also no-machine server and Chrome Remote Desktop don't work, and these are the two remote desktop solutions which work on spotty 4G.
And I had to ditch NixOS, because my employer forced me to use a proprietary VPN, and I there is no way it would run on NixOS.
For python, you're best off using a virtualenv anyways. For proprietary binaries, you can almost always get them to run using steam-run. But the nicer way is a wrapper script to set up LD_LIBRARY_PATH, or custom derivation to patch their ld lib paths.
Yeah it requires some elbow grease sometimes, but what distribution doesn't? Maybe Fedora/Ubuntu? I think the pain really is all that prior Linux knowledge is non-transferable and you have to learn how to fix things in the Nix way.
> wrapper script to set up LD_LIBRARY_PATH, or custom derivation to patch their ld lib paths.
There is your problem, I don't want to spend time writing wrapper scripts, or researching how to craft my buildFHS for every little piece of software I will run once for an oddly specific purpose.
Running the proprietary VPN on Arch Linux was as simple as running debtap, and then installing the package via pacman, even though the package shipped by the vendor was made for Ubuntu. It even figured out the dependencies automatically.
It could probably be automated more. It's just that most NixOS users have low interest in automation .deb -> Nix conversion since it's not something you actually run into often as a NixOS user.
you should not create such an imperative simlink
almost anything can be packages with nix in a minute or two, so any code you found out the internet would be easy to run and it will take not much more time than to simply check it's build config for malicious code, which you should do anyway
Maybe if you use buildUserFHS and --impure a lot. But NodeJS applications that try to download binaries at install time or python packages with conflicting package versions definitely take more than a minute or two. Just look at the history of Anki in Nixpkgs, or the derivations for JetBrains products or Cypress or any of the other packages that took consistent effort by multiple contributors to even get them working in the first place.
I think it's important to manage expectations about Nix and that includes being realistic about what's easy and simple what isn't.
Yeah, I am aware what I did above would make a lot of nixos purists shudder. But from a pragmatic pov it saves me a lot of time. It's mostly to deal with repos at clients that are filled with scripts hardcoded to /bin/bash.
I really tried making a derrivation for for the nomachine server, but it consists of a wrapper script in bash which for some reason is very long and complicated, this script calls a binary which required some libraries which were missing in the NixOS repo, and everyting assumed the program was installed in /opt/something. Then I tried steam-run, but the program just segfaulted on me when I tried. This is where I reckoned investing more time was not worth it.
On Arch I just do `yay -S nomachine` and call it a day.
But I really believe that someday the NixOS community will catch up, but currently it is not for me, since sometimes I want to get stuff done and not tinker with my system.
I played Dota2 in NixOS for years, so i am not sure why steam wouldn't work for you(it uses FHS too). You can always ask for help in discourse/matrix channel.
> since sometimes I want to get stuff done and not tinker with my system.
Plenty of people do get their work done on NixOS, so good luck with that attitude.
> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else.
As a NixOS user, I did learn a lot about what is part of Linux distributions and what is part of the kernel, and how they interact. Compared to my previous Ubuntu knowledge, of course. If I would have ran Arch, I would have learned similar things.
I bounced off NixOS a few times as well. In addition to what you've said, I also didn't find it compelling because I already had a way of doing programmatic configuration and functional system management under Debian using my own scripts. So I didn't particularly see what converting everything over to NixOS configs would get me.
What made NixOS stick is running up against some problems where Debian itself was ill-suited and seeing Nix's power. For example, building an image for a Raspberry Pi can be done with a handful of config lines. Changing between a cross compile and an emulated compile is also a handful of lines. This kind of power feels akin to the general lisp / functional curse where certain things become so easy they aren't even well documented because once you understand the system it's second nature.
Another benefit - I've modified kernel source and I've written my own modules, but they always fell by the wayside due to the maintenance burden of a compiling a custom kernel package. With Debian, I would end up reading kernel source plenty of times to figure out what was going on, but it was effectively read only. Whereas with NixOS, adding kernel overlays is straightforward. Using what is essentially a source distribution plays to the larger philosophy of Free software.
Same here. I still flock to the page every now and then and think about to give it yet another shot. But my main usecase is to develop software. I work with java, rust, ruby, JS and different other languages that needs custom treatment when doing things the nix way. Like writing a custom nix shell env file which deals with npm dependencies and the like to have all the glory deterministic package updates etc. I guess I will try it again at one point.
This is a pretty good take. Although I'd further emphasise: knowledge of Linux is "necessary but not sufficient" for using NixOS. NixOS requires additional knowledge, rather than a different set of knowledge.
I think for many developers with Linux experience, probably getting a reasonable NixOS desktop setup is straightforward.
There are some compelling benefits to Nix/NixOS, but these also require getting past a steep cliff in the difficulty curve.
>I think for many developers with Linux experience, probably getting a reasonable NixOS desktop setup is straightforward.
I took this as an excuse to try NixOS myself and an opportunity to provide anecdata.
Previous Linux experience: Lots, including about 7 years of Gentoo use, some Arch and the usual distro hopping before that. Mostly on laptops (not counting VMs). Lately it's mostly been the BSDs so I'm a little lost.
It took me about 45 minutes from searching for their site to have a working XFCE install using their minimal install ISO with VirtualBox. Certainly a different experience, but with their install guide and searching "nixos xfce" you'll get it done.
Promptly rebooted and went for an encrypted ZFS root - less straightforward but after a few PEBKAC snags I got it up in an hour or two.
My immediate impression is that this is great but not being allowed to just
# which zsh >> /etc/shells
rubbed me the wrong way. Definitely something I'll consider using in the future, seems like a good fit for i.e. a VPS you might want to move easily.
Naturally I haven't learned the config language fully, but it seems easy enough if the docs aren't terrible.
> My immediate impression is that this is great but not being allowed to just `# which zsh >> /etc/shells` rubbed me the wrong way.
Yep. That kind of thing will come up; on NixOS, root's interactive whim doesn't own /etc— `nixos-rebuild` owns /etc. But of course, both root and nixos-rebuild are you, so that's not so bad. :)
For those curious (I assume the parent poster already figured it out) the NixOS way of enabling ZSH as a login shell is the following one liner:
programs.zsh.enable = true;
which will both ensure that it is installed and on the PATH, and add it to /etc/shells for you.
As a rule of thumb, it's generally a good idea to check the NixOS options to see if there's a module defined for configuring a program before just adding it to your `environment.systemPackages`. Here's NixOS' zsh configuration options, for example: https://search.nixos.org/options?channel=21.05&from=0&size=5...
(`programs.zsh.{shell,prompt,loginShell,interactiveShell}Init` are your escape hatches; you can put whatever custom zsh scripting you want in there)
> This is a pretty good take. Although I'd further emphasise: knowledge of Linux is "necessary but not sufficient" for using NixOS. NixOS requires additional knowledge, rather than a different set of knowledge.
You can use NixOS to learn more about Linux quite well. You can't really ruin everything by mucking around at the low-level. Just rollback to previous generation. I've definitely learned a lot due to NixOS allowed me to hack with impunity.
xhyve[0] doesn't look entirely production ready, but emulates a number of devices including networking, block storage, and a framebuffer while being based on Hypervisor.framework.
Does xhyve have any support for ARM though? I remember it as being pretty x86 specific re: emulated devices and targets. A very quick glance doesn't suggest this has changed.
Java IDEs are so thorough that I learned Java from NetBeans autocomplete rather than any tutorial.
Which is not to say that my understanding of Java extends to working professionally in it; I'm a functional programmer and broadly unfamiliar with modern Java's specific patterns.
I have a distant childhood memory of a book based on this concept, in which the protagonist is projected back in time through light beams bounced off of distant mirrors. I think I stopped reading because I could tell the science was completely impossible, and ultimately just an excuse to write an historical fiction book which I didn't feel like reading. Perhaps I judged it too harshly?
As a counter-anecdote, the built in Ruby interpreter in Mac OS X Tiger was the way I learned to program and how I got interested in programming. I don't think a bare Ruby interpreter is the best way to get into programming, but Apple hasn't been great at encouraging programming among kids. As a kid, its development tools were totally baffling, where Ruby was much easier to understand.
But that's teaching a new generation of coders a set of tools designed only for Apple. Ruby (Python etc) are open and easily available on other platforms, Swift may be in the future but it isn't now.
Once you’ve learned one programming language, it’s not hard to learn a second. It’s not terribly important what you’re first language is, and Swift isn’t a bad starting point anyway.
Funny. I learned on qbasic and I
remember they were teaching dr racket at ubc to first year students. They were teaching java when I was in engineering and my career has basically gotten zero
Mileage from that stinking heap of uncollected garbage.
One of the things that drew me to Macs as I started to learn programming in '05 was that I could simply open any macbook and type python/ruby/perl and write some code.
They just pack a statically compiled Ruby interpreter with Homebrew. Not very complex or novel. Disadvantage: install becomes more bloated (larger size).
Sure, it’s not a hard engineering challenge. However, installation instructions right now are as simple as “run this one-liner on your terminal”. That’ll have to materially change.
> Sure, it’s not a hard engineering challenge. However, installation instructions right now are as simple as “run this one-liner on your terminal”. That’ll have to materially change.
It could just as well still remain a one-liner. Every system Homebrew is installed on has Bash installed (not the latest, but still).
> Every system Homebrew is installed on has Bash installed
Ironically, they are also moving from bash to zsh for default shell. Again not an unsurmontable challenge (just make sure the bang is correct in your scripts, bash will likely still be around somewhere in macOS for the foreseeable future) but another little hurdle to mind.
As far as I'm aware they're not changing anything about which shells are installed or which executable /bin/sh points to they're just changing the default login shell for a new user, so nothing should have to change about the scripts that are (or have been) written.
I had the opposite experience with AppleScript - the development tool (Script Editor) was simple enough for me to understand that it was the way I taught myself to program when I was 13.
(OK, I learned Logo in school when I was 7, but programming became way more interesting when I discovered AppleScript's APIs to control all the programs on my Mac).
Sure... but that was then. I too had a real hard time learning Ruby back in the day. But now if you google any Ruby or Rails how-tos they will include a one-line Brew and RBENV install.
So I get what you are saying but I think we are in a new world here.
To name one, trans people. It's my understanding that prescription drugs are carefully controlled in Dubai, and HRT is not permitted, and carrying HRT through Dubai can get you arrested and thrown in jail.
I'm a generalist programmer with strong vocational experience in web application development and additional experience in graphics programming, systems programming, and functional programming. I've worked in startups and large enterprises. I'm a junior programmer, but I've been programming in some respect for over a decade. I love learning and mastering new technologies and languages.
Location: Silicon Valley
Remote: Both
Willing to relocate: Yes
Technologies: Rails, Rust, Go, Elixir, Web, Python, Java, Unity, Lisp
Résumé/CV: https://atamis.me/downloads/resume.pdf
Email: atamiser@gmail.com
I'm a recent graduate looking looking for my first full time position. I have a broad base of experience, with a vocational focus on web application development. I've been programming since age 9, and I really enjoy solving technical challenges of all sorts.
I'm currently working on a bytecode compiler, a game in Unity, and some data analysis. Email me if you'd like to talk.
It looks like it was for fun. The author has several repositories on Github holding Lisp interpreters in different languages. It might also be a learning technique: interpreters for higher order languages are good intermediate projects when learning new languages.
You can't translate Linux knowledge to a NixOS config directly, you need NixOS' documentation to understand the "NixOS Way" of doing things, and the NixOS way of doing things does not translate into other distros. And the documentation is difficult to understand and at times seemingly arbitrary.
You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. Other Linux distros help you learn Linux in general and inform your understanding of Linux system construction, but NixOS is its own thing. Plenty of people learn NixOS anyway, and more power to them, but it's definitely pushed me away.