The Most Serene Republic has decided to make an operating system. I've received the call to head the project and this article is my first attempt to clarify the needs and requirements for success.
As an implement of TMSR, the operating system serves as the point of integration between V -- the most important advancement in human thought and only sane manner of deploying software -- and all other software worth the mention. Given the sad state of computer hardware and software in these dark modern ages, the switchover guarantees to be bloody in all the correct places.
While the technical implications are profound and technical conversation is likely to dominate the first phases of development, eyes and efforts must be continually aimed at capitalizing on the capacity for TMSR OS to be a political implement to use in talking to the right people as the Republic continues to carve a sane living space for the elite to productively defect to.
The form of the core work follows the function of meeting the dependency requirements of the clients, implicitly : time and money (i), chat (ii), publishing (iii), "the masterclass in economy masquerading as a video game", and strong encryption. Or as the man himself put it, "the legitimate and for that reason possible-in-the-future uses for a computer definitively enumerated : you can publish with it, you can hack with it, and that's the fuck it with it already! You can't pantsuit with it, nor should you."
To address some management considerations prior diving into the technical topics :
- Continuing to hold the initial design and strategy conversations in #trilema is preferred, a #tmsr-os channel is the next step when the technical details deepen and as a landing beach for new blood.
- I see no reason to change the process of the author and signers of a v patch writing a blog article to provide context on the patch and their seals. A central website that aggregates and organizes the articles and patches as well as high level introductory literature can be added as an integrating layer.
- Weekly or biweekly planning and reporting articles to clarify status, maintain alignment and ensure reporting is central. As more ownership is taken and work specified, delivery timelines for the high level goals will solidify.
- trinque mentioned in the log he was working on a ticketing system ; mod6 also stood up a ticketing system (tbot) for TRB, but I'm unsure if it's still online. I think a ticketing system is smart, my present preference is to use mod6's if available, primarily because it was complete and would only require mod6 to genesis and someone to stand up.
- Much of my thinking so far has been focused on clarifying the technical requirements and who we have today to deliver on that front. As the technical requirements become properly specified, raising the quantity and quality of participants we become a higher priority.
So what are the primary domains of the technical work ?
- The Linux kernel
- Owner: bvt
- Status: Linux 4.9.95 was genesis'd and feeding the RNG with FG is implemented.
- Questions/Comments: Latest vpatch and write up coming over the weekend. Unclear at present what next priorities are. There was previous mention of rolling back to 4.4.
- The Compiler and C Library
- Owner: ave1 (tentative) (iv)
- Status: Work towards a GCC 4.9 genesis underway, unknown how far developed.
- Questions:
- I understand GCC 4.9 coming into Republican use as the last GCC prior to version 5 wreckage. Gales Linux uses 4.7.4 in part because it's the last GCC that doesn't require any C++ to compile. What are the cost/benefits of genesising 4.9 vs 4.7.4 ?
- C, C++ and Ada are the desired initial GCC front-ends.
- Static or Dynamic linking ? musl, glibc or other C library ? Is there a way to have the default be static linking, but provide a dynamic linking option for software that won't link statically, e.g. libGL ?
- Coreutils
- Owner: unowned at present
- Status: Cuntoo bootstraps from Gentoo stage3, Gales Linux bootstraps from Busybox.
- Questions: Busybox is spartan enough for one to approach understanding, though it leaves a lot to be desired. Gentoo stage3 is a more robust tarball of binaries from Gentoo that requires a Gentoo system to build and doesn't support cross-compile. What does a Busybox + Gnu Coreutils approach look like in comparison ?
- Package Management
- Owner: unowned (v) at present
- Status: Cuntoo uses Gentoo's portage/ebuild based on Python, Gales uses a custom, shell based build script system.
- Questions/Comment: The former is more mature and more complex; while the later has far fewer packages ported, it's much simpler. Porting the dependencies of the list of implicit TMSR OS clients is the first priority once the framework has been decided.
- Graphical Interface
- Owner: unowned
- Status: needs reporting
- Questions/Comments: X11 is not ported to /cuntoo/portage. I am under the impression that it could be emerge built, but would be under the more traditional /usr/portage. Gales doesn't have a X11 port, though jfw has a recipe to built the X11 stack by hand.
- The Install Process
- Owner: unowned at present
- Status: livecd/usb, initramfs
- Questions/Comments: Process for creating and using install media for deployment.
- The Boot Process
- Owner: unowned at present
- Status: BIOS, bootloader, init
- Questions/Comments:
- Does Coreboot fall within the scope ? This seems it should be optional given limiting TMSR OS to Corebootable machines would be quite restrictive. With that being said, owning the BIOS for those who do want to take the step is a big win.
- Bootloader: LILO, grub.
- init: Gales Linux uses a 57 LoC init in combination with djb's daemontools.
- Process Supervision and Logging
- Owner: unowned at present
- Status: Gales uses djb's daemontools and multilog while Cuntoo imports Gentoo's OpenRC based init system.
- Questions: Gales uses daemontools and multilog to great effect, including leveraging daemontools to simplify the boot process.
There remain many wrinkles to iron out, but here is where I make the cut in this attempt to clarify my understanding of the way forward, solicit feedback from the commenters and encourage any bystanders to come out of the shadows.
- The Real Bitcoin [^]
- ircd as a predecessor to gossipd [^]
- MP-WP, see The Whet and billymg's v-tree [^]
- He shared the news of his genesis efforts in the log, yet to respond to my ping about his status. [^]
- lobbes is taking up Gentoo portage/ebuild reporting; spyked has published his notes on bootstrapping Cuntoo; it's unclear at present if either wants to own this domain. [^]
A tiny bit to add on the gcc 4.7 vs 4.9 is that so far all the GNAT versions have used (as far as I'm aware) 4.9 and mainly because of this Eulora has also been tested/compiled on 4.9 rather than anything earlier than that. So any potential downgrade would require at least a re-look into all of this.
Comment by Diana Coman — November 29, 2019 @ 18:41
Actually everyone who makes patches should just maintain his own code shelf, what "central". Let the WoT be.
Why ?
Amusingly, I mostly use 4.4.7.
Anyways, my main takeaway here is that jfw actually has A LOT of publishing to catch up with.
Comment by Mircea Popescu — November 29, 2019 @ 23:32
> it's unclear at present if either wants to own this domain.
In particular the Cuntoo bootstrapper is Trinque's thing, so IMHO he'd be the best person to own it if he's willing. But note that the bootstrapper falls more into the "installer" area, and it's unclear whether Trinque's bootstrapper or Gales' installer would be better (moreover, I'm not really clear what "better" means) or whether there's space here for a new item. In any case as I mentioned in #t too, I'd be for taking any one presently unowned item, but rather based on its merits than any arbitrary "interest".
> jfw has a recipe to built the X11 stack by hand
So he got to build X11 statically? That'd be great news, in any case, it's something worth writing about.
> The Boot Process
IMHO LILO works fine as it is and I wouldn't touch it unless there's some good reasons for changing it. As for the BIOS, I'm not sure it's even possible to own that at the moment, since most motherboards come with their own proprietary thing.
The iffier question here is whether there's any reason to support EFI at all. The newer hardware comes with it enabled by default, and I've personally touched laptops so broken that they wouldn't even boot USB sticks in legacy (non-UEFI) mode. I'm avoiding buying any post-2014 hardware for precisely this reason, but well, I really don't know what to make of this.
> What are the cost/benefits of genesising 4.9 vs 4.7.4 ?
I'm curious what Ave1 has to say on this matter; meanwhile, on the C/C++ matter in particular: it seems that C++ isn't going anywhere, as there's plenty of code out there depending on it, most notably TRB and Eulora. TRB requires boost of all things to run, so there we go.
Comment by spyked — November 30, 2019 @ 09:07
One more thing re. package management: as MP says, whatever package management TMSR OS ends up using, it absolutely has to obey V and not the other way around. There's no other recipe for sanity IMHO, and this of all things will drive ownership over so-called "packages": if someone wants to use a package P in TMSR-OS, then why haven't they genesized it yet?
Comment by spyked — November 30, 2019 @ 09:11
[...] hash reference is not in keeping with V principles, but taking ownership of the whole mess will be a larger project. [...]
Pingback by Gales Linux initial release « Fixpoint — December 1, 2019 @ 21:05
[...] owed Robinson Dorion an estimate on my auctionbot work Saturday, and seeing as it is Sunday night I will address this [...]
Pingback by Workplan: December 2019 « Krankendenken — December 2, 2019 @ 04:11
@Diana Coman Thank you for that insight, knowing what infrastructure is already tested on what certainly makes a difference in the decision. I'm looking forward to what ave1 has to say.
Comment by Robinson Dorion — December 2, 2019 @ 18:08
@Mircea Popescu
Maintaining one's own code shelf sounds good to add to contribution requirements/guidelines, along with e.g. registering a key with the WoT.
The thinking behind a central aggregator and organizer was to have a coherent entry point to the project and the WoT, e.g. the blogs of the people doing the work. Similar to how http://therealbitcoin.org is an entry point to TRB. The site could be made to be mirrorable.
My first motivation was for my own sake of organizing and referencing work to be done. Upon reflection, I could simply make a page on this blog which I update as needed for that purpose.
4.4.7 usage is interesting to know about.
Do you think it's worth putting on the table for analysis next to 4.7.4 and 4.9 ?
jfw has made some ground on the publishing front with the introduction and initial release of Gales Linux.
Comment by Robinson Dorion — December 2, 2019 @ 18:34
@spyked
Given the troubles you documented in your Cuntoo write up and the not yet fully documented work needed to integrate V usage into Gales in general and make Gales produce a v-genesis as a starting point, the first move from my perspective is to define what is needed/wanted and see what can be taken from both.
I asked him in #o to clarify if it's indeed static or dynamic linked musl.
I like LILO and EFI systems are the only reason I've found to use grub. As to whether TMSR-OS supports EFI systems, on the one hand, I interpret Eulora being an implicit client means new hardware shall be supported, so EFI ; on the other hand, TRB being an implicit client means if one wants to implement an airgap to spec, old hardware is imperative and my bias presently is to stick with LILO. Thus, grub and LILO support both fit on the table.
The motivation behind the BIOS ownership is no one should have to run the vendor blobbed BIOS unless ~they want to~. While blobbed BIOS may be fine for Eulora use cases, it's not advised for TRB. What I have in mind for a starting point is to use coreboot/linuxbios. As worthy hardware is identified signed configs are published and the corebootable hardware available to the tmsr-os operator grows. JFW has a config for the x200 Thinkpads, I don't know if lobbes dug into coreboot in this x61 set-up.
Have you used Coreboot ?
I'm also curious what he has to say.
I didn't mean to imply that C++ was going away anytime soon -- and in point #2 there noted it as a front-end -- just that 4.7.4 doesn't require C++ for the minimal build of the compiler itself.
Comment by Robinson Dorion — December 2, 2019 @ 19:49
Re: "coreboot" (aka "linuxbios") -- I've used it industrially, and published certain materials useful for those bringing up / debugging same on compatible AMD irons.
AFAIK the last Intel chipset where a "blobless" linuxbios could operate, was the "945" as found in e.g. Thinkpad X60/61; last such AMD chipset -- "G-series", as found in e.g. "PCEngines APU1".
On certain more recent x86 irons, is possible to bring up linuxbios "with blobs", but this rather defeats the point of the exercise -- a dedicated spy core runs a large (multi-MB) evil-smelling blob of RSA-signed mystery meat.
Comment by Stanislav Datskovskiy — December 2, 2019 @ 20:04
Linux and GCC (plus binutils, arguably part of the compiler) are by far the largest pieces by weight, and consist of many subsystems. X11 is up there too. Might be worth subdividing and planning to get multiple people on them.
You can certainly use busybox or whatever lightweight things by default with GNU stuff as an option.
Thinking aloud re portage and similar vs. V, as I see it either a common standard, or tool to abstract over a proliferation of standards, is needed for how applications get built and installed. V gives you a source tree in a location of your choice. OK, then what? You still need to build it. There might be dependencies - unless we're banning those outside of the base, in which case what, every GUI app ships its own GTK or Qt? Every script ships own interpreter? Then how does the rest of the system find it, e.g. installing to somewhere in the shell search path.
In the domain breakdown, note that firmware and bootloaders are a pretty different domain from init scripts and syslog; more in common with the kernel really.
Re LILO, I'm not too thrilled with the code from having poked at it. I'd readily believe GRUB is worse, though perhaps there's a distinction to be made between grub 2 and legacy. Concur re UEFI being evil but necessary if modern hardware is relevant. GRUB isn't strictly necessary to work with it, e.g. there's the in-kernel stub loader, and there's some ELILO thing. One particular pain is it's far more complex than BIOS and vendors don't always implement it consistently.
Re GNAT - it's Adacore GNAT that's in use, right? So it's at least somewhat divergent from the GNU 4.9 tree; I don't know if this is just in the frontend (written in Ada) or the backend (C/C++ and machine definitions) too. Probably worth researching, e.g. better to be able to fix backend bugs in one place if possible.
Sadly no, this was on a dynamic musl system. I haven't tried it static yet; expecting a mess due to the dlopen'ed module design.
This; and incidentally I suspect it accounts for a large part of the difference between my ~1 hour, ~3G temp space bootstrap process and the apparently >10G for cuntoo. Also, AFAIK it's not that they totally rewrote the codebase in C++ or anything, but started to compile in C++ mode and make changes assuming it.
Comment by Jacob Welsh — December 2, 2019 @ 22:37
Absolutely nothing the fuck should work like that sad idiocy that I started as the foundation and the previous generation of morons fucked so thoroughly I regret even mentioning such lofty things to such lowly idiots. It's such eminent uncomprehending & offensive fail as to well outcompete the generation 0's ROTA monument to nude imbecile humanity.
You're the coherent entry point, that's what you do, own it as such.
> Do you think it's worth putting on the table for analysis next to 4.7.4 and 4.9 ?
Sure, why not.
> I interpret Eulora being an implicit client means new hardware shall be supported, so EFI
I dunno Eulora cares about this either way ; your problems will start once various systems won't boot your stick because uefi considerations, for instance.
> in which case what, every GUI app ships its own GTK or Qt?
No, every GUI app is a patchset on the GTK tree.
> OK, then what? You still need to build it.
Hence why only-one-build-system, so it's ~implicitly~ clear "then what". This was one of those implcits that never needed explicitation, it should have forever stayed implicit.
Comment by Mircea Popescu — December 2, 2019 @ 23:13
@Mircea Popescu
Thank you, Sir. The coherent entry point I must be then.
I re-read La Serenissima and Personal Sovereignty this morning and the identity being allodial property of the person point sunk in :
And layering on the factor of the leverage of invested individuals the advantages amplify.
On GCC :
Ok, GCCs 4.4.7., 4.7.4 and 4.9.4 are all up for consideration.
Comment by Robinson Dorion — December 3, 2019 @ 21:04
> point sunk in
I expect that'll be a recurring experience, hence the "word by fucking word" sura.
Comment by Mircea Popescu — December 4, 2019 @ 03:47
[...] holiday further stress this weakness12. This week I have a lot more external stability and with my increased responsibility I must strengthen my hands at this fundamental [...]
Pingback by RMD: Reconciling Plans and Execution « Young Hands Club — December 4, 2019 @ 20:34
[...] this week, focus at the start of the week was aimed at responding to comments in the log and on the Implementing TMSR OS [...]
Pingback by RMD review, Dec 2nd-6th, 2019 « Young Hands Club — December 7, 2019 @ 07:59
[...] 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 [...]
Pingback by Work plan for (the rest of) M12 2019 « The Tar Pit — December 7, 2019 @ 16:16
[...] implicit clients of TMSR OS are the implementation tools of economy, i.e. medium of exchange 1, punishment gazette 2 and public [...]
Pingback by Contribution Guidelines for TMSR OS « Dorion Mode — December 14, 2019 @ 06:32
[...] uses for a computer are there, anyway"; meanwhile, Dorion does a first breakdown of the system's components and, among others, states its mission and some of the reasons why all of this is needed and useful; [...]
Pingback by Bootloading operating systems, some opening bits and the current state in personal computing « The Tar Pit — December 31, 2019 @ 09:20
[...] responsibility was further clarified in my mind December 3rd as Mircea Popescu disabused me of the notion some central website ought exist. You're the [...]
Pingback by TMSR OS, January 2020 Statement « Dorion Mode — January 27, 2020 @ 04:12