squiggleblaz

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.

`One reason to set `mutableUsers = false`: https://mynixos.com/nixpkgs/option/users.mutableUsers.`

That doesn't help. Mutable users is about the lifecycle of the /etc/passwd file. What's I'm referring to is /var/lib/nixos/uid-map.

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.

I don't know what other solutions there are to TOFU, but maybe it's nice if there's something like a standardised /.well-known/ssh-keys.json path for public ssh servers like github and pico.sh.

From https://github.com/tailscale/tailscale

"This repository contains the majority of Tailscale's open source code. Notably, it includes the tailscaled daemon and the tailscale CLI tool. The tailscaled daemon runs on Linux, Windows, macOS, and to varying degrees on FreeBSD and OpenBSD. The Tailscale iOS and Android apps use this repo's code, but this repo doesn't contain the mobile GUI code."

and

"The macOS, iOS, and Windows clients use the code in this repository but additionally include small GUI wrappers. The GUI wrappers on non-open source platforms are themselves not open source."

Moreover, there's https://github.com/tailscale/tailscale-chocolatey to aid the build process. I haven't built it or run it.

On the other hand, while I suppose the Windows app is probably reasonably straightforward to replicate, I guess it would be much harder to produce an iOS or Android app because of the vagaries of mobile programming.

* Does it work well? * Do you recommend it? * Do your users care? * Is it difficult? Do you have to maintain it or is it basically set it and forget it? * What was memorable about setting it up? * Why did you go for Headscale vs Tailscale or Netbird or some other solution?

I can buy a brand new Ryzen 7000 series laptop for the price of replacing a Ryzen 7000 series mainboard for a Framework laptop.

I haven't been able to confirm this (I found laptop prices running at about twice the cost of the mainboard), but I wonder if you're comparing an EOL runout model from a place that can afford heavy discounts against a standard price from a smaller company. If you just need a laptop and you're not too fussy, that's definitely a fair choice. But if you're buying a laptop for ten years, you probably aren't going to settle for the unsold 16GB 512GB.

Their laptops are also a lot more expensive than same spec branded ones from Asus, Lenovo and Dell that have better build quality and design.

I guess a Framework isn't for someone who wants a same spec Asus, Lenovo or Dell.

Eventually, sooner rather than later, both RAM and SSD will come soldered on, so the only thing you will be able to replace is the battery and the screen.

This is 173% fud. If it happens, it's because Framework is dead and there's some different company that bought their branding and just wants to use it for market segmentation. I definitely have to rate the chances that Framework has died as one of the risks of buying them, whereas I wouldn't concern myself with the risk of System76 dying, because a typical laptop lasts well past its warranty, but the point of Framework is indeed what happens in that post-warranty period.

I'm not a huge fan of Frameworks. I left a critical review on another comment. I'm not sure at all if they fit my needs, and having recently discovered the wonder of tailscale I'm now debating if my next computer will be a Framework vs a headless desktop + a dumb laptop. So even if a Framework doesn't fit my needs, they're still the only laptop that seems to. But your criticisms don't at all seem grounded enough.

The modular ports are just USB-C in a cutaway. You can plug your charger into the USB-C port, or into a USB-C module that plugs into the USB-C port. Totally underwhelming. (I had a Framework 16 as a work machine at a previous job.) I definitely still make use of USB-A, and I will for some time - but only when I'm at home plugging in my keyboard and mouse, so I could be perfectly happy with a USB-C hub like I use with my current laptop. I want a durable computer which I can upgrade the RAM, motherboard, storage, replace the battery, screen etc over the next seventeen years so that I don't know when one computer begins and the next ends. I don't want impractical USB-C ports that I have to pay extra for and which limit the durability of the system. To be clear: I've never had a laptop whose charging port died, but if it was something I'd rate as likely, I'd would much rather have a good system and replace the bottom cover kit, rather than a compromised system and replace a protective plug.

I just searched for some colorised Roman statues and they don't seem to be overusing color. Even complex designs might be basically three colors (e.g. red, blue and white, plus with brown hair and eyes), and the colors themselves are a bit muted. I guess the have been painted based on modern interpretations of the original colors based on whatever limited evidence remains, so maybe those aren't the original colors, but it doesn't seem like a 1990s era website or a garish collection of first gen iMacs and iBooks.

What else could it be but a bitwise AND. If they had used `open_source && privacy_focused && user_controlled`, it would just be `true`, which is hardly an interesting philosophy. This way, you'll be able to do tests like `if (!(philosophy & privacy_focused)) { track_user_activity(); serve_creepy_but_useless_ad_about_something_they_bought_yesterday(); }`. Alternatively, they could have used some kind of set datatype if the number of philosophy variables is large enough, but I think the code would have become unmaintainable if they want to implement every possible philosophical alternative; 64 bits should be enough for everyone.

If you buy someone's domain name, then they'll probably have emails going to it. So you set up a catchall address and discover what accounts are related to it, then you can use the reset password functionality to get access to the accounts. In some cases, they'll have a backup gmail account - and perhaps you can guess what it is (e.g. emails come through to Paul Davis so you guess, oh, maybe they have the paul.davis google account, and reset password on that).

Yes but metrics! How can the CEO look like they know what's happening without understanding anything if they don't have everyone producing numbers?

Ultimately, yes, programming with LLMs is exactly the sort of programming we've always tried to do. It gets rid of the boring stuff and lets you focus on the algorithm at the level you need to - just like we try to do with functions and LSP and IDE tools. People needn't be scared of LLMs: they aren't going to take our jobs or drain the fun out of programming.

But I'm 90% confident that you will gain something from LLM-based coding. You can do a lot with our code editing tools, but there's almost certainly going to be times when you need to do a sequence of seven things to get the outcome you want, and you can ask the computer to prepare that for you.