anandsuresh

True. IMO, this is one of nix's weak UX points. There are ways to see if it's still running/doing things, but one should not have to jump through hoops to answer such a basic question.

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. :)

+100 for technical chops, -100 for usability. +10 for the trip down memory lane, and the self-realization that I now suck at playing video games.

Pretty cool. Have been looking for something like this for a while. Thanks for building it.

Just sent you a PR for some typos I found while running through an example.

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?

So fucking good it felt like the 90s again. :)

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?

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.

Could not agree more. I've learned more about build systems and different compilers by reading through Nix code than any other endeavor in the past.

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!

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.

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?

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.

Not in any usable form. But I do intend to blog about it once I clean it up.

Not in any usable form. But I do intend to blog about it once I clean it up. :)

Congrats on your journey out of the tarpit! :)

Love to see more adoption of Nix and NixOS.

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.

Obligatory "Bitcoin would solve this!" post. :)

True. It is sad that market forces may and likely will have the opposite of the intended effect. Personally, I like the idea of having more options to have healthier competition in the market.

It is also true that the issue is very similar to the one you describe in the e-commerce world. However, I would argue that food delivery is specifically very different from most other products/services. Food is a need; not a want, and poor experience usually produces a stronger-than-usual emotional response... we have all been "hangry" at some point in time. IMO, that specific emotional response is the key differentiator. Hangry customers that are usually unaware of the nuances of the food delivery industry and its practices, usually end up blaming the restaurants. It also doesn't help that feedback mechanisms built into most delivery apps are limited (although I've seen improvements in that area in more recent times).