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.
455 karma · joined December 27, 2011
Just sent you a PR for some typos I found while running through an example.
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'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. :)
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?
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!
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.
Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?
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.
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.
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).
> Indexing and aggregating data is already covered by numerous laws. If Google can aggregate restaurant listings without permission then why can't others? Linking is ok, showing a call button is ok, but delivering isn't?
Searching for information on the internet and having food delivered are not the same experience; I'm usually not "hangry" when my search results take too long to come up, and/or are not what I was expecting. Even so, I usually blame Google for the bad results. It "should" be the same for food delivery services as well, where people "should" blame DoorDash/GrubHub, but that rarely happens. For better or worse, it is the restaurant that takes the blame, and risks losing future business.
Most people I have spoken to regarding this issue were under the assumption that the delivery service already had agreements in place with these restaurants. A lot of these people are business owners themselves, and were surprised to find out that no such agreements existed; much like I was when I first found out about this issue.
> The law around copyright is clear: you can't copy a restaurants menu without permission the same way you can't copy someone's blog post. This should be enough.
True. It "should" be enough, but in practice, it rarely is. Most companies operate knowing that legal processes are lengthy and expensive and take that into account when modeling their business practices.
> Why don't restaurants want delivery companies doing this? The typical argument is bad Yelp reviews. Instead of blaming delivery companies why not blame Yelp for not authenticating their reviews?
When you're a small-business owner losing business due to the activities of some third-party service you did not authorize to represent you in the first place, you're usually not looking to blame another third-party service for the bad reviews you didn't know you were getting; especially one whose "business-model" was to blackmail restaurants to take down bad reviews. As a business owner, it is my right to know my customer and know anyone who is (mis)using my brand without my permission.
> Restaurants should be benefiting from delivery companies distributing their products, and there is nothing preventing them from offering direct to consumer deliveries themselves.
A handful of restaurants I order from on DoorDash/GrubHub usually have their own delivery crew. It isn't a requirement for every restaurant to offer delivery. Elsewhere in this thread, there was the issue of certain food items (usually the restaurant's speciality) having very precise kitchen-to-table time requirements. It is hard for a restaurant owner to control their product when they don't have any control over the delivery process. And when they choose to not have delivery, they are bypassed entirely by these third-parties. Seems perfectly fine for the restaurant to fight back against such practices.
EDIT: fixed typo
It was a great place to start off my career, but sustaining it as a business was always a challenge. Sad to know that it has deteriorated to this point now.
PoW has proven itself in the field for years, while PoS is still untested at scale. Being able to piggyback scientific/medical/environmental computation over a PoW scheme would provide significant value as opposed to a fairly useless compute problem such as the double-SHA256.
The key here is to be able to re-interpret/re-state a problem in terms of the PoW algorithm with the following characteristics: - Expensive to calculate, cheap to validate - Dynamically-adjustable difficulty
An ideal implementation of this would be similar to an OS running an idle process (double SHA256), and switching to running user-processes (medical/scientific computation) when needed/instructed.