It seems that the implications of the theory that I inadvertently came up with force me to write an article. I could have just declared that other then the hardware as a foundation, the OS must have real business/organization/world-changing usage (even if it is only used to attract people to TMSR), not just some engineers working on self-perpetuation of the OS. And that the prospect of such usage is a necessary part of motivation to start developing an OS. That I did not suggest to start exam-taking the OS development by implementing only the functionality for one use-case, ignoring all the principles. However, now the theory sounds not that deep, and anyway it's more interesting to answer the comments as they are:
Re first question: I could see a BSD-style partitioning of system: all programs separated into core1 and applications; application ebuilds2, with all the dependencies, are moved into a separate repository. OS people take responsibility over the core, perhaps making Linux ABI level of guarantees3, while others are free to do with rest of the software whatever they want. The problem here is that saying that all deployment happens through static binaries built elsewhere is equivalent to saying 'fuck you' to the user. OTOH if the user is supposed to build his software on the core OS using OS-provided tools, would, say, ftjam be part of core or not? I would not expect it to be necessary for bootstrapping... In general, the line between core and applications is rather blurry, and the fact that Linux package managers handle both core and non-core software the same way is stirring the water, so to speak. Or to put it differently, the definition is ambiguous: it does not specify whether this general purpose collection of software is minimal or not; and development tools is the first software set that may or may not get included depending on the answer; OTOH, minimal environments can be too harsh for efficient usage.
Why input from users is required? There is an practically infinite amount of work available for the core, which forces the following question: What things would have to be implemented before people would start switching from whatever they currently use to TMSR OS? IMO it has the following implications:
- How would the work be prioritized? I do not suggests that only the tasks that are necessary for users get worked on, but given that the workforce is limited4, setting the scope would be useful to get users.
- Suppose one day you ask 'Can I run my stuff on your OS?', what would be there to say, 'Uhmm, I suppose?'; and if it doesn't work immediately, what would be the answer to 'WTF have you been doing all this time?'. Having real users and knowing what users would want helps a lot by providing a reference point 'OS - works or not?', but again, yes, this creates the opportunity for OS-making exam-taking. Yet, real usage will be a test that the OS should pass.
- Working on the OS while not having anyone running something on it sounds wrong to me5, and the more intensive/longer/etc. the work without users, the wronger it sounds6.
As far as causes and purposes are concerned, let's try to sort out what possible causes for development of core could be (stated in purpose-like form here):
- Have the OS under the TMSR control, not somewhere by some out-of-WoT entity. This one may be a hard one - when can developers honestly-to-self declare that the OS is now under control?
- Stop importing broken software versions at any stage of system deployment.
- Apply sane security, operation, and development measures that are already in use in TMSR.
- Standardize the runtime environment for servers, instead of having cuntoo/proto-cuntoo/centos mix.
The hardware is already making a hard split between the server OS and graphics-capable OS. Further splits can be enforced by different architectures (ARM64, etc.): as mentioned by spyked, this will enforce lower bound on the versions of the compiler and kernel. This split won't be as big as the one from graphics. Also, I do not see hardware as a significant cause: if there existed a sane and usable graphics stack that didn't come in the same strand with whole spittoon of ???, there would be no problem with running it on the same OS. However, it neither exists nor is currently within the reach of engineering. IMO it is just a constraint that sometimes (but not always) forces a creation of the second artifact, intended to contain the complexity and brokenness of e.g. Linux graphics stack.
- Just enough to be infectious? I would speculate that bootstrapping/package management/development tools are a significant source of bloat; trinque would be in much better position to judge this after finishing his Buildroot experiment. [↩]
- Or their equivalents. [↩]
- There was an attempt to standardize the Linux ABI (LSB/Carrier Grade Linux), which IIRC took ABI as present in some minimal-to-default installation of RHEL. From the practical point of view, in modern Linux it is mostly irrelevant. [↩]
- Though most likely adding more people would not help at all; it's increasing the personhood-percentage of involved parties that would help. [↩]
- After there is something that can be called an OS in first place, of course. [↩]
- A few years ago, while I was still studying, people from a local embedded OS development company did a guest lecture, mentioning that they did ~PHP development for a few years to feed themselves while developing their own OS, until they got the necessary density of contacts to actually live off it. Getting those contacts often meant 'Will work afterhours to put our OS into your HW for free.' [↩]
> all programs separated into core and applications
I think this is a very good point, and it's probably what makes e.g. FreeBSD much easier to manage, despite the community being much smaller than those of Linux distros. As for where to make the cut, my first go-to place would be the POSIX standard, which IIRC also specifies the base utilities. This could be a starting point at the very least, though I guess programs could be added to this set, assuming a good reason is provided... as for what "a good reason" is in general, I have no idea. In particular, I expect that some automation for getting stuff (I refuse to call them "packages" for now) built, along the lines of Portage/Emerge/etc., would be required.
Either way, I don't think the enumeration of components comprising this "core" can be escaped.
> let's try to sort out what possible causes for development of core could be
IMHO the idea is to a. start from some existing basis for both core/infrastructure and application development; and b. use V, thus attaching identities and responsibility to further changes. Stated as such, this probably sounds like a truism, but e.g. it would imply that if ftjam turns out to not be in the core, someone with the knowledge could step up and do the integration work if needed -- and if no one with that knowledge exists, then we have a problem, but I don't think that's the kind of problem that any OS can solve.
> The hardware is already making a hard split between the server OS and graphics-capable OS.
Gentoo (and not only it) seems flexible enough to build both types of OS, and probably more... but that's more of a guess on my part, there's for example the question of how much time it would take to build either, and IMHO this project requires someone capable of answering these kinds of questions in order for it to succeed.
Link's broken ; but tbh I kinda like this article approach to the problem.
In that case it seems to me TMSR-OS does (and it alone does) actually pass this qualification then, as I understand what you're saying. Is this the case ?
I could too, hence all that.
It's funny to watch, by the way, how stable an' regular that "days later" works for this dumbest generation of cucks in history, by the way. I had no idea back then Christina Applegate's the chosen one, to become iconic for the place in ways all sorts of other women aspired to yet apparently never managed. But it's very much her, the daughter of "married with children", married, with children. "You suck!" she tells the nominal hero, that deeply incompent male, exuberantly whiny, militantly ignorant and plenty stubborn. "You've got nothing", she says, "and you can't even admit it". She's right -- he can't ; yet the belated confrontation doth finally send the hero (of a travel story!) on a venture to find himself, three quarters in. This is how long it took to finally get him to move his ass out of his wife's bed/mother's skirts ; and that trip comes to an abrupt end two minutes!!11 later. That's how long he has -- after which it's all suddenly fixed and better and whatever, microsoft has a place for them all, burial's now called "acquihire" and so on. Much like the TV depiction, the irl hero was alive for all of three days, and with him OpenBSD was an actual project, as opposed to a going through the motions, for all of three days. Laugh. Laugh I say. You must laugh, bevelen zijn bevelen.
So... isn't it funny ?
First off, I don't recall a time Linux actually seriously did this, and in any case they've not been doing it for a long time.
However, I believe this must be the very core of the core effort -- those folk must start specifically with an enumeration of such absolutes in a thick permanence sauce. Just like the expectations that logs, for instance, will not go away is perfectly justified, and stuck to, just so other things.
Then permit me to be the very first to say it : FUCK YOU, DUMBASS.
I'm not even against eventually having properly v-treed (therefore source, let's make this plain an' clear for the n-th time, there is no such thing as source outside the v-tree) build tools, ftjam-like or not. But in any practical sense confidence is built through the WoT, not through spurious pretense of the rustics to a franchise they never did have (pretense put forth by whomever to the contrary notwithstanding, as it can't withstand anything) nor could ever possibly have.
The fact that "you built it from source" means exactly nothing above or beyond "you ran a binary" unless you've actually read and understood the source, yes ? Well ?
(Yes I'm aware the traditional rustic defense goes along the lines of "Oh, someone would have noticed" -- but on one hand "someone" noticed rowhammer ; and on the other hand gimme a break, notice. Ask anyone who was ever involved to any degree with any kind of debugging / cleaning / bringing to human shape the open source filth what they think of this "notice".)
I expect this only appears blurry if one dedicates significant resources to actually making it so, not merely by painstakingly avoiding "toxic facts" on the matter but actively cultivating imaginary doubts. Otherwise it's much of a "the line between surgical room hygiene / ergative and absolutive / men and women is blurry" ideological construct, there's no blur there besides whatever blur you bring from home.
To quote a recent quoting,
I do not believe linux is a model to be followed, or all that important, or in any case informative much past the "what not to do" list ; and chief on that list, linus' personal conduct is the principal example of what not to do -- don't fucking bait and switch, it is impermissible to convert the effort people put into fucking up the pantsuits by simply handing the keys over what the everloving fuck. Sell your daughter off to the pinoy sheet brothels first, before this nonsense -- she'll be happier there, anyways.
You have to distinguish two things you currently do not : yes input from users is required, but in certain form. Input from users "whichever way they wish to present it" is not required, or even wanted. In fact, it's not even tolerable, which is why people prepare speeches for parliament rather than go about muttering al day long ; while the toothpaste tube issues toothpaste when squeezed through the designated issuer end, not whichever way it comes out. You don't have unpackaged soft cheeses in your fridge, which you squeeze in your fist whenever you're making a sandwich, why should I have unrestrained users pissing all over, whichever direction and in whatever manner any of them ever came up with that morning ?
There's a forum -- it works, let it be worked. Users want to input, good! Let them talk to people. Users want to "help" in the manalone way, let them go fucking hang, the absolute last thing you wish is for their poisonous offerings to infect your life. There's no further definition available, let alone needed, for malevolence besides this manner of "helping" in the autistic way.
Let me recount a story. So, many years ago a friend of mine had a daughter ; and still many but not quite as many years ago I fucked her sore in every hole together with a friend. It was a pleasant experience I fondly remember, but here's what the father of the daughter I fucked didn't do : he didn't proceed by asking around "what features would have to be implemented before people would start switching from whatever they currently used sexually to his daughter". I didn't give anything up to fuck his daughter, she was an extra fuck not a replacement fuck ; and he didn't particularly relish, or all that much care, how the world was gonna use his daughter -- supposedly if you spend too much time thinking about this "you'll go mad", by which of course we mean "through this sort of mental process pre-existing mental breakage finds manifestation".
I do not believe the approach is useful or informative ; I understand it is shorthand, like most of the things you say I take under protest forcing you to write more articles in response -- but I don't agree it's useful shorthand. In fact, I believe it's the sort of shorthand that keeps people down.
More productive, I suspect : what things could be done right for once, at no great cost to anyone and unclear benefit in the future ? That's, after all, why she grew splendid tits, the 15yo -- because she could.
Traditionally (it's been how many years of TMSR to date ?!) work is prioritized by the criteria of what people feel like doing, subtly mediated by a poorly understood leadership process. That this has produced a large count of blow-ups to date is perhaps grounds for some reform, I grant ; but let me point out that the blow-ups in question have in fact been immensely informative -- and to everyone involved, whether they're in la-la-la mode irrespective. I will definitely entertain discussion, but understand we're discussing finery here, it's not something to be "i don't see why"'d into oblivion, aite ?
I also find your 4th footnote eminently on point (which is why the foregoing paragraph at all), otherwise I'd have just passed it in silence. There is such a thing as table stakes for all kind and manner of discussions, and they often come in the shape of magic passwords.
Articulate the problem you perceive with this, if you will ?
Shall we go back to the daughter ? Decade+ before anyone's working on her, yes ? Also a problem ? And if not, then why not!
Understand, I'm not proposing the opposite of what you say ; I'm merely investigating the substance of what you're saying. I certainly wouldn't mind getting it right, not anymore than you in any case.
I confess I don't understand the question. Everything's under our control if we wish to take it, one can genesis anything any time they feel like, including whatever bundle of software. The point is to build atop foundations under our control rather than waste away whittling down soap in the big/small zones. Nolite thesaurizare vobis thesauros in terra ubi erugo et tinea demolitur ubi fures effodiunt et furantur ; thesaurizate autem vobis thesauros in caelo ubi neque erugo neque tinea demolitur et ubi fures non effodiunt nec furantur. Shall I say it in broken Attic, too ? Or how should I put it best, let's see, what do the users say ?
In fairness, that was a pre-existing split, hardware only copied. There's a split between the "jsut want to" mode, where I am say playing a game ; and the "this'd better not get in my way" mode when I'm say writing an article. And it's not limited to computers, either, girls walk into the room to see what mode I'm in all the time, and on occasion withdraw quietly. It's intellectual life, there's no way out of this, it comes in two modes.
I'm not strictly in opposition to your pov, namely that the split could in principle be cured, at least for computers. Maybe it can, but I suspect the only way it'll be cured is when we actually run republican foundries, because the constraints of hardware are such that performance or abstraction, pick one, and you'll pick the former, and then you'll have microcode in there that only the makers understand, so having the makers in the wot's the only way. But, more on this later.
Yes, I would agree. I think my idea was that those interested in TMSR-OS would declare what exactly they will be doing with it, though it reads dumb, of the 'now, predict the future' sort.
I don't see any disagreement here, the intended users were always these, input from out-of-WoT entities would have been considered differently. Hence, I mentioned ftjam not as an example of tool "someone" might need, but an example of tool that you and Diana Coman currently actually need for your software.
Well, "barely examined" would have been a better expression than just "blurry". I don't think I can produce an exhaustive list of core software off the top of my head.
Neither do I; technically BSD present a better data point, politically there is no difference.
Point taken.
Yes, this is clear, kind of why writing a follow-up article would cross into comical. And anyway, I still need to do the last vpatch for the RNG series...
The problem only appears when the actual user is asking, and only in the model where the user requires specific features. If these requirements are not communicated to the OS people, they have no chance to satisfy them. Though for the core OS, the included functionality should be independent from what user runs on top, so this would not be a problem, I guess.
Yes, everything has its time. I guess my expectation was that direct utility from the TMSR-OS should be extracted all along the way, without delays.
It is also not like I am fiercely fighting for the 'one true way of doing Linux'. More trying to clarify things for myself - thank you for the opportunity!
Myeah, that was not very well thought out. Yes, individual components can be taken under control easily; the distribution will need a set of scripts to bring all of components into "directed movement", so to speak, and that should be it.
[...] far as work on the yet-infant TMSR-OS project goes, there's already plenty of discussion going on and the first order of business is to get it all organized in my head and lay out what I see as [...]