I find that for dev workflows (even outside firefox containers) to not mix up badly, you end up needing to split localhost anyway - so for example, binding to specific IPs inside 127.0.0.1/8 (it's a whole /8, you're usually not running out of that), or, depending on how badly you need ::1/IPv6 bindings, service.localhost6 or service.localhost6.localdomain6 style names instead of just localhost.
Unless all python dependencies you ever used were available in your distro (and then at that point, you're no longer using pip, you're using dpkg...), this never worked well. What solves this well is PEP 723 and tooling around it.
With PEP 723 and confortable tooling (like uv), now you get scripts, that are "actually directly runnable", not just "fake directly runnable oops forgot to apt-get install something sorta runnable", and work reliably even when stuff around you is updated.
I wish this comment was true, but due to a foolish attempt to squish all human charactets to 2 bytes as UCS (that failed and turned into the ugly UTF-16 mess), a disaster called Han Unification was unleashed upon the world, and now out-of-band communication is required to render the correct Han characters in a page and not offend people.
> systemd is my hammer having it's own opinions about what nails I hit & where & into what & why.
I feel like the exact opposite. systemd has way too many layers of customization. Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes.
Now, if you are in a system that doesn't use systemd, if you mess with the "sacred and sanctioned" system service summoning scrolls, now you're on your own to diff whoever stuff the maintainer did, every time the summoning scroll changes, and to make sure that probably Turing-complete mess still summons a valid, working and safe system component instead of rampaging thru your system.
> Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes.
I really encourage you to learn the difference between these three places. They are semantically distinct, and it's truly an advantage to have the system distinguish them. They're all sources of configuration, of course. But one is managed by the OS vendor, one by the sysadmin, and one by the sysadmin at runtime. Runtime isn't as significant a distinction, but having a clear, bright line between vendor-provided and sysadmin-managed config is huge.
I read that message as "Whoever is the poor soul attempting to fix this system that doesn't boot, (because who otherwise inspects early boot messages?) whoever installed this system is running a known-fragile configuration."
And that's what I expect of systemd? That it should complain loudly whenever me, the daemons I'm attempting to run, or the overall system is doing things in a weird, known-bad, known-fragile way and warn me about it before it breaks if possible.
When I tried Fossil it had things weirdly separated.
I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
That's my favourite thing about fossil though. History is what it is, not simplified to look "clean" (i.e. hide what actually happened and when) and you get a lot fewer footguns to ruin everything by accidentally rebasing things to the wrong place without noticing.
Information security's primary focus is the balanced protection of data confidentiality, integrity, and availability, so, not having availability of the things the user wants to do is a failing grade. In this case you can pretend you value other things, not security.
Either you really are secure, or ideally you should not be able to even pretend you are secure. Allowing "pretend it's secure" downgrades the security in all contexts.
IMHO they should gradually lock all dynamic code execution such as dynamic CSS and javascript behind a explicit toggle for insecure http sites.
> It massively undermines the security of connections to local devices
No, you see the prompt, it is insecure. If the network admin wants it secure, it means either a internal CA, or a literally free cert from let's encrypt. As the network admin did not care, it's insecure.
"but I have legacy garbage with hardcoded self-signed certs" then reverse proxy that legacy garbage with Caddy?
I'm talking about situations where you have nontechnical users that need to connect to the device, neither the client nor the device have necessarily an internet connection, and the connection is often via a local IP address. None of your proposed solutions are appropriate for that situation. And basically all I'm asking is that the connection be at least encrypted (meaning that eavesdropping is not enough: you need to construct a man in the middle), even if it's not presented to the user as secure.
(An option to get some authentication, and one that I think chrome have kind of started to figure out, is to allow a PWA to connect to a local device and authenticate with its own keys. This still means you need to connect to the internet once with the client device, but at least from that point onwards it can work without internet. But then you need to have a whole other flow so that random sites can't just connect to your local devices...)
How often are you offline like that but on a network you can trust isn’t malicious? If I’m at home, my printer is more protected from eavesdropping by the WiFi password than a self-signed certificate. If I’m at the coffee shop, it’s insecure because I can’t trust the dozens of other people not to be malicious or compromised, and the answer is to clearly tell me that it’s unsafe.
What about wayback? Assuming running X by itself becomes real bad and undesirable, would wayback+Xwayland cover all those "can't Wayland" use cases? What remains (besides better stability and wider availability of wayback) to be done?
reply