Your link is irrelevant.
It points to OpenBSD which uses rc, not sysv.
The 3 lines of this rc startup script use a file of 400 lines of shell with commands that don't exist in SysVinit.
With sysv, the difficulty depended on the local tools because the launching scripts could not be shared across Linux distributions. Debian used the compiled helper `start-stop-daemon` while Redhat did not.
With sysv, some sysadmin tasks require external tools. Try to write a launching script with a smart autorestart in case of crash. Make it work even when the daemon forks. Do not assume that the daemon writes its initial PID anywhere. IIRC, to get this feature, we had to drop sysv for runit, two decades ago. Now it's just 2 lines in a systemd unit.
Init and run control aren't the same thing. Which is part of what's nice about sysv (which, yes, OpenBSD's init is based on). OpenBSD's run control system is particularly nice, and it's the sort of thing you can use with an init system that isn't constantly eating everything.
The world is vast, and I doubt that every mechanical engineer has studied steam engines, and that it makes a difference in the end.
Most modern programmers don't learn COBOL60 or Commodore BASIC. Modern mathematician very rarely study writings of Euler or Gauss; even 50 years old math books may be hard to grasp for modern students.
I agree that using a simpler tool for educational purpose is useful, but since SysVinit is obsoleted almost everywhere, it made sense to drop it. LFS could have chosen a simpler init than the domain standard, like runit or s6-init.
Comparing MermaidJS with Kroki is a bit like comparing PDF.js to Adobe Acrobat. I don't think either is better than the other, they're just for different use-cases.
With MermaidJS, converting a diagram inside a web page requires adding a handful of lines to a HTML page. The execution is fast and local.
Kroki is a web-service. To use it in a web page means adding a dependency to an external provider (a free service exists, but asks for fundings). An alternative is self-hosting by running a Kroki container.
A few years ago, I added Mermaid diagrams to a project in a few minutes of work. Had we needed a much more complex tool, maybe I would have gone with Kroki, but not by myself; it would have required a change in the deploying process of the project.
For anyone opening the link and wondering why the expected "gleam.toml" is missing: the project contains 2 Gleam sub-projects. The server/ directory is the BEAM server (no framework) and the client/ directory is the gleam-compiled-js client (lustre framework).
Unfortunately, there are many tests for the server, and none for the client.
This a very verbose and confuse article. Mixing P/LI and IMG/BR is wrong. I think the situation could be explained with two points:
1. The autoclose syntax does not exist in HTML5, and a trailing slash after a tag is always ignored. It's therefore recommended to avoid this syntax. I.e write <br> instead of <br />. For details and a list of void elements, see https://developer.mozilla.org/en-US/docs/Glossary/Void_eleme...
2. It's not mandatory to close tags when the parser can guess where they end. E.g. a paragraph cannot contain any line-block, so <p>a<div>b</div> is the same as <p>a</p><div>b</div>. It depends on the context, but putting an explicit end tag is usually less error-prone.
Putting an explicit end tag is more error-prone. It won't do anything for valid HTML but it'll add empty tag for invalid HTML. If you want to improve human readability, put end tag enclosed in HTML comment. At least it won't add empty elements.
The reporter rightly queried other researchers about this article, and all of them were skeptical that a "supply shock" could be the cause, or even the main cause. My own skepticism is because the death rate went down many months before any sign of shortage appeared.
I haven't read the paywalled Science paper, but The Economist extracted a graph which shows that the purity of Fentanyl pills was stable till the first months of 2024, then dropped sharply. The purity of the powder peaked in 2023, then went down in 2024, back to its older levels. They suppose that it proves the supply was short, but another researcher even states that the supply of Fentanyl precursors didn't change until the end of 2024.
What is your supposition here? That addicts are keeping narcan around just in case? That good friends of addicts are standing by with the spray in case it is needed? That your local opium den had staff with it on hand?
Narcan should be available, but short of a few users that know they need to keep it around, I don’t buy that making it available has meant a significant change in total outcomes because of timely deployment.
You might have got some at a rehab centre, or someone might live with a non-addict friend or partner. Community outreach workers (in cities that have embraced this stuff) might carry some around to administer.
I would be surprised if widespread availability to Narcan didn't decrease ODs.
Yes to all of the above. I knew of addicts who managed to get their hands on it many years ago when it required a prescription. Most weren't that resourceful though.
I've read thousands of books. There are good novels everywhere, and no country has the exclusivity of any theme.
> One is the depiction of desolation and human loneliness before the American continent was developed into a prosperous land.
Of course, classical European literature didn't focus on the American wilderness.
Though the most famous book on this theme is probably Defoe's Robinson Crusoe. And I enjoyed T.E. Lawrence' Seven Pillars of Wisdom which most people know through the film; the Arabian desert was a good place for loneliness in the wilderness.
> Another is the pursuit of the American Dream, where people achieve success through relentless struggle.
Like wise, the American Dream is an American myth, which is rarely the focus outside of the USA. But searching success through relentless struggle is a frequent theme. For instance, Stendhal's Le rouge et le noir or Maupassant's Bel-ami. These are from two of the most famous classical French authors, but there are many novels about hard-working people that reach success.
> The third is what this novel expresses: what happens after success? Money and career cannot solve all problems; people need more to fill an entire life.
As you like Russian literature, I suppose you've read Goncharov's Oblomov and Chekov's theater, especially Uncle Vania. That theme is central in one of the most famous French novel, Flaubert's Madame Bovary. The excellent Italian writer Alberto Moravia also has many novels about this, the most famous being Il disprezzo and my favourite being Gli indifferenti. I also like D'Annunzio's Il piacere much more than The Great Gatsby. I would argue that variations of this theme are universal, with old writings like the Bibles's Qohelet and even more Sumer's Gilgamesh.
I think what you said makes a lot of sense, and my earlier comment wasn’t very rigorous. More accurately, the most interesting thing about the United States is that it has almost stripped away all other influencing factors—no deep history, no influence from classical literature. If we set aside the atrocities committed against the Native Americans, it’s as if the country started from an untouched, resource-rich continent and rapidly evolved into the most advanced capitalist society. This makes the contrast between material wealth and the spiritual world especially stark and easy to observe.
The title makes it look like Public Domain is universal, while the article does mention that this list is only about the USA.
> On January 1, 2026, books published in 1930 enter the U.S. public domain.
The Copyright laws are different in each country, and it's a non-sense in the modern world.
A few years ago, I was searching for books written by Alexandra David-Neel. I found them on a Canadian (IIRC) website, but downloads were filtered by geo-IP, since what was in the public domain there was not yet public in France. One of the books I wanted was written before 1900, and not in print since then. Yet the author died in 1969, aged 100, so the French Public Domain for her works will start in 2040.
Another example: "As I lay dying" by William Faulkner is now Public Domain in the USA. It was Public Domain in Canada from 2013 to 2023. Then the law changed, and the copyright was extended by 20 years, and reinstated for this book until 2032 — which is 70 years after the author's death in 1962.
AIUI the Canadian law change did not reinstate copyright status for works that had lapsed into the public domain, though it did extend duration of existing copyright.
I wrote a few times to my local MPs ("député", as we call them in France). I usually got a response, though I suspect it was written by their secretary with no other consequence. In one case (related to privacy against surveillance), they raised a question in the congress, which had just a symbolic impact.
It may be different in other countries. In France, Parliament is de-facto a marginal power against a strong executive power. Even the legal terms are symptomatic of this situation: the government submits a "project of law" while MPs submit a "proposal of law" (which, for members of the governing party, is almost always written by the government then endorsed by some loyal MP).
That's my experience. I'm not a Python developer, and installing Python programs has been a mess for decades, so I'd rather stay away from the language than try another new tool.
Over the years, I've used setup.py, pip, pipenv (which kept crashing though it was an official recommendation), manual venv+pip (or virtualenv? I vaguely remember there were 2 similar tools and none was part of a minimal Python install). Does uv work in all of these cases? The uv doc pointed out by the GP is vague about legacy projects, though I've just skimmed through the long page.
IIRC, Python tools didn't share their data across projects, so they could build the same heavy dependencies multiple times. I've also seen projects with incomplete dependencies (installed through Conda, IIRC) which were a major pain to get working. For many years, the only simple and sane way to run some Python code was in a Docker image, which has its own drawbacks.
In my experience every other python tool has a variety of slightly to extremely painful behaviours that you have to work around or at least be aware of.
Sometimes it's things like updating to Fedora 43 and every tool you installed with `pipx` breaking because it was doing things that got wiped out by the system upgrade, sometimes it's `poetry update --only dep1` silently updating dep2 in the background without telling you because there was an update available and even though you specified `--only` you were wrong to do that and Poetry knows best.
Did you know that when you call `python -m venv` you should always pass `--upgrade-deps` because otherwise it intentionally installs an out of date version of pip and setuptools as a joke? Maybe you're not using `python -m venv` because you ran the pyenv installer and it automatically installed `pyenv-virtualenv` without asking which overrides a bunch of virtualenv features because the pyenv team think you should develop things in the same way they do regardless of how you want to delevop things. I hate pyenv.
So far the only problem I've had with uv is that if you run `uv venv` it doesn't install pip in the created virtualenv because you're supposed to run `uv pip install` instead of `pip install`. That's annoying but it's not a dealbreaker.
Outside of that, I feel very confident that I could give a link to the uv docs to a junior developer and tell them to run `uv python install 3.13` and `uv tool install ruff` and then run `uv sync` in a project and everything will work out and I'm not going to have to help them recover their hard drive because they made the foolish mistake of assuming that `brew install python` wouldn't wreck their macbook when the next version of Python gets released.
uv not only completely replaces all of pip, pyenv & venv, but it also does a much better job than any of them at their intended function, as well as a bunch of other convenient, simple developer-friendly features.
1. pip isn't entirely to blame for all of Python's bad package management - distutils & setuptools gave us setup.py shenanigans - but either way, UV does away with that in favour of a modern, consistent, declarative, parseable PEP 508 manifest spec, along with their own well-designed lockfile (there was no accepted lockfile PEP at the time UV was created - since PEP 715 has become accepted UV has added support, though that PEP is still limited so there's more work to do here).
2. pyenv works fine but uv is faster & adds some nice extra features with uvx
3. venv has always been a pain - ensuring you're always in the right venv, shell support, etc. uv handles this invisibly & automatically - because it's one tool you don't need to worry about running pip in the right venv or whatever.
pip and venv. The Python ecosystem has taken a huge step backwards with the preachy attitude that you have to do everything in a venv. Not when I want to have installable utility scripts usable from all my shells at any time or location.
I get that installing to the site-packages is a security vulnerability. Installing to my home directory is not, so why can't that be the happy path by default? Debian used to make this easy with the dist-packages split leaving site-packages as a safe sandbox but they caved.
They have their place. But the default shouldn't force you into a "project" when you want general purpose applicability. Python should work from the shell as readily as it did 20 years ago. Not mysteriously break what used to work with no low-friction replacement.
Python can work from the shell, if you don’t have external dependencies. But once you have external dependencies, with incompatible potential versions, I just don’t see how you could do this with “one environment”.
A python virtualenv is just a slightly more complicated node_modules. Tools like PDM, Poetry and uv handle them automatically for you to the point where it effectively is the same as npm.
The thing that makes Python different is that it was never designed with any kind of per-project isolation in mind and this is the best way anyone's come up with to hack that behaviour into the language.
That's what `uv tool install` does: it creates the wrapper and puts a symlink to it into ~/.local/bin (which you can add to PATH with `uv tool update-shell` if you don't want to do it manually). I don't recall pip doing anything helpful here; I think it still leaves it up to the end user to either add the venv's bin directory to their PATH or create the wrapper and put it somewhere already on the PATH. So it's a reasonable complaint that `pip install` has become less useful now that it resists installing tools outside of a venv but still lacks the replacement feature (which third party tools like uv and pipx do provide).
I'm interpreting this as "uv was built off of years of PEPs", which is true; that being said the UX of `uv` is their own, and to me has significantly reduced the amount of time I spend thinking about requirements, modules, etc.
> IIRC, Python tools didn't share their data across projects, so they could build the same heavy dependencies multiple times.
One of the neatest features of uv is that it uses clever symlinking tricks so if you have a dozen different Python environments all with the same dependency there's only one copy of that dependency on disk.
Hard links, in fact. It's not hard to do, just (the Rust equivalent of) `os.link` in place of `os.copy` pretty much. The actually clever part is that the package cache actually contains files that can be used this way, instead of just having wheels and unpacking them from scratch each time.
For pip to do this, first it would have to organize its cache in a sensible manner, such that it could work as an actual download cache. Currently it is an HTTP cache (except for locally-built wheels), where it uses a vendored third-party library to simulate the connection to files.pythonhosted.org (in the common PyPI case). But it still needs to connect to pypi.org to figure out the URI that the third-party library will simulate accessing.
Coming from a mostly Java guy (since around 2001), I've been away from Python for a while and my two most recent work projects have been in Python and both switched to uv around the time I joined. Such a huge difference in time and pain - I'm with you here.
Python's always been a pretty nice language to work in, and uv makes it one of the most pleasant to deal with.
That's partly because python has a very large installed base, and ease of entry (including distribution). This leads to people running into issues quicker, and many alternative solutions.
Unlike something like Rust, which has much fewer users (though growing) and requires PhDs in Compiler Imprecation and Lexical Exegetics.
Or C++ which has a much larger installed base but also no standard distribution method at all, and an honorary degree in Dorsal Artillery.
Your link is irrelevant. It points to OpenBSD which uses rc, not sysv. The 3 lines of this rc startup script use a file of 400 lines of shell with commands that don't exist in SysVinit.
With sysv, the difficulty depended on the local tools because the launching scripts could not be shared across Linux distributions. Debian used the compiled helper `start-stop-daemon` while Redhat did not.
With sysv, some sysadmin tasks require external tools. Try to write a launching script with a smart autorestart in case of crash. Make it work even when the daemon forks. Do not assume that the daemon writes its initial PID anywhere. IIRC, to get this feature, we had to drop sysv for runit, two decades ago. Now it's just 2 lines in a systemd unit.
reply