Oh systemd cares about them very much, and systemd will be a key component for the stability for postmarketOS with stuff like first-boot, sysusers/tmpfiles and in the end sysupdate (hopefully). That's just part of a very long list which simply wouldn't be possible without systemd.
In the end, if someone cares enough to step up and keeps OpenRC at the same state (and there is some progress, to be noted), we won't interfere with you, but at the current state it's just a big time consumer for many of our developers, and it's not where we would like to spend the time with and rather want to focus on stability and sustainability in general.
The idea here is more that you need to adjust these flags for the benchmark to make sense.
Take fore example the aforementioned block size. Say, you have a storage with 4x block size of the one used by PostgreSQL. If you run a benchmark over such a storage, you'll have insane write amplification. Nobody will consider results of such a "benchmark" because that's simply a misconfiguration of the program you are trying to measure.
More generally, Linux distros will tend to compile distributed binaries with "safe" defaults s.t. run on most h/w users can have, and this means optimizing for the lowest common denominator. Looping back to PostgreSQL, the default for block size was for a long time 4k, and iirc today it's 8k. This is fine, if we are talking about plain SSD / HDD, but with enterprise SDS, these are "rookie numbers", even the maximum supported by PosgreSQL (32k) is still a "rookie number", but it's still four times better than the default!
Not who you are replying to, but likely: 1) heat 2) fan noise 3) power consumption.
I recently (8 months ago) replaced my 10 year-old laptop. The only reason I retired it was because the display was starting to go.
So I bought a second-hand workstation-class laptop with 6 beefy CPU cores and kinda wish I hadn't. Overall I want to like it but the battery life is abysmal, it makes a lot of heat even when fairly idle, and is a bit heavy due to the large heatsink inside. (And that's without a dedicated GPU.)
If I had to do it over again, I would trade it for one with a weaker but more power-efficient CPU.
qutebrowser author here, use Dodo and can confirm it's basically the qutebrowser of mail clients :)
Development is slow but not unmaintained. The author comes back every month or so to merge PRs. Reminds me I have a bunch of local changes I should upstream...
I stumbled upon Dodo while checking your starred repos, and I think it deserves more attention than it has; it is mature enough to be used by users who wants customizibility, vim-bindings, and easy configuration. It's one of my top options to migrate to as a mail client if I find any problems with neomutt, which I am using right now.
That reminds my of a own xdg-open I wrote that sits in /usr/local/bin/xdg-open.
It's a simple python script that checks by looking at the protocol, mime type or extension which URL it is and also asks if there are multiple applications
[In the spirit of elucidation, and not general meanness…]
Like jojo14 points out Python has the shlex module, and it is definitely useful in these situations even if just for quote(). And, os.system() is basically never safe with external input. Without proper escaping you're one click from code execution, for example with the input "file:///etc/issue%3Becho%20whoops" or "http://example.com/';echo whoops'".
It doesn't appear to matter in this instance, but you can feed check_output() with the stdin argument, which removes the need for using shell=True. shell=True in other paths could easily lead to unwanted code execution without thorough escaping.
> What if you're ssh'd into a machine, you're in your trusty bash shell, but unfortunately you cannot spawn any new processes because literally all other pids are taken. What do you do?
But what if i'm instead in my trusty POSIX shell without bash support? The bash script is not POSIX complient :(
reply