trinque: dorion: yes, I haven't had time to complete the final post, but last I checked y'all were pretty opposed to using busybox-only for the userland.
trinque: so where are we at with that?
trinque: because the final post is little else than gathering the selected items into a source tree, wrapping them in a build process, and cutting a genesis.
trinque: I'll point out again for the logs that my picking busybox wasn't just "whatever, it's small, and it's all there"
trinque: it's that we can cleave shit out of busybox source permanently trivially by using the config flags.
trinque: so it's not only the smallest candidate, but it can be miles smaller still
jfw: trinque: I'm also tardy on jumping back into the OS fray, for one thing my wallet project has dragged out way longer than I naively expected, but I look forward to doing so shortly. But in hopes of advancing the discussion a bit: is there a particular merit to busybox-1.31.1 ? For all I know it's an entirely different thing from the older one I've been looking at and we'll need some common basis
jfw: for what we're talking about.
jfw: that's 1). 2) what do you mean by "busybox-only" - because far as I know you can't possibly mean exactly that, it doesn't have an mkfs or make for example, let alone a compiler. Do you mean, "system which selects components outside busybox only if busybox $version does not contain them"? I'll note that busybox is an amalgam of code from a variety of sources and, ahem, "Adjusted by so many folks,
jfw: it's impossible to keep track" to quote its init.c. One thing I take from this is one's not likely to get a good sense of the code quality of a given part from a random sampling of the overall tree.
ossabot: Logged on 2020-03-11 02:01:59 trinque: dorion: yes, I haven't had time to complete the final post, but last I checked y'all were pretty opposed to using busybox-only for the userland.
dorion: 1 was out of ignorance and it was
conceded MAKEDEV can be dropped.
ossabot: (trinque) 2020-01-24 jfw: trinque: I was ignorant of mdev, looks like just the thing!
dorion: 2 was out of poorly documented dissatisfaction with bb ash, yet he
said, "perhaps his pdksh can be of use."
dorion: jfw can correct me if I'm wrong but I don't think he knew busybox includes
runit. since he was already used to using daemontools and daemontools is the predecessor to runit anyways he went with that.
dorion: please correct me if I'm missing something, but how do you draw "pretty opposed" from the above ?
jfw: I haven't actually tried mdev so I'm not quite at "makedev can be dropped" but I'm certainly open to it.
jfw: If we're adding runit to the mix on the busybox side, then it becomes fair to compare their 800+ LoC init.c to my 30-line one.
ossabot: Logged on 2020-03-11 02:02:05 trinque: so where are we at with that?
ossabot: Logged on 2020-03-11 02:03:07 trinque: because the final post is little else than gathering the selected items into a source tree, wrapping them in a build process, and cutting a genesis.
dorion: if you've made progress on the selecting and organizing into a source tree, why not be satisfied with publishing that and getting feedback ?
ossabot: Logged on 2020-03-11 02:03:07 trinque: because the final post is little else than gathering the selected items into a source tree, wrapping them in a build process, and cutting a genesis.
dorion: ^^ mp_en_viaje jfw bvt spyked diana_coman and any other parties interested in tmsr os ^^
trinque: dorion: so now we have something to talk about.
trinque: if you want "builds crystalspace" to be the purpose towards which we're reaching, might as well install ubuntu.
trinque: if you want "doesn't have batshit bashism" to be the measure of which shell to use, idem
trinque: for the record, my measure is "self-hosts"
trinque: it can be used to build and improve itself. the end.
trinque: ok, so what rankles my ass about your goodness list is you have items at wildly different levels of the tree all flattened together like they're of the same importance and same level of the ontology.
trinque: what's python even doing there?
trinque: this is a wall of hubris, my friend, and sorta flies in the face of what I was trying to convey with the series.
trinque: the "big dream" approach does not work, which is why I started simply, and proceeded outward.
trinque: but anyway. I wasn't describing an item I wish I had. I was describing an item I'm building.
trinque: I propose you delete that list, and you write another. In the new list, write down only the items that will get the machine to boot, and allow the user to edit and rebuild the OS.