4 ms·
I think it's time to use an LLM to rewrite portage in C. Might be one of my next projects. Should not take long and the result will be easy to deterministically
by hparadiz 5mo ago
I think it's time to use an LLM to rewrite portage in C. Might be one of my next projects. Should not take long and the result will be easy to deterministically test side by side.
- lanstin 5mo agoRust or Go please.
- Gualdrapo 5mo agoAnd get rid of the bashims in OpenRC to make it posix-sh compliand while we're at that.
- mid-kid 5mo agoIt already is, though? I've been using dash as /bin/sh for years, openrc is using that.
- adrian_b 5mo agoI do not agree with this. Here the guilty part is POSIX, not bash. Most bashisms are very old and they come from ksh. Bash has added very few features beyond what was already quasi-standard in UNIX shells. POSIX has standardized a shell variant that had already been obsolete for a long time. The scripts that use the additional facilities added by ksh and also a few added by zsh, which now are all available in bash, can be written in a way that makes them more concise, more clear and less prone to bugs. I believe that bash must be considered the standard for shell scripts, not the POSIX shell, which has been obsolete for more than 3 decades, i.e. since long before the existence of the POSIX standard. When using a POSIX shell, there are many unavoidable things that can be performed only by invoking external command line utilities, instead of using intrinsic shell features. This not only can make the script much slower, but it adds extra software package dependencies, instead of avoiding such dependencies, which is the declared purpose of using a POSIX shell. Making your shell script dependent on the existence of bash is less risky than making it dependent on the existence of awk, which may be forced when using a POSIX shell. (The existence of awk is mandated by POSIX, but there are plenty of Linux systems that do not have installed all the POSIX utilities, but they have bash.) It is true that bash is ubiquitous only on Linux, while on *BSD it is optional. I have used FreeBSD and other *BSD systems for as many decades as I have used Linux. My first action when installing a *BSD system, after the base system is installed, has always been to install bash. I believe that whoever does not do this is mistaken and they should not demand to receive scripts that can be run without having installed one of the bash, ksh or zsh shells.
- tanderson92 5mo agoThere have existed portage replacements in C++ in the past. What you will find on reading the history is that personalities in the Gentoo community can play a more important role than technical excellence.
- bombcar 5mo agoSwitch to using a git backend and portage will fly fast enough. tank ~ # time emerge --sync * Using keys from /usr/share/openpgp-keys/gentoo-release.asc emerge --sync 3.18s user 5.15s system 67% cpu 12.324 total https://wiki.gentoo.org/wiki/Portage_with_Git https://wiki.gentoo.org/wiki/Portage_with_Git
- hparadiz 5mo agoThe sync has nothing to do with it's slowness when reconciling dependency conflicts.
- yjftsjthsd-h 5mo agoWait, it's that easy? Why isn't that the default?
- bombcar 5mo agoI have no idea - I randomly stumbled on that when looking for something else and it blew my mind.
- themafia 5mo ago> will be easy to deterministically test side by side. How are you ever going to get test coverage over the massive number of possible system states and configurations? Are you going to compile every package in portage on every architecture it supports?
- hparadiz 5mo agoportage doesn't compile anything. it tells gcc et al to do stuff. the commands it runs are deterministic and the unit tests that portage comes with can easily be used. whether or not some ebuild builds on your machine is kind of between you and gcc and has nothing to do with anything gentoo. I don't really care about it being a replacement overall. I just want my own emerge command to be faster. I can't believe it's not instant like it should be.
- themafia 5mo ago> portage doesn't compile anything. it tells gcc et al to do stuff. That's a difference without distinction. Portage does patch packages. So it involves itself directly in the compilation cycle. > it runs are deterministic Well, I don't think so, but good luck to you anyways.