Thanks for the link!

Re the kernel, I think that's a good approach for the foreseeable future and falls within minding the ancient lion joke.

"a dozen or two motherboards per architecture" - I took the cited comment to mean a dozen or two in total, and "arch-sufficient" as a superlative in the manner of archbishop and such.

Good point, thanks.

"appears to have uncovered some opportunities for TMSR OS to leverage busybox further to slim down the codebase Gales is using" - note that we're not talking big differences here, such that crude metrics alone make a poor heuristic, and the named components do overlapping but different things. It's my belief that daemontools solves real problems, and if you don't use it (or something like it) then you're stuck solving them repeatedly & poorly elsewhere. It may be that I'm unduly biased toward djb over busybox code based on the limited samples I've read, and I'd be glad to take a closer look and report on findings if it would be of value.

Thanks for the points. I'm curious to see how the discussion continues to unfold, though at present it's not a high priority for you to dive into busybox code.

"Get cracking on my code shelf." - just curious, what do you have in mind with this? Reading code, signing vpatches yourself, just mirroring?

My first step is to mirror.

"At what point is kernel "good enough" short term and can he be freed up" - seems to me that building up knowledge of kernel internals is important no matter how "working fine" a frozen version may appear, as kernel bugs can be quite disruptive and require substantial knowledge to track down and adequately fix (compared to userspace C programming for example). It sounds like bvt's pretty far along on that but perhaps best for him to judge, if he's the one signing and to be consulted when problems arise.

Agreed that building up the knowledge is key. I reckon there's a balance to strike between the substantial ground to cover, limited present man power and delivering an initial viable V-tree to be refined over time. Generally, we need to differentiate optimizations that are due and premature.

Thanks for the typo notes and sorry they made it into what was published, fixed.

I have looked at 2.6.32 code briefly, it's ~300Mb smaller than 4.9 - rather nice. But about further plans for it, other than regrinding all RNG vpatches, vulnerability fixes and slimming down where possible, my idea was that when we figure out that kernel causes us some trouble or inconvenience, I would look at the code and fix it. I don't think rewriting subsystems or drivers without real need for that would be useful in any way.

"appears to have uncovered some opportunities for TMSR OS to leverage busybox further to slim down the codebase Gales is using" - note that we're not talking big differences here, such that crude metrics alone make a poor heuristic, and the named components do overlapping but different things. It's my belief that daemontools solves real problems, and if you don't use it (or something like it) then you're stuck solving them repeatedly & poorly elsewhere. It may be that I'm unduly biased toward djb over busybox code based on the limited samples I've read, and I'd be glad to take a closer look and report on findings if it would be of value.

"Get cracking on my code shelf." - just curious, what do you have in mind with this? Reading code, signing vpatches yourself, just mirroring?

"At what point is kernel "good enough" short term and can he be freed up" - seems to me that building up knowledge of kernel internals is important no matter how "working fine" a frozen version may appear, as kernel bugs can be quite disruptive and require substantial knowledge to track down and adequately fix (compared to userspace C programming for example). It sounds like bvt's pretty far along on that but perhaps best for him to judge, if he's the one signing and to be consulted when problems arise.

Now for the friendly typo notes:

to review of December ; straight jacket ; After, following TMSR ; Bootlading ; through which, the ; on v-shaped os means ; _popescu ; to install it on ; dorion_road:I'm ; I'm sure if this task ; also cause me ; is helping me established ; in an of itself ; Jacob's can own

"his beings an engineer" - perhaps usage is evolving on this but if you're pluralizing the "being" then it would seem to imply the whole construct is acting as a noun, referring to multiple beings owned by him, rather than his possible state of being, as I took your meaning to be!

Regarding the blockquotes, I edited the comment to add them back in.

@Mircea Popescu Blockquotes seem to be in place both when looking at source of page and when seeing it in firefox.

Re-reading this, the occasional missing spaces in my quotes is annoying though by and large fixable on read ; there's one broken line however which needs fixing,

I added the spaces and modified the broken line with the fix.

> At what point is kernel "good enough" short term

2.whatever has been "good enough" for about a decade by now.

Not that things like proper rng aren't an improvement ; nor that the actual state of things under the hood's anything besides a coiling web of maggots and magic juice. But good enough short term it's been for many, many years now.

Alright, cool, thank you.

but i do mean ~very~ bad. fractally bad, it even gives them the impression they have been.

but it was never intended as anything other than

but i do mean ~very~ bad. fractally bad, it even gives them the impression they haven't been [writing bad code].

> At what point is kernel "good enough" short term

2.whatever has been "good enough" for about a decade by now.

Not that things like proper rng aren't an improvement ; nor that the actual state of things under the hood's anything besides a coiling web of maggots and magic juice. But good enough short term it's been for many, many years now.