>My package really does depend on the latest patch release!
> Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version.
I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business to make that so. If someone downstream wants to use library_method_broadly_correct and not library_method_correct_only_with_latest, then downstream should patch your source to allow them to do something unsupported. That becomes their problem. If this is likely to be a significant problem that will affect many users, then this is a codesmell warning you that you've probably got two libraries which you're just jumbling together into one: the solution isn't to falsely gate a safe function behind a high dependency version, nor to falsely release a function to people who can't use it safely, but to publish each with its own requirements expressly stated.
Not the greatest fan of python, but when I've got to run a python script, I do `nix-shell -p 'python3.withPackages (ps: [ps.requests])' --command 'python3 your-script.py'` Note that there is one argument to -p and one argument to --command -- both are quoted. The argument to -p is a nix expression that will provide a python3 command, referring to a python3 with the requests package. The argument to --command is a bash script that will run python3 with the argument "your-script.py" i.e. it will run your-script.py with the python3 that has the requests package.
I think there's ways you can autoderive a python3 with specific packages from python dependency files, but I can't help you there. I do find AI to be reasonably helpful for answering questions like this: it just might sometimes require a bit of help that you want to understand the answer rather than receive a perfect packaged shell.nix file.
Yes I just replied to your other comment with the same observation. It reminds me of an article by Paul Graham, I forget which, who expressed the difficulty of explaining to programmers who lack an abstraction just how good the abstraction is. Anything you can do with NixOS, you can do with any distribution, because it isn't magic. But somehow, more stuff becomes possible because it gives you a better way to think.
(As for why the docs are so bad, I think it's because of the lack of good canonical documentation. There's too many copies of it. Search engines ignore the canonical version because it's presented as one giant document. Parts of the system aren't documented at all and you have to work out what you've got by reading the code. The result is that you have no idea what to do if you want to improve the situation - it seems like your best option is to create new documentation. And now you have the same basic level of documentation that didn't help the first hundred times it was rewritten. And I don't really think submitting a PR to nixpkgs is exactly userfriendly, so it probably discourages people from doing the "I'm just trying to understand this, so I'll fix up the documentation as I learn something" thing.)
yes i think you've hit the nail on the head. I tend to view NixOS not as a distribution, but as a distribution framework. The system configuration is the sources for an immutable distribution as much as it as system configuration.
You're in no way bound by decisions of the nixpkgs contributors: as you say, we can add a patch. Or we can also decide we totally disapprove of the way they've configured such-and-such a service and write our own systemd service to run it.
Anyone can write a local debian package which adds a patch, and build and install it. And anyone can write a systemd service and use it instead of the distribution's systemd service. But on NixOS, these are equal to the rest of the system rather than outside it. Nixpkgs is just a library which your configuration uses to build a system.
While nix might be free of side effects, activating a nixos configuration isn't as free as you imply. As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id. And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
Not an argument against using NixOS - I think the bridge device issue could reasonably be regarded as a bug rather than a fundamental design issue, and the user id/username mapping is a totally reasonable design decision which can be taken into account by forcing the user id numbers anyway.
I'm not OP but that's basically right. With NixOS, nix generates the system configuration as well as making sure the packages are available. If you pin your dependencies using something like nix flakes and rely on git as your source of truth, you can get GitOps for the operating system.
But it isn't necessary. You can certainly make a change and apply it without committing it to git or relying on a CI/CD pipeline to deploy it. And it isn't necessary to use input pinning - if you don't, you can wind up making it at best archaeological work to rollback. Most people recommend flakes nowadays though, whose input pinning and purity rules should prevent any need for archaeology if you do commit before applying.
Engineers want some kind of regulation because they feel like computer systems, which they nominally control, are out of control, because of the business people's demands. They want the right to say no without having to have the consequences of saying no. But then when regulations come in, they're not about regulating business, they're about regulated interactions between people and business. And whereas the idealist sees a regulation as a chance to change things for the better, a regulator sees a regulation as a chance to preserve things as they were just before they became bad. (It takes a politician, not a regulator, to change things.)
> Fixing this is difficult, not just because people are resistant to change, but also because the variations in accents.
The relevance of accents is greatly overstated. The argument is of the form "we should let the perfect be the enemy of the good, and therefore it's impossible". There are a great many words in English whose pronunciation is irregular: these are the ones we should fix. For these, accent is irrelevant; you can pronounce your r's hard or your a's broad, and it doesn't matter: "bury" is pronounced to rhyme with "merry" in probably every accent of English that's ever been, from Old English (ic byrge vs myrge) on. You could just fix 100 words like "bury" and "could" and "are" whose spellings are either wrong or etymological but don't reflect extant variants, and the spelling would be reformed, children's lives would be improved, and it wouldn't be a problem from any perspective of accent variation or etymology or anything.
A certificate authority is an organisation that pays good money to make sure that their internet connection is not being subjected to MITMs. They put vastly more resources into that than you can.
A certificate is evidence that the server you're connected to has a secret that was also possessed by the server that the certificate authority connected to. This means that whether or not you're subject to MITMs, at least you don't seem to be getting MITMed right now.
The importance of certificates is quite clear if you were around on the web in the last days before universal HTTPS became a thing. You would connect to the internet, and you would somehow notice that the ISP you're connected to had modified the website you're accessing.
A local minimum is a point in the design space from which any change is an improvement (but there's other designs which would be worse, if they make several larger changes). I think it's hard to make that claim about Git. You're probably referring to a local maximum, a point in the design space from which any change makes it better (but there's other designs which would be better, if they make several larger changes).
In my career, I've used Svn, Git and something I think it was called VSS. Git has definitively caused less problems, it's also been easy to teach to newbies. And I think the best feature of Git is that people really really benefit from being taught the Git models and data structures (even bootcamp juniors on their first job), because suddenly they go from a magic incantation perspective to a problem-solving perspective. I've never experienced any other software which has such a powerful mental model.
That of course doesn't mean that Mercurial is not better; I've never used it. It might be that Mercurial would have all the advantages of git and then some. But if that were so, I think it would be hard to say that Git is at a local maximum.
Reinforcement learning, maximise rewards? They work because rabbits like carrots. What does an LLM want? Haven't we already committed the fundamental error when we're saying we're using reinforcement learning and they want rewards?
I think it's your responsibility to control the LLM. Sometimes, I worry that I'm beginning to code myself into a corner, and I ask if this is the dumbest idea it's ever heard and it says there might be a better way to do it. Sometimes I'm totally sceptical and ask that question first thing. (Usually it hallucinates when I'm being really obtuse though, and in a bad case that's the first time I notice it.)
> GNU did not have a working system until Linus released Linux in 1992. They had pieces and components which were worthless on their own.
People were installing GNU onto existing Unix systems because GNU was better than they were distributed with. Maybe they did that with components of BSD Net/1 - no one has ever told me they did but it probably happened - but that was definitively post GNU.
Anyway, I'm not sure if this matters so much to the debate. Stallman was reacting to a change. He rambled politically and wrote some code to back it up because he used to be able to do things, and now he could only do them if he would write some code and win some allies.
Linking against GPL code on a backend server which is never distributed - neither in code or binary form. (Because what might happen tomorrow? Maybe now you want to allow enterprise on prem.)
My favorite one I think is the Internet Explorer/Google Chrome "Same shit different - " one, because it's obviously recent and somehow iconic of the sort of person who reminisces about the old web, and clearly narrowcasting to such people.
I'm trying to brainstorm an answer. My best guess is that SSH is obsoleted by disposable instances. You can spin up a new instance for every version of your configuration, transition to it, and dispose of the original (or set it aside or whatever). That way, you could probably have a reasonably complete tech career and only ever use ssh as an implementation detail of git.
I think OP's point isn't to prevent toxic assholes from saying whatever righteous things and fighting whatever bad fight, but to limit bot/inorganic/foreign contributions from made up people - basically to make it "one person one voice".
I kind of like the idea of "one person one voice", but I have two problems with it, which I think will block me from accepting it.
One is that the cost of it seems much too high, even if you can change it to allow the use of chosen aliases (I don't think it matters what a "one person one voice" system calls an authenticated member). I don't really trust everyone who I have to give my ID details too, and this is just one more bit of stress for so little gain.
The second is that the benefits will never be realised. In an election, one person one vote doesn't work when half the population doesn't vote; you need almost everyone to come, otherwise it's the strongest opinions not the mainstream opinions that dominate. And I'm quite sure we'll see the exact same thing here, but in spades, and faster. If you don't like the opinion, you just don't show up. Once the centre of the social media is sufficiently different from the centre of the community, there will be the sort of bullying and self censorship you foresee and it will spiral out of control.
In case someone gets the misapprehension that there is a contrast between systemd and launchd in terms of the "well documented" attribution, systemd configuration is also well documented e.g. man systemd.timer etc. I didn't know if launchd has an equivalent of timers, but it does and I've just read `man launchd.plist` "StartCalendarInterval" and compared it with `man systemd.timer` "OnCalendar". I would have said they're about equal. Launchd is more concise, but systemd talks a lot about the interactions with other settings and edge cases.
As for ini vs xml, I've generally found xml is a crueller syntax for humans than ini. At the time I started using systemd, it was a bit funny - the last time I'd been editing ini files was on Windows 3.11. But I think ini and toml are now once again reasonably common so I forgot about how out of place it felt at the time.
I've never taken it as wish that employees have some cult like adoration, but as a team building exercise. I don't like it, it's cringe, but it's nothing worse than a bit of meaningless cringe. I have heard the theory of the fine line between a CEO and a cult leader, but I've never worked at a company that came anywhere near that fine line. Every CEO I've worked with has known that we're there due to a mutually beneficial agreement.
> Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version.
I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business to make that so. If someone downstream wants to use library_method_broadly_correct and not library_method_correct_only_with_latest, then downstream should patch your source to allow them to do something unsupported. That becomes their problem. If this is likely to be a significant problem that will affect many users, then this is a codesmell warning you that you've probably got two libraries which you're just jumbling together into one: the solution isn't to falsely gate a safe function behind a high dependency version, nor to falsely release a function to people who can't use it safely, but to publish each with its own requirements expressly stated.