Nix in production is more common than you think, even at scale.
It's hard to know what exactly your security concerns are here, but if you look at the current ecosystem of using containers and package registries, Nix is pretty clearly a solid contender, security-wise.
Plenty of wildly unsafe behavior is common in production infrastructure today. This is also why compromised corporate infrastructure is in the news so often. Few orgs hire or even contract security engineers with Linux supply chain and hardening experience, opting to blindly trust the popular options and their maintainers.
NixOS knowingly discards vital supply chain integrity controls to minimize developer friction and maximize package contributions. It is a highly complex Wikipedia style distribution optimizing for maximum package variety which is absolutely fine and great for hobby use cases, but use in security critical applications is absolutely irresponsible.
Guix goes some big steps further in supply chain integrity but still ultimately trusts individual maintainers.
Long article, but the fundamental premise is that IMAP, SMTP, and POP are all you need. And that email clients are good... This is just false IMHO. There is a reason why both Fastmail and Gmail implement their own protocols in addition to those.
But fundamentally the "folder" view of email does not work. A single message often needs to be in several different folders simultaneously. And when the thread is spread across many folders, there needs to be a way to see the whole thread.
The only way to accomplish this is with email tags or labels. These are implemented by nearly all successful email companies. Gmail, Fastmail, and Proton are examples. Labels are a fundamental feature in this day and age, and neither IMAP nor POP can handle them gracefully.
Gmail is so big that when Outlook, Apple Mail, and even Thunderbird connect to it, they do an OAuth exchange and then talk over a proprietary protocol.
JMAP may have poor adoption, but it's the only open protocol that understands labels well. The lack of adoption is mostly due to email providers not implementing it. There is not a lot of incentive for clients to implement it for the few providers. And providers would prefer you use their web clients anyway, as then they control access to your email.
> Gmail is so big that when Outlook, Apple Mail, and even Thunderbird connect to it, they do an OAuth exchange and then talk over a proprietary protocol.
>A single message often needs to be in several different folders simultaneously
Just No. This is by far my biggest complaint of using Gmail.
It makes it impossible to write rules to file mail into folders as all you can do is add tags (labels). Whereas to _move_ you require the ability to unset and label which tags/labels don't support as thats a definining function of a folder.
Make Email Great Again! Now thats a campaign i'd be willing to fund!
This again is a limitation of mapping labels to IMAP, which does not understand labels.
Both the Gmail web interface and the Gmail API allow the ability to set all the labels for a message. This can effectively enable your desired functionality. But IMAP can only deal with "folders", and cannot correctly decide when to remove a single label or remove all other labels when it sees a move action.
IMAP also only deals in messages and not threads. Gmail labels also technically only apply to messages, but the web interface shows the union of all labels of a thread. This is another decision I agree with. It means that when someone explicitly adds me to a thread, the whole thread gets highlighted in my feed.
I personally really enjoy the Gmail/fastmail/proton behavior so please don't make another political campaign to make things worse again. We have enough of those.
File extensions are just a hint about what the file might be and have nothing to do with what the file actually is. If the server sets the MIME type, the browser will use that as the hint.
But even beyond that, most file formats have a bit of a header at the start of the file that declares the actual format of the file. Browsers already can understand that and use the correct render for a file without an extension.
I'm not so sure most people would agree with you. Though I think plenty would.
I dare say that developers like environment variables more than before. Consider that Docker images, and hence Helm charts, are entirely controlled via environment variables. These very popular dev tools suffer from the same problem of having near-zero easy discoverability of what those environment variables might be. Yet they are very popular.
But I don't think Make usually uses all that many environment variables. You're usually specifying build targets as the command line arguments. Automake and autogen usually generate these makefiles with everything hard-coded.
Also, it makes it very easy to get started with, and it is universally available. Makes it very easy to like.
And don't even think about starting a sentence with 'and'.
I think we're taught rules like this to prevent us developing bad habits at the outset. Then, once we have more experience, we know when it's okay to break the rules.
You should look into why cities use smooth asphalt over concert which would be significantly less maintenance.
Cars driving around create a lot of noise. Driving on a rough surface like concert, let alone a bumpy surface like brick or cobblestone, creates a ton of additional noise. Another hint is that gravel driveways are cheap, but they also make it very very easy to hear when someone is pulling up to your house.
Anyone living next to these roads _might_ have some cars go a bit slower, but at the cost of not being able to sleep at night.
Then there is the fact that America loves big cars with big off roading wheels. I think the assumption here is that most speeders would be discouraged by the uncomfortable ride, however I think reality is that the people in that hummer going 90mph on a city street just won't care about a rougher ride.
Population of the world in 1950 was 2.5 billion. The population of the world has over tripled. This world put a lot of scaling pressure on everything.
I didn't think plastics are used because they are considered the only submittable suitable material, but they are definitely the cheapest and easiest to use. You cannot injection mold wood to be the exact shape and size with a snug fit for something you are packaging.
The fraction of the world's population regularly consuming manufactured and packaged goods is also increasing. That increases discarded plastics and other materials.
About a decade ago I tracked down the somewhat provocative claim that contemporary New Yorkers (city, not state) produced less refuse, by mass, than those of the 1930s. My first thoughts were that total packaging weight and waste food might account for this, older packaging materials being more ecologically-friendly, but generally more massive: wood, glass, metal, etc., and refrigeration and food preservation less developed.
Good guesses, but wrong as it happens.
The culprit was coal ash, on the order of 40% of all rubbish by weight. It had been > 80% in 1900.
Building heat was supplied by boilers running on coal. That left a large quantity of fly ash as residue. As heating switched to natural gas and cogeneration steam from the 1950s through the 1960s, coal use was largely eliminated.
Former generations of New Yorkers would often refer to receptacles as ash cans, and they were traditionally made of galvanized steel, both useful when contents might contain glowing coals. As trash evolved to colder refuse, plastic bins or bags could be substituted. "[T]he New York City Sanitation Department began encouraging the use of plastic garbage bags in 1969." (<https://archive.nytimes.com/cityroom.blogs.nytimes.com/2007/...>)
Net non-coal refuse has increased, but the total, at least as of a decade ago, was still below the early-20th-century high point. Much of the current total however is plastics, and in particular disposable diapers.
I'd had additional sources on this at one point though I can't locate them presently.
This paper discusses composition and confirms the 40% & 80% figures above:
"How New York City Residents Diminished Trash", Paul E Waggoner and Jesse H. Ausubel, The Connecticut Agricultural Experiment Station, New Haven andRockefeller University, New York.
October 2003.
You may not remember GameSharks, but those things did you exactly what you suggest. As do most game cheat engines. Editing the state, directly in RAM, without the program's knowledge.
The next time something tries to use whatever memory or function it overroad, it would pick up your version instead.
There is a difference between a series of instructions that maps to machine code nearly directly, and a data format like an image, or factory templates.
The point about algorithms stands - it's not that programs don't contain any because a machine interprets them. I'm referring to the simple fact that program code can be expressed as a flow diagram - but try doing that with a CAD file. You can't, it's declarative in nature, not a series of steps and decisions.
I started with MySQL in 2006 for my personal projects, but what first won me over to psql was those commands.
Today I use CLIs like usql to interact with MySQL and SQLite so I can continue to use those commands.
At first glance they may be less obvious, but they are significantly more discoverable. \? Just shows you all of them. In MySQL it always feels like I need to Google it.
> At first glance they may be less obvious, but they are significantly more discoverable. \? Just shows you all of them. In MySQL it always feels like I need to Google it.
In MySQL either `?` or `help` or `\?` will show you the help...
It's hard to know what exactly your security concerns are here, but if you look at the current ecosystem of using containers and package registries, Nix is pretty clearly a solid contender, security-wise.