<qyliss>
(I totally can figure out the fd type from userspace -- just need to look at the device ID returned from fstat)
<pie_>
https://slideplayer.com/slide/3052416/ slide 30 "we believe its not possible to implement effective kernel protection on General Purpose OSes based on a microkernel architecture"
<pie_>
is....that a typo?
multi has quit [Quit: bye]
multi has joined #spectrum
cole-h has quit [Ping timeout: 240 seconds]
TheJollyRoger has quit [Quit: TheJollyRoger]
jpds has quit [Remote host closed the connection]
jpds has joined #spectrum
cleeyv has quit [Quit: WeeChat 2.7.1]
cleeyv has joined #spectrum
<hyperfekt>
must be. the next bullet point recommends microkernel architectures. and classically the problem of driver isolation is specific to monokernels
c4rc4s has quit [Ping timeout: 240 seconds]
c4rc4s has joined #spectrum
qyliss has quit [Quit: bye]
qyliss has joined #spectrum
<pie_>
hyperfekt: hence my confusion
<pie_>
ok
<pie_>
hyperfekt: i mean, i was like, well, this is invisible things lab, so who knows, maybe they have reasons for unorthodox opinions :P
<MichaelRaskin>
Missing «not» maybe
cole-h has joined #spectrum
<hypokeimenon[m]>
Are there any general purpose operating systems based on microkernels? Apart from maybe Redox
<MichaelRaskin>
Genode?
<MichaelRaskin>
Minix?
<qyliss>
macOS, dependency on your definition
<qyliss>
*depending
<qyliss>
*microkernel people get mad at me*
<MichaelRaskin>
Also, QNX is probably still alive, right?
<qyliss>
yeah
<qyliss>
used in lots of cars AIUI
<MichaelRaskin>
There was this period when QNX could be downloaded for non-commercial use, and it definitely had a general-purpose desktop distribution
<MichaelRaskin>
Wait what? AmigaOS had a release in 2021?
<MichaelRaskin>
I wonder should Hurd be considered «there is»? I guess GuixSD/Hurd will eventually have a release, and Debian GNU/Hurd does not seem to be abandoned
<qyliss>
Guix on Hurd seems to be quite actively developed
<MichaelRaskin>
Well, the question should it already be called «there is» not «there will be»
<MichaelRaskin>
And at any moment in time there is some general-purpose PoC microkernel OS under development at MS Research
<Ke>
didn't google publish something?
<MichaelRaskin>
Probably, but by the time Google publishes something they have already discontinued it and just forgot to tell the people developing the thing
<MichaelRaskin>
But yeah, Fuchsia seems unfortunately still alive
<MichaelRaskin>
(unfortunately, because «garbage quality firmware → eventually rootable» might be less true there)
<MichaelRaskin>
I would say «missing rule», not really a bug per se
<samueldr>
MichaelRaskin: "firmware" there was "operating system", right?
<MichaelRaskin>
More narrowly. Operating system installed in a hostile way
<samueldr>
yeah
<samueldr>
it's just that I'm like 99% sure the "initial boot firmware" situation won't change whether it boots a Linux or a Fuschia :)
<samueldr>
ugh, that word
<samueldr>
fuchsia
<MichaelRaskin>
Well, _there_ there is also less spread in quality
<qyliss>
MichaelRaskin: missing default rule is a bug imo
<MichaelRaskin>
Nah, missing important feature
<samueldr>
nah, it's a usability bug if an expected feature is missing
<MichaelRaskin>
Yeah, that's why my default assumption that any work on usability works to software becoming less comfortable for me
<MichaelRaskin>
Because here I agree this is most probably a drawbackless improvement, but this logic gets scaled really quickly to turn a piece of software into a damned patch of quicksand
<MichaelRaskin>
Also, given that the missing rule is trivial to install separately, shouldn't usability bug stay with whoever picked default set of driver/udev-rule packages to install?
<qyliss>
no, because systemd has taken responsibility for maintaining the default rules
<MichaelRaskin>
Clearly enough to be sure it is not the NTP defaults story again?
<MichaelRaskin>
(To be clear: I sure hope that the patch will be merged just on the merit of being a clearly in-scope feature addition with no maintenance necessary)
<pie_>
i will continue to say that im still salty flokli is insistent on not diverging from upstream and all our magic sysrq are off by default on nixos
<pie_>
the "lets throw everything 'complicated' out" excuse of usability. (which is really just an excuse for pushing incomplete systems) <MichaelRaskin> Yeah, that's why my default assumption that any work on usability works to software becoming less comfortable for me
<MichaelRaskin>
Look, I dropped NixOS because systemd was changing random stuff all the damned time
<MichaelRaskin>
I prefer to assemble my environment if a few incomplete-when-separate systems to chasing the tail of One True Way
<pie_>
you could argue systemd was the incomplete system being pushed :P dunno if there were any usability arguments though
<pie_>
i guess all the stuff i said is too soft to prevent goalpost moving
<MichaelRaskin>
I think systemd does not want to be incomplete, which is why I don't want it on interactive machines
<lejonet>
Yeah, that is also why I dropped nixos, and that a badly done glibc upgrade hosed several of my systems to the point where a reinstall was the only way out of it (the 20.03 -> 20.09 upgrade path never worked for me)
<MichaelRaskin>
I always ran on Nixpkgs checkouts close to master, and still run
<MichaelRaskin>
Might have missed some of the stable-branch fun
<lejonet>
Well, for my desktop, I did that, but for the servers, I kept very close to the stable-branch, and then everything just bombed when 20.03 -> 20.09, so I decided to go back to gentoo if I needed to reinstall everything anyway, because I've never been a fan of systemd, even if it ofc has some nifty things (not saying that other initsystems don't have those nifty things)
<pie_>
huh
<MichaelRaskin>
For my VPS I just nix-build the tools and let whatever Debian OVH offers handle the boot.
<pie_>
lejonet: tbh i find that a bit odd but im no expert
<MichaelRaskin>
Unlikely to try spinning CrosVM inside this low-tier VPS either…
<lejonet>
pie_: it was very odd, the root of the problem was that something in the switch-to-configuration toolchain got screwed up with the glibc upgrade, trying to use libraries from two different version of glibc simultaneously, deep down somewhere in the perl modules that the toolchain uses
<lejonet>
Which also meant there was no turning back either
<pie_>
h u h
<lejonet>
So basically even going back to a fully 20.03, functioning, system wasn't really possible, because the toolchain handling all the switching to configuration was borked
<pie_>
how would that even work though besides strange impurities???
<pie_>
you could maybe have run nixos-install from another image
<lejonet>
Well, I'm gonna blame it on some weird design choices in the switching toolchain, like making some scripts be executed unconditionally, but if the condition that triggered it to do something wasn't fullfilled, it would exit early, the problem with that was that it errored out and segfaulted before reaching the "exit early"
<lejonet>
pie_: I could do that to restore the 20.03 configuration yes, but any attempt to go to 20.09 outside of a fresh reinstall didn't work
<pie_>
i was wondering about using it to do the 20.09, but ok, i see
<pie_>
were you able to open any issues
<pie_>
this bothers me
<pie_>
unconditional execution sounds good in that path will always be tested, and activation scripts are supposed to be idempotent
<mvnetbiz_>
If you NixOS-rebuild boot, and reboot would that have worked? That doesn't use the same activation script right? Or does it?
<lejonet>
I didn't have the energy to do that at the time sadly, I spoke a lot with people in #nixos about it, and I debugged it very thoroughly down to what script was segfaulting and so (I sadly don't remember the exact name of the script anymore, but it was the one that was supposed to copy secrets to grub or something like that)
jpds has quit [Ping timeout: 240 seconds]
<lejonet>
mvnetbiz_: any attempt to do nixos-rebuild segfaulted due to ^
jpds has joined #spectrum
<mvnetbiz_>
If NixOS-rebuild failed, how did you even end up with a built activation script to fail?
<lejonet>
Because it was activation part that failed, not the build
<mvnetbiz_>
Oh, never mind, at the `switch-to-configuarion boot` it would fail?
<mvnetbiz_>
I see
<lejonet>
Yea
<MichaelRaskin>
I wonder if just running the script inside env -i would help…
<MichaelRaskin>
NixOS sometimes sets LD_LIBRARY_PATH…
<pie_>
MichaelRaskin: you raise an interesting point if it doesnt _already_ do that
<pie_>
run with a clean environment i mean
<MichaelRaskin>
No idea. Boot management is one part of NixOS code I have not considered reusing in my system
<lejonet>
I tried munging around, and fixing the RPATH of the relevant binaries and so, with no success, the part where I stopped debugging because it was getting redonkeylous was when I came all the way to the perl script that runs the whole activation part, and figured it was probably a module or so to that, that was erroring out
<qyliss>
but nested virtualisation might be a problem I suppose
<MichaelRaskin>
Hm, I might even _have_ nested KVM on that VPS, didn't really expect that
<MichaelRaskin>
RPATH is one thing that probably did not need fixing
<lejonet>
Well, most of the binaries in the toolchain was referencing libraries from two different libcs
<MichaelRaskin>
Directly or as shown by ldd witn un-wiped LD_LIBRARY_PATH ?
<lejonet>
Probably the latter, I don't remember all the details now, it was in november somewhere
<lejonet>
It all started with firefox crashing on me after doing a nixos-rebuild ironically enough
<pie_>
all i can think is something was messed up with your system config but there isnt really a way to substantiate that with this much information
<pie_>
and im probably wrong about that anyway
<pie_>
im just confused because thats specifically the kind of problem nixos is generally built to avoid
<lejonet>
pie_: Yeah, that is why I was so surprised about it too
<lejonet>
and I certainly don't discount the possibility that it was something with my system config, but I reproduced it on one of my servers, and could reproduce it more or less 100% on it
<lejonet>
I had been debating switching back to gentoo before that, this just presented with an oppertune oppertunity, as the likelyhood that I'd have to do a bunch of reinstalls was quite high with the info I had at the time