Julio Merino writes about software performance, Unix systems, build tools, and Windows Subsystem for Linux.
HN links his 'Fast machines, slow machines' post as evidence that older computers could feel faster than modern ones. Another commenter adds it to a blog recommendation list.
Aside from a centralized, trusted packge archives, with signed packages and vetting, and secure downloads and verification, one difference is that with individual install.exe's - that installer can do whatever it wants. Windows package managers are just a facade over this and just run the installer for you.
An actual Package Manager _is_ the installer - they are part of the OS and know how to correctly install and fully uninstall things. Someone else in this thread wrote a nice summary of this aspect here: https://jmmv.dev/2022/03/a-year-on-windows-winget.html#uninstallation
This part is mostly true with MSI's, they're just a package format like .deb or .rpm - they just don't have any of the other infrastructure around them.
> It does in fact centralize the update flow, but that's only beneficial when you update everything at once, which I don't have any reason to be doing: either I want it on latest, with the only interruption being not quite yet, or I don't want it updating at all
Having this all centralized is actually really nice, so I wouldn't discount that. If you want to pin a package at a particular version, you can and the package manager will leave it alone. If you don't want things updated yet, just don't run the update yet.
> Bash is "real language" if you treat it as such. Yes, there are plenty of spaghetti scripts out there, riddled with global variables and full of side-effects, but if you write shell in a principled manner, you can solve some pretty big problems with ease, and you can write maintainable code.
Even carefully written bash code tends to be much less maintainable than code in better languages. It's just badly designed on multiple levels, like the famous post about PHP. Yes, if you're really careful you can write decent code in Malbolge - but why would you?
> I wouldn't start new projects in shell, of course, but one area in which I think the shell shines is in writing integration tests for tools. More on this in a recent post I wrote: https://jmmv.dev/2023/10/unit-testing-with-shtk.html
The fact that you've written something that compiles to shell scripts rather than writing shell scripts rather undermines your claim that shell is a decent language. Integration tests of tools are important, but I'd still find e.g. TCL a much better way to write them.
No, but if you are doing something like rebuilding a distro's worth of packages from source from scratch, the configure step starts to dominate. I build around 550, and it takes around 6 hours on a single node.
Most checks are common, so what can help is having a shared cache for all configure scripts so if you have 400 packages to rebuild, it doesn't check 400 times if you should use flock or fcntl. This approach is described here: https://jmmv.dev/2022/06/autoconf-caching.html
It doesn't help that autoconf is basically abandonware, with one forlorn maintainer trying to resuscitate it, but creating major regressions with new releases: https://lwn.net/Articles/834682/
Right. I found <https://www.ise.io/wp-content/uploads/2017/07/apple-sandbox.pdf> which agrees with you (on page 9). Guess it's down to defining "at runtime" now; the TinyScheme code (and GC) and Scheme code for the sandbox definitions are shipped to a user of macOS, and the user can invoke sandbox-exec with new sandboxing definitions (e.g. <https://jmmv.dev/2019/11/macos-sandbox-exec.html>), running TinyScheme and Scheme code. So I'd think Scheme is part of the entire sandbox system, even if not in the kernel?
> https://jmmv.dev/2021/08/useless-use-of-gnu.html
Tangential, but your blog software seems to have mangled the headings; it's serving eg:
make $(shell &mldr;) expansion
instead of
make $(shell ...) expansion
(note that (as is correctly written in the body) that's three pediods, not one elipsis, so mldr wouldn't be correct even on it's own, meaning there's two probably-unrelated bugs affecting it).
A lot of the GNUisms described in https://jmmv.dev/2021/08/useless-use-of-gnu.html are very useful in interactive use. Search the current directory without an explcit . - useful. Append an option to a command you just typed - heck yeah, always annoyed when commands don't support that.
For scripts though, sticking to POSIX sh often makes sense, yeah. You should at least be aware if your use of Bash-isms.