Dorion Mode

March 4, 2020

TMSR OS, February 2020 Statement

Filed under: TMSR OS — Robinson Dorion @ 07:21

For the month of February, 2020 I didn't manage to deliver any of my agenda from the last report. With that being said, not all was lost and a point of reporting is to learn your lessons and improve how you work with people moving forward.

At the beginning of the month, Diana Coman provided me valuable feedback and conversation on the 2nd attempt at the Why it's +ev to contribute to TMSR OS which resulted in deciding to move back up a node and write about why TMSR OS came to be. I didn't make meaningful progress on that or anything else on the list.

The first couple weeks of the month, the majority of my productive output was directed at a conference clients asked jfw and myself to help host which took place Feb 13-14th. We generated some JWRD leads, made presentations we can reuse and turn into articles and gained experience hosting a ~20 person, 2 day event.

The later half of the month I took a couple steps back to do some personal reflection on the past few months and further given the occasion I turned 30 last week. This included picking back up an old, resourceful habit of hand written journaling in an effort to examine some of my unexamined bad habits and replace them with more productive habits. A key shift I'm is looking in the accountability mirror at the close of each day and publishing on my weekly Young Hands plan a reflection on some questions to help me grow consistently in the right direction.

Moving to March, the first month of the Roman year and the resumption of military campaigns, my objective is to strike off the items from last months' list.

  1. bvt's February
    1. published his awk + posix shell + Ada Vtron in a 3 part series (1, 2, 3)
    2. Investigated TRB wedge
  2. bvt's March
    1. moving onto the regrind of keccak RNG patches for 2.6.32 kernel
  3. spyked's February
    1. published Gales build and install report on January 31st
  4. spyked's March
    1. TMSR OS Hardware research
  5. jfw's February
    1. reported completion of the offline component of Gales Bitcoin Wallet and a successful test transaction was confirmed.
    2. published on article on Bitcoin transactions and their signing that's building toward a series of publications presenting the code.
    3. pointed out to musl their move towards an infinite alphabet is misguided and does not have the consensus they may have imagined.
  6. jfw's March
    1. finish the Gales Bitcoin Wallet article series and genesis the code, which will include TRB patches to build on Gales Linux and a sendrawtransaction regrind.
    2. Ask about proposed clearsigning scheme.
  7. trinque's February/March
    1. reported to be closing in on another article in his Republican OS series, but it's not exactly clear what that will cover.
  8. No word from ave1
  9. lobbes reported he'll need to put down TMSR OS work for the short term as mp-wp delivery and changes on the home and saltmining front are higher priorities.

Last but not least, the proposed clearsigning scheme that was seeded could use the sowing of intelligent discussion.

January 27, 2020

TMSR OS, January 2020 Statement

Filed under: TMSR OS — Robinson Dorion @ 04:12

This statement reviews December 2019 and January 2020 TMSR OS developments and previews the work ahead for February. I said I would make a statement at the beginning of January to review December and plan for January, but ended up having too much fun as the year turned and didn't regain my bearings until mid-January. Please accept this under the traditional MPEx reporting standard of one late monthly statement per calendar year. Moving forward, my reporting plan is to publish statements monthly that reflect on the prior month and report prospectively on the month to come. My weekly reports on Young Hands Club will continue to include TMSR OS activities and to tighten the feedback loop and keep the plans structured as flexible road maps rather than straitjackets I'll comment with a status update mid-month on the prior statement.

Yesterday, January 25th, marked two months since I received the call to head up TMSR OS :

mircea_popescu: yo dorion , you wanna head the tmsr-os project for us ?
diana_coman: just in case he had found things moving too slowly around here, lolz.

Unsurprisingly, Diana Coman had anticipated the potential of such a development a couple weeks prior :

diana_coman: dorion jfw current tribulations in tmsr might even push your schedule earlier re getting more visible and involved.

After following TMSR from the shadows since 2015, while manaloning with Jacob all the while, I didn't hesitate to take the call once I'd confirmed what heading the project meant :

mircea_popescu: http://logs.ossasepia.com/log/trilema/2019-11-25#1953458 << nothing new or different, same old thing management always was. write a plan, get people to ~commit~ to parts, chase the commitments, reschedule as needed and so on.
ossabot: Logged on 2019-11-25 14:32:04dorion_road: http://logs.ossasepia.com/log/trilema/2019-11-25#1953428 << my initial bias is to say, yes I want it. Before I take the claim though, I have to better understand what the responsibility of heading the project means.

This 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 coherent entry point, that's what you do, own it as such.

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 :

La Serenissima does not recognise nor will ever enforce any sort of claim of any entity that purports to impinge on the sovereignty of persons. No entity may claim rights to person's identity under this rule, and if they try to they're being the enemy and should be treated like the enemy. For all intents and purposes identity is allodial property of the person therein represented, and no convention may touch it.

And layering on the factor of the leverage of invested individuals the advantages amplify.

If project C has a decision making system formed out of 18 elements, which each obviously will require a separate pitch, as well as 39 groups formed out of the 18 elements in varying compositions, while project D has a decision making system formed out of one single person, we can say that D offers leverage and couldn't be bothered to mention C again.

There ain't going to be no tmsr-os.orgUSG.dnsTVraft, http://dorion-mode.com/category/tmsros/ is where it's happening.

Given this is the first report, let's link in some of the preceding work that was done. Trinque published Cuntoo November 2018 and between then and November 2019, diana_coman , bvt , spyked , hanbot , lobbes , mod6 , and shinohai had published installation reports.

Despite being instructive on various levels, trinque himself didn't see continuing its development to be sustainable and said he'd be pivoting to a kernel + busybox style arrangement for his own stack.

My familiarity with jfw's Gales Linux1 was encouraging and since he'd just published it, having Republican eyes look it over is a good step towards considering what we have to use to forge TMSR OS.

So given than context, what's been going on these past couple months ?

On November 28th, Mircea Popescu clarified The TMSR-OS Implicit Clients which is a high level description of the software TMSR-OS must be prepared to serve.

On November 29th, I published Implementing TMSR OS which outlined some management objectives2 and the domains of technical work to be owned and delivered. The comments were pretty active there, with a major technical takeaway being GCC 4.4.7, 4.7.4 and 4.9.4 are all up for consideration when an owner of the compiler and C library antes at the table.

On December 2nd, Mircea Popescu comments on the weight of the efi/uefi problem in #trilema :

mircea_popescu: anyway, the efi/uefi problem is actually looming the largest here.
jfw: myeah. if Intel decides the PC architecture is no longer the PC architecture, OS maker has to bear the burden ?
mircea_popescu: the nsa is firmly entrenched in controlling that sweet, sweet path to diff power analysis, they've glued it thoroughly with all the broken glass of "energy efficiency" faux ourdemocracy preoccupations, it strikes me as one of the things that'll only dislodge once the emperor himself is rapemeat.
mircea_popescu: jfw, the ideal solution here'd be a de-uefi-izing dongle.
mircea_popescu: but in any case, the item's probably the most contundent impediment to sanity in computong
jfw: But what do you put in its place? Reversing boards was tough enough as I gather even before the standard fritz chips
mircea_popescu: myeah.
mircea_popescu: i dunno, i'd rather this didn't end up with a tmsr motherboard.
mircea_popescu: in any case, my point being, this whole uefi thing needs some serious mapping.
jfw opens up the spec PDF he had lying on HDD, is reminded it's 2500 pages
mircea_popescu: there;s at least one major separation in the uefi latrine (plenty others, of course, the thing's fractally broken), which fortunately occured just about that moment in time when intel chips became thoroughly useless. so not supporting uefi-2, "must have to work" is relatively a small loss, as it goes with the shitty spycore intel chips anyways, which nobody wants (though might be tolerated in some roles for cheapness' sake
mircea_popescu: ). uefi-1 however is just this jumble of works-with-or-without, maybe-so-maybe-not, up to indeed about 2015 or so.
mircea_popescu: getting concrete details on this partition would certainly help, as a starting point.
mircea_popescu: i don't really know anyone who both a) is technically literate and b) thinks post 2015 intel chips are actually worth money, as it happens. a situation eerily reminiscent of every other socialism's progress, late sovok folk similarily didn't think late sovok artefacts worth deploying.
jfw: Are the post-2013 AMDs any better? 'platform security processor' to keep up with the competition right?
mircea_popescu: prolly just less documented equally worse, nfi.
jfw: the noted split in UEFI severity is a point.
mircea_popescu: Where do anti-good ideas come from? They come from misguided attempts to do the impossible - which is another way of saying "trying to ignore reality."
mircea_popescu: not bad, huh.

Spyked stepped up to the plate here and published his initial report on Bootloading Operating Systems December 31st, through which the decision to support a dozen or two motherboards per architecture and let the rest wither was made.

On December 5th, I drew on some ancient trilema articles and noticed TMSR OS may have the mid to long term profit center potential those articles describe :

dorion_road: It occurred to me this morning, this tmsr-os project could be utilized medium to long term in both lifetime support consultancy and the hottest business idea in btc (code review and code insurance) ventures.
dorion_road: I haven't developed it very far past what's in those articles and what we've done to develop JWRD, but seems like there is a medium to long term profit center to establish.
ossabot: Logged on 2019-05-17 19:17:54 trinque: republic is scant of profit centers

Ideas aren't worth shit without action, but nevertheless, informed long term vision and mission are imperative.

On December 5th, bvt published his vpatch and article to Cement Keccak Hashing into Kernel RNG, continuing his prior work of ripping out Linux kernel RNG and replacing it with a driver that could be directly fed with random data provided from userspace (i.e. from FUCKGOATS). You know, that feature that's, in part, "turning the currently worked-upon cuntoo 3 from a flavour project some group stylistically flavours to a must-have item with no possible competition in the professional (as opposed to toy&smartphone) IT space."

On December 6th I managed to reel lobbes back into the project :

dorion_road: http://logs.ossasepia.com/log/trilema/2019-12-04#1954338 << on the one hand, there is other work to be done aside from writting code, but on the other hand, portage/emerge/ebuild system is python.
ossabot: Logged on 2019-12-04 22:32:39 lobbes: though tbh, this whole experience makes me think that maybe computers just ain't my thing. Perhaps I ought to think about BingoBoingo's writing for Qntra course a little more instead of this TMSR OS project
ossabot: Logged on 2019-12-04 22:49:59 lobbes: and even then, it has always been 'soft computering' like reporting, sql queries, excel jockying, etc. The only programming language I really know is python (and that I've only ever used here in tmsr)
dorion_road: while I understand you wanted to the logging project to go smoother, but you were also picking up a new langauge for the job.
lobbes: this is true. I've given it some reflection, and I'm going to go ahead and commit to diving into the ebuilds.

Between December 9th and 10th I engaged trinque in #trilema and with MP's help, got commitment from him to provide high level analysis generally and a look at Gales Linux in particular, the fruit of which so far has been his enlightening Republican OS series.

  • Part 1 was published December 28th which establishes solid definitions of Republican and Operating System and discusses hardware selection, compiler, bootloader and kernel with line count measurements of various options.
  • Part 2 was published December 29th which establishes solid definitions of complexity and ownership and discusses and weighs glibc vs musl for libc choice.
  • Part 3 was published January 20th which details the Linux bootprocess on ATX-compatible computers and weighs busybox vs non-busybox system.

Part 3 4 appears to have uncovered some opportunities for TMSR OS to leverage busybox further to slim down the codebase Gales is using --namely using busybox's native mdev for device management, init for init and syslog or logging in place of MAKEDEV, jfw's custom init and multilog via daemontools which Gales use.

On December 9th, bvt committed to giving Gales a test run and published his Gales Installation Report December 29th.

On December 11, Mircea Popescu laid out the important marks against python 5 :

dorion_road: http://logs.ericbenevides.com/log/trilema/2019-12-10#1954799 << hmm. I know python is discussed at length in various log threads, for the sake of clarity, would you mind summarizing the most important marks against it ?
ericbot: Logged on 2019-12-10 19:25:02 mp_en_viaje: anyways, i have serious reservations about anything-python. it's the first time for me, i never thought before a lang is basically the satan ; but it seems to me anything derived off python's going to be stupid, for that reason.
mp_en_viaje: dorion, i wouldn't. let's use the call-and-response format for this. so, what would you say is the problem the republic's formed to resolve?
dorion_road: good question. the problem of maintaining a hierarchy of indivdual agents.
dorion_road: individual*
mp_en_viaje: ever heard / seen someone say "bring it" ? as in you know, the challenge, there's some kinda threat an' the response is... bring it
dorion_road: yes, I have.
mp_en_viaje: the job of gnoseology, the collected product of thought, is to enact partitions, and record them. some of these are more interesting than others, as illustrated through experience ; an examined life is exactly this "following phenomena while aware of the partitions list"
mp_en_viaje: i'd say the most interesting partition available upon "living things" is whether they are ready. there's the living things that are, and the living things that aren't. hence that whole discussion of http://trilema.com/2017/the-day-of-failure-trilemma/
mp_en_viaje: now, people as a particular class of living things are perverse (this is called "intelligence" in pantsuit gospels), meaning they also have a recursion built in there.
dorion_road: that's an interesting partition for sure.
mp_en_viaje: practically this enacts another partition, nietzsche's will.
mp_en_viaje: now there are three groups : the ready, the willing unready, and the dumb unready. in more traditional terms the middle class is denoted as organized stupidity.
mp_en_viaje: they'd like to be ready, see. they just... aren't. and because people are perverse, this tends to manifest rather as exam taking than actual improvement. they don't become any ready-er, they just become adept at pretending they are.
mp_en_viaje: this having progressed unchecked for lo these many years, the principal problem of the republic is dealing with organized stupidity. this is a lot like any other cleaning job, because yes there's no difference between the filth that supports vermin infestations and the "collective action" that supports the marauding idiots.
mp_en_viaje: my objection is that foremost and before being any other thing, python is a tool for the wilfully stupid.
mp_en_viaje: hence the link relating it to wikipedia recently that now of course i can't find. basically what it does seems to me in any and all particulars based upon the forwarding of the "group action" agenda of the only evil in this world ; much like the republic's in all workings promoting itself python's in all its workings first supporting the enemy.
mp_en_viaje: the problem with this argument of course is that it can be applied quite well to A LOT of the things we use ; most notably c++. but it's at the core, i suspect, if unexpressed, of why nobody ever pushed for say c#.
diana_coman: fwiw I wanted to add precisely ^ .
dorion_road: python is then not available to meaningful examination because it has been exam taking and pretending to be ready (e.g. usg.mit now uses it instead of scheme), rather than actually making itself ready for human use.
mp_en_viaje: no, python is a tool built so as to permit the unready to write very bad code.
dorion_road: ah, now I see.
mp_en_viaje: but i do mean ~very~ bad. fractally bad, it even gives them the impression they haven't been writing bad code. without prejudice to lobbes, look at his experience, not necessarily just since sept.
mp_en_viaje: i don't think it's him ; i think it's the damned python.
mp_en_viaje: i am not proposing bash is good ; but i made a point of it in that context because i believe it is in this respect opposite. it has all the ills naggum finds it, yes, but it does not have that one thing that produces pete dushenskis out of otherwise promising young men.
mp_en_viaje: it doesn't promote smarm.
dorion_road: mp_en_viaje makes sense, thanks for laying it out.
mp_en_viaje: this'd be to my mind the string holding pantsuit online together : python, wikipedia & wediditreddit.

On December 11th, I published Heading TMSR OS to further detail my perceived responsibilities owning this position. I've made progress on many of the points, but there remains substantial work to do to close the various open loops. On December 14th, I published Contribution Guidelines for TMSR OS to document established best practices. On December 16th, I published TMSR OS Mission and Vision Statement Genesis. On December 19th, I published Some Reasons Contributing to TMSR OS is +ev.

On December 23rd, lobbes delivered his article on Portage and ebuilds.

On December 18th, Diana Coman shared her initial thoughts on v-shaped package management in #ossasepia :

diana_coman: jfw, dorion_road while I haven't really spent time specifically pondering the v-shape of a package management system, I think it essentially stems from that fundamental "each V-tree" is the context of its all vpatches; as such, for one thing there isn't an "automatic dependency resolution" external to the v-tree because what would it do anyway, mess up trees or what exactly? and the problem otherwise switches more to a proper grind ...
diana_coman: ... of the tree ie a reader/signer's thing rather than a system; ie possibly even different grinds of "my OS" since anyway, tmsr-os or not, it's still up to each user what exactly they run on their machine.
dorion_road: http://logs.ossasepia.com/log/ossasepia/2019-12-18#1013429 << the matter needs to be considered further and i read your reasoning to be strong. in each deployment the user subjectively selects the vpatches and sigs for a particular machine and his plans for it.
ossabot: Logged on 2019-12-18 12:33:03 diana_coman: jfw, dorion_road while I haven't really spent time specifically pondering the v-shape of a package management system, I think it essentially stems from that fundamental "each V-tree" is the context of its all vpatches; as such, for one thing there isn't an "automatic dependency resolution" external to the v-tree because what would it do anyway, mess up trees or what exactly? and the problem otherwise switches more to a proper grind ...
diana_coman: it's just my initial thought on it really, so I expect there will be more discussion on it esp as things get moving otherwise, certainly; the main thing though is that in this/similar, I fail to see much use/space for ebuilds/portage/very-similar.

Between December 29-30th, Mircea Popescu, trinque and bvt conversed on what v-shaped os means in #trilema :

mircea_popescu: "A feature that I liked a lot is that shell is the only scripting language in the default install of the distribution. Typically perl and python get pulled in unconditionally as a build dependency of a runtime dependency of some rarely-used default-installed utility, or are directly used to implement package manager, etc. With Gales, a decision about what scripting language to use can be made without constraints created
mircea_popescu: by ready availability of python or others." << indeed this is mindblowingly beautiful, and as far as i current;y know the foremost fearher in jfw 's cap.
mircea_popescu: feather*
mircea_popescu: neways, as to the burning "OTOH, I wonder if things like Apache or imagemagick get installed, how will the package management system work out, and how comprehensible will system stay?" question -- i see the merit of using the clean spot as a fixed point to attempt expanding cleanliness. so, it would work by apache becoming tmserv or w/e, and not sucking anymore.
mircea_popescu: at least, ideally.
mircea_popescu: or to put it another way, i do not believe it is either intelligent or even tolerable to try and carry forward the "install" paradigm from derpworld. something much more akin to diana_coman 's work on eulora is what "get installed" will have to mean.
feedbot: http://ossasepia.com/2019/12/29/the-shady-business-with-shaders-in-cs-notes-on-graphics-in-eulora-ix/ << Ossa Sepia -- The Shady Business with Shaders in CS (Notes on Graphics in Eulora, IX)
trinque: mircea_popescu: does this mean "everything is always built and installed" ?
bvt: mircea_popescu: ty; fixed.
trinque: I don't for example need anything GUI-related in an embedded linux device
trinque: I agree that there should be single, correct answers when choosing components (as I'm trying to lay out the options for such selection in my series), but not that each component is always present in any system.
trinque: they are however all to be in the source v-tree, of course.
bvt: mircea_popescu: re second q, imho cleaning up the components will be driven by how the OS gets [re]structured around V, too early to say right now
trinque: bvt: not trying to be a pedantic dick over here, but it's v that's the boundary around the other stuff, not the other stuff around v
bvt: at the individual v-trees sure, but on the yddragsil level?
trinque: no, there's only one v tree
trinque: we've just only ever composed fragments of it yet.
bvt: in this case, i can restate it as 'depends on how current fragments will get composed into one tree'
mircea_popescu: http://logs.ossasepia.com/log/trilema/2019-12-29#1956202 << not necessarily, what i meant was, "everything is first read, then the ints are fixed, then it's read some more, then all the shit is taken out, bit by [http://fixpoint.welshcomputing.com/2019/draft-gbw-node-schema/?b=Compared&e=be#select][bit], then eventually a small pile of actually useful and working code is left behind, implementing 108% or so of what the old pile actually did while removing 98% or so of what it had no business doing"
ossabot: Logged on 2019-12-29 13:49:02 trinque: mircea_popescu: does this mean "everything is always built and installed" ?
mircea_popescu: http://logs.ossasepia.com/log/trilema/2019-12-29#1956205 << i don't think anyone's proposing all components should be present in all systems. rather, i expect the v-way to do this is end up with a large tree, with some usually-favoured leaves or final branches. the gui/nogui split seems very early, like one of those
ossabot: Logged on 2019-12-29 13:51:19 trinque: I agree that there should be single, correct answers when choosing components (as I'm trying to lay out the options for such selection in my series), but not that each component is always present in any system.
mircea_popescu: http://logs.ossasepia.com/log/trilema/2019-12-29#1956212 << for some reason the proposal there's multiple choice there sits ill with my totalitarian mindset ; but we don't have to argue about it rightnao.
ossabot: Logged on 2019-12-29 13:57:52 bvt: in this case, i can restate it as 'depends on how current fragments will get composed into one tree'
mircea_popescu kicks ossabot
mircea_popescu: hey!
mircea_popescu always knew kicking mechanisms is legitimate maintenance technique.

On January 12th, the decision to port bvt's kernel RNG work from 4.9.95 to 2.6.32 was made :

dorion: mircea_popescu in light of never moving off linux 2.x series, it seems to me bvt ought to port his rng work from 4.9.95 it currently sits on to 2.x.
dorion: perhaps it's not an immediate priority, but I'd like to clarify the path forward.
mircea_popescu: http://logs.ossasepia.com/log/trilema/2020-01-12#1956783 << well, or at the very least comment on it.
ossabot: Logged on 2020-01-12 12:47:24 dorion: mircea_popescu in light of never moving off linux 2.x series, it seems to me bvt ought to port his rng work from 4.9.95 it currently sits on to 2.x.
dorion: mircea_popescu comment on major/important changes between linux 2.x and 4.9.95 ?
mircea_popescu: you're not serious, are you ?
mircea_popescu: between 2.4 and 2.6 the principal change is how kernel modules get loaded (they were actually linked pre 2.6).
mircea_popescu: between 2 and 4 the difference simply is "2 was a linux kernel, 4 is treasonable atrocity built atop 3, which is how you say '''mike hearn''' in linux"
mircea_popescu: https://upload.wikimedia.org/wikipedia/en/timeline/a390b4b428edb39f3d7f6fcd66aa2d05.png << this timeline might help your visual style i guess.
dorion: mircea_popescu re seriousness, I know it'd be a helluva lot, but I don't imagine porting his work from 4.9.95 to 2.x isn't trivial either. I should've asked, comment how ?
mircea_popescu: dorion, of course it's trivial, he doesn't use any of the pestilent doohickeys. he could port it to most 1series also.
mircea_popescu: this is in no small part due to how alf thinks, he's remarkably exceptional at this side of things.
dorion: mircea_popescu I see, nice. today I learned.
bvt: mircea_popescu: moving to 2.6 kernel will be interesting experience wrt. newer hardware. 2.6.32 was one of the better-patched ones, could try to use that. otoh, the machine i am writing from requires 2.6.38 minimum for full hardware.
bvt: *full hardware support
bvt: porting rng to 2.6 kernel should indeed be not too hard, the only thing i may need adaptation is kfifo api (iirc it's api changed at some point, which may break the code)
dorion: bvt wrt to newer hardware, did you see get a dozen or two alternatives, let the rest wither ?
BingoBoingo: mircea_popescu: I am inclined to attribute this in part to your use of technology to dive into what seems to be historically uncharted territory as far as extreme literacy goes.
bvt: dorion: in this case, picking 2.6 will not be a problem, of course
mircea_popescu: bvt, i dunno man, commodity servers to this day come on 2.6, random sample turned out 100%
mircea_popescu: unless by newer hardware you mean who knows what random home luser dongle.
mircea_popescu: but the cost to replace that is minimal, i mean... oh, so your video card doesn't work no mo ? awww, splurge on 50 bux, which as per latest j-lo self-promotion 1hr long advertisement incomprehensibly packaged as "a movie" ain't even enough to START the moneycount.
mircea_popescu: skip trying to buy a coupla shots for whatever rando hobag at the club next time, get yourself a working peripheral [see all the hobags in history naked-er and working it more excitedly anyways].
mircea_popescu: it's not clear to me how i'd actually go about computing the value-add of supporting whatever config isn't self-supporting ; but it seems indisputable it's under the cost of five second's labour. making the matter not even work considering, let alone discussing.
dorion: trinque html stripped from comment again, here's original : http://paste.deedbot.org/?id=3p4J
mircea_popescu: http://logs.ossasepia.com/log/trilema/2020-01-12#1956798 << just the simple string "lts" makes my skin crawl
ossabot: Logged on 2020-01-12 14:02:44 mircea_popescu: https://upload.wikimedia.org/wikipedia/en/timeline/a390b4b428edb39f3d7f6fcd66aa2d05.png << this timeline might help your visual style i guess.

On January 17th, Diana Coman reported a successful build of Gales Linux, which she has unearthed a Lenovo x200 for installation.

Upon trinque noting rEFInd being a relatively slim but robust bootloader apparently developed by one man, I said hi to Rod Smith in email, received a positive reply from him and subsequently invited him to join #trilema on January 18th.

On January 18th, jfw began the process of answering my earlier question about the ability to have multiple C libraries installed and used on a system as a way to approach supporting libGL for Eulora. I say began the process because as the answer indicates, there may be something there, but needs serious research by the man who steps up to own compiler and C library.

I'll note here that I never did follow through on the Cuntoo install I said I'd do back in December.

dorion_road: I'm budgeting time this month to carry out spyked's method using qemu and lobbes is deepening his understanding of the ebuild system.

This is one that fell through the cracks and though I'm not against doing it, I'm not exactly clear to me at this point what would be learned and what the gain would be relative to the time investment to pursue it. In other words, I'm not sure if this task ought to stay on the road map or is an unnecessary straitjacket.

Much of my January activity has consisted of catching up with comments on the various articles published late December. Being back on the ground in Panama also caused me to be a bit overweight in time allocation to JWRD business development. Diana Coman's guidance is helping me establish more balance between TMSR OS, JWRD and a more diversified selection of writing on this here blog since they're all long term and really tied together.

So what's on the agenda for the month ahead ?

1. Moi :

  1. Recurse and give a second go on why it's +ev to contribute to TMSR OS.
  2. Get feedback on the mission and vision statement.
  3. Draft a page for Dorion Mode of a list of all the dependencies the genesis of the system requires.
  4. Get cracking on my code shelf.
  5. Start strategizing on growing contributors

2. bvt :

  1. He expects to deliver awk + posix shell + Ada Vtron by the end of next week
  2. then he'll be on to porting his kernel work to Linux 2.6.32. TODO : have him establish expected delivery date.
  3. What are other priorities for the kernel ?
  4. While I don't want to overload bvt, I recall reading, but sadly don't have the link, that he did the kernel work because important, not because it was most interesting to him. At what point is kernel "good enough" short term and can he be freed up to tackle something else of higher priority ? I'm asking the question, not saying one way or the other ought to be pursued.

3. trinque :

  1. 1-2 more articles in his Republican OS series. He's established a foundation to discuss how V integrates it all and then will summarize and publish a specification6.
  2. No time frame right now about casting his discerning eye over Gales, but keep up the momentum on the path you're on trinque and we'll decide later if/when tearing Gales to shreds is +ev.

4. spyked :

  1. He got his botworks patches out this weekend.
  2. Report on the Gales Linux build and install process was scheduled for January and may still be achievable depending on the demands from his saltmine, but may leak into February.
  3. Acquiring corebootable boards in general and covering suppliers of the APU1 in particular.

5. jfw

  1. Online part of the Gales Bitcoin Wallet is drafted and the code annotation is complete.
  2. Offline work continues in February, optimistically will be done next month, but may leak in March.
  3. Once that's genesis'd and off his plate, decide what he wants to own. I haven't really rushed him here because the wallet is a big win and we've discussed offline it probably ought to include a genesis of Gales Scheme, which will be a big Fixpoint series in and of itself.
  4. Also, while Jacob's been on gbw work, I've been holding my breath on ave1 re-emerging to claim gcc + C lib. I reckon Jacob'd be a good fit here, but if we have a reliable and Lordly ave1, Jacob can own something else.

6. lobbes

  1. He's partially through the gales build and install, was expecting to deliver report by Jan 31st, but MP-logger is dragging a bit, so may leak into next month.
  2. Once his plate has been relatively cleared, need to have a conversation with him about what he thinks is a good fit for him, or at least which ways he's interested in growing his skills, which as I said in the bit quoted from December doesn't have to be purely technical.

7. ave1

  1. Feedback modes are a sign of life, let's see the extent to which he can shorten the loop. First things first is conversations, I don't want to pressure him into a situation to trigger his being an engineer until he's ready.

I'm not hiding or shying away from my junior management status, so if there's anything I've missed, am confused on or am overlooking, please set my head straight in the comments !

P.S. February's my birthday month, I'm not asking for presents apart from those listed above, so don't go have me chasing them ;)

  1. Which uses busybox and aims to avoid the unnecessary complexity Gentoo has fallen into the the sad state of importing []
  2. Some of which were determined to be ill-informed and have been struck. []
  3. Now shapeshifted to TMSR OS. []
  4. See comments there for the details. []
  5. Of interest here given Cuntoo/Portage uses python []
  6. I didn't get an estimated timeline out of him yet, but am assuming for now at least one of those will be out in Feb []

December 19, 2019

Some Reasons Contributing to TMSR OS is +ev

Filed under: TMSR OS — Robinson Dorion @ 04:00

NOTE: It's been noted by a couple authorities this article is rather incomprehensible. With that being said, take heart that the comments provide some relief and a good example of the quality of feedback Diana Coman is prepared to provide should she accept you as a Young Hand of hers.

If you find yourself weighing whether or not it's in your interest to contribute to TMSR OS, consider some points :

Your interest is derived from who you are, i.e. your identity, signature, name, word and actions.

A strong individual identity is unique and expensive to replicate which generates signatures that are expensive to forge. Strong signatures are essential for sound contracts which are a central pillar of commerce. TMSR employs 1 RSA for identifying individuals in the WoT because it's the strongest known identity scheme from a practical 2 standpoint.

Having more effective tools available to employ for commerce increases your leverage and raises the probability for resourceful commerce.

The stronger your identity tools, the more incentive you have to use them to own and sign your work and the more incentive others have to provide you feedback to acknowledge the quality of your work and help you improve. The elite thinkers and capital allocators have the intellectual bearing to do in this world ; if you're one, you might as well own the bearing you do with a strong signature and a proper publishing platform.

By effectively contributing 3 to TMSR OS, you not only strengthen yourself as noted above, you also help strengthen the system's implicit clients 4.

On the money side of the ledger, you're well advised to factor in Gresham's Law into your expected value function and ask yourself if TMSR OS makes Bitcoin more or less peer to peer, more or less adamant :

mircea_popescu you familiar with gresham's law ?
herbijudlestoids yes
herbijudlestoids quite :)
mircea_popescu ok so. it doesn';t matter what people do or don't do. merely the preference to save strong currencies and to spend weak ones ensures the price differential. compared to anything else man made, bitcoin is adamantine.
herbijudlestoids i swear i mentioned something about global reserve asset earlier. preference to save is enforced by the marginal global saver
mircea_popescu so i mentioned something in 2011, what of it >D
herbijudlestoids what they save in is the store of value. you cant just call a currency the strong one for no reason. the use of a particular asset as a store of value by the marginal global saver(s) is what gives it that characteristic i.e. what are those entities converting their productive surplus into
mircea_popescu but i have an excellent statistical reasonv : that 10mn earliervi. no business in the history of business did anything like this. only currencies can, and only currencies do. basically in the 2010-2014 the entire world had a zimbabwe moment and didn't even know it (much like the actual peasants of zimbabwe, what do they know of finance).
jurov oh, they did notice ever fattening stacks of bills
mircea_popescu i guess. and obama is increasing the minimum wage, and more qe, and more bailouts, and so on and so forth.
herbijudlestoids im not really sure what any of the above has to do with greshams law lol
mircea_popescu it's a better model than the "marginal saver", in that it relies less on statistical artificery.vii other than the statistical reason (ie, bitcoin is the strong currency because of its history) there are actually legions of other reasons. bitcoin is fungible, unlike any other fiat (in that no court can order the de-fungibilisation of bitcoin). in any dispute of currency the more fungible wins, period.

Everyone knows weakness is strength in fiat land ; do you think the ~33% cut to the Federal Funds Rate in 2019 is a signal of more to come ? What'll that do you your purchasing power ? Why save with the weak, when you can hold the strong ?

Fine, fine, let's engage the point a little. Just the tip, okay ?

Here's one example. Do you understand what that means ? Do you see how the fact that you can make rounds of any size and call them coins therefore makes for a weaker currency than Bitcoin ?

Strength in the sense of stronger, fuller specification ; strength in the sense of stronger, fuller bindings on the future -- that's what strength is ; not the piddly nonsense you expect it to be, on the basis of all your experience clawing barefoot through the mood of your sad, limited past history. There can always be more of anything in nature -- but there will never be another number four. That is what real strength is.

And that's what we're aiming for here with this OS, a full specification because Bitcoin is an OS and Bitcoin is Sovereign.

There are more points and more details that could be expanded upon, but if "you" are operating on causes of this world of higher importance to you when compute expected value of an investment of your time than personal responsibility, strong individual identity, efficient and effective contracts and sound money 5, feel free to explain in the comments how those interests provide you leverage and ask how contributing to TMSR OS may further those causes.

  1. Understanding the practical strength of RSA for identity keys and signature has been a long term strategic project of TMSR, since before I was born. []
  2. Euclid's GCD is the latest hightech in factoring large prime numbers. []
  3. Contribution isn't limited to vpatches to software, there's a lot to be done and TMSR OS is a piece of something much greater. So follow the links I lay and the links in the links and if you don't know, you can ask me and someone in your WoT to help clarify. []
  4. E.g. more of the right people reading the Bitcoin code and staking their name on signing it and deploying TRB on TMSR OS means over time a smaller, clearer and more comprehensible codebase and a more robust Bitcoin. []
  5. Time and how you spend it falls in there as well and is there a better way to make use of your time than to interact with people carrying meaning ? []

December 16, 2019

TMSR OS Mission and Vision Statements Genesis

Filed under: TMSR OS — Robinson Dorion @ 22:12

The TMSR OS mission and vision statements genesis seeds the tree of consideration and expression on this branch of thought.

Mission:

The mission of TMSR OS is to be a profitable implement for its implicit clients and operators to leverage in furthering capitalist economic interests and disrupting socialism.

Vision:

By enumerating goodness 1 and owning any software worth the mention under V, TMSR OS allows the operator to manage his investment of trust and sets the basis of a framework for full process insurance of the complete computing stack, from hardware schematics to BIOS to bootloader to kernel to compiler to key management and graphics software -- ab ovo usque ad mala.

The success of TMSR OS is measured primarily by the success and growth of its clients. Bitcoin is the sound money, unpatchable 0day to the socialist monetary system, Gossipd is the uninterdictable, undecryptable communications layer of the forum, MP-WP is the preeminent publishing platform, Eulora is, "the masterclass in economy masquerading as a video game" and with TMSR-PGP the operator manages his identity keys, i.e. generates keys, encrypts and decrypts, creates and verifies signatures.

Sharpening the capitalist computing tools necessarily means making the use of fake central bank 2 money trademarks and the fast food technology sillycon valley has been serving to support their inflation fueled real estate and ipo bezzle investments for the -ev misallocations they are. Everyone who has thought for a few moments about it knows the political and technological collectivism is unsustainable and TMSR OS accelerates the slaying of the socialist beast and assertion of the individualist, honor-based hierarchy to which the elite are productively defecting.

May this guide the cultivation and bearing of nutritious fruit and to the victor go the spoils.

To be continued in the comments and pingbacks...

  1. As M. J. Ranum puts it :

    Why is "Enumerating Badness" a dumb idea? It's a dumb idea because sometime around 1992 the amount of Badness in the Internet began to vastly outweigh the amount of Goodness. For every harmless, legitimate, application, there are dozens or hundreds of pieces of malware, worm tests, exploits, or viral code. Examine a typical antivirus package and you'll see it knows about 75,000+ viruses that might infect your machine. Compare that to the legitimate 30 or so apps that I've installed on my machine, and you can see it's rather dumb to try to track 75,000 pieces of Badness when even a simpleton could track 30 pieces of Goodness. In fact, if I were to simply track the 30 pieces of Goodness on my machine, and allow nothing else to run, I would have simultaneously solved the following problems:

    • Spyware
    • Viruses
    • Remote Control Trojans
    • Exploits that involve executing pre-installed code that you don't use regularly

    Thanks to all the marketing hype around disclosing and announcing vulnerabilities, there are (according to some industry analysts) between 200 and 700 new pieces of Badness hitting the Internet every month. Not only is "Enumerating Badness" a dumb idea, it's gotten dumber during the few minutes of your time you've bequeathed me by reading this article.

    Now, your typical IT executive, when I discuss this concept with him or her, will stand up and say something like, "That sounds great, but our enterprise network is really complicated. Knowing about all the different apps that we rely on would be impossible! What you're saying sounds reasonable until you think about it and realize how absurd it is!" To which I respond, "How can you call yourself a 'Chief Technology Officer' if you have no idea what your technology is doing?" A CTO isn't going to know detail about every application on the network, but if you haven't got a vague idea what's going on it's impossible to do capacity planning, disaster planning, security planning, or virtually any of the things in a CTO's charter.

    Editorial Note :

    I went through the pain of making the quote a footnote because a) Ranum's blog doesn't have the MP-WP select tool to render http://www.ranum.com/security/computer_security/editorials/dumb/?b=Why%20is&e=CTO%27s%20charter.#select correctly and the archive.is js select is unreliable across browsers, b) underscore how handy the tool is and c) I've learned a lot reading Ranum, you probably will too. []

  2. What percentage of Federal Reserve Notes do you reckon are digits on some server in a ~closet in Northern Jersey (no, not the Bailiwick of Jersey in the channel north of Normandy, the failed European colony south of the mouth of the Hudson River), hmm ? []

December 14, 2019

Contribution Guidelines for TMSR OS

Filed under: TMSR OS — Robinson Dorion @ 06:32

The implicit clients of TMSR OS are the implementation tools of economy, i.e. medium of exchange 1, punishment gazette 2 and public forum 3, along with "the masterclass in economy masquerading as a video game".

Being a collection of software, the entire system is controlled by V 4 , which has a manual genesis of it's own, to quote :

0x00] Software is the property of people running it, and part of the systems running it.
0x01] Identity is constructed, upon a fixed supportv, by others' view.

These absolutely true, universally valid and fundamentally correct principles mean in part that there is an expected value of every line of code that is deployed. Every line of code carries both risk and reward. A job of the operator is to evaluate his risk and reward exposure and the tools of contribution provide him leverage in that process.

All code in the system is a signed vpatch published by the authors on their blogs in articles which explain the modification. All vpatches and signatures are distributed on the code shelf of the author and the code shelves of any other signers of the vpatch who leave their seals. While there is no central code repository or central version control system or even a wesbite, the decentralized publishing and distribution system provides the operator of TMSR OS a basis to answer his guiding questions, "What is the cost/benefit of each vpatch ?" "What is the meaning, source and context of the text ?" This is the paradigm shift at the root of the redesign of computing, consider :

Used together with specialised scripts, V-genesis allows an agent to reconstruct a complete Bitcoin tree, verify its correctness, and manage his investment of trust at all junctures so that he is never required to implicitly trust either an unknown code author, or a code snippet of unknown provenance.

Exciting times, wouldn't you say ? As the old Young Hands m.o. goes, "Work on what matters, so you matter too." So then, what are the guidelines for setting yourself up to contribute to this process ?

  1. Install an IRC client and register a nick with #freenode 5 ; Jacob Welsh (WoT: jfw) genesis'd his IRC client, yrc.
  2. Register your RSA key 6 with deedbot, see deedbot's help page for help.
  3. Install a V, Diana Coman's (WoT: diana_coman) starter pack is a good starting point.
  4. Maintain a blog 7 where you :
    1. Maintain a code shelf ,
    2. Publish your work plans and reviews 8,
    3. Publish articles for context 9 on your vpatches,
  5. Maintain an IRC connection to converse with people 10 for context to sort out who's who and what's what.

Take your time to learn, but come out of the shadows sooner rather than later, you don't really stand to gain from manaloning. Go ahead and start by asking questions here in the comments.

Sed fugit interea fugit irreparabile tempus, singula dum captos circumvectamur amore.

  1. Bitcoin []
  2. Web of Trust (WoT). []
  3. The logs and blogs. []
  4. Linking to Diana Coman's latest as it provides context and preserves the predecessors, which she links to. []
  5. #freenode is not ideal, in fact, it's a known issue. Nevertheless, it's where the Republic meets at present. I link the article pointing out the problem in case you, dear reader, reckon you have what it takes to solve it. []
  6. GnuPG 1.4.10 is recomended for now. []
  7. At minimum the blog software should support comments, pingbacks, server side select a la MP-WP, and no SSL or javascript or captchas of anykind if. Really, you should probably just install mp-wp. It'll give you more practice with V and if Mircea Popescu (WoT: mircea_popescu), says it, "provides those last edges of extra productivity and intellectual leverage that convert exceptional performance into mindblowing performance" for him, what's it going to do for you ? billymg (WoT: billymg) has a vtree and guide and Hannah Wiggins (WoT: hanbot), Aaron Rogier (WoT: BingoBoingo) and Eric Benevides (WoT: lobbes) have guides published. []
  8. You probably already know prospective reporting is core to working with people. The minimum standard is aligning with the ancient MPex standard of one month, but some people publish more frequently. The bottom line is, tell people what you want to do, what you think is important and do it well. If your words don't match your actions, write about what you're doing to fix it. A few example plans are Lucian Mogosanu (WoT: spyked) for December 2019 and Eric Benevides for December 2019, bvt (WoT: bvt) for July 2019 and Young Hands. []
  9. Articles publishing a vpatch, should have context about the vpatch, your blog should also have articles to provide context about you. []
  10. The forum is vast and deep, a few years ago the recommendation was to read the logs for '6 months'. Meanwhile the forum moved to #trilema and licensed castles while the log is available via trilema, ossasepia and ericbenevides. []

December 11, 2019

Heading TMSR OS

Filed under: TMSR OS — Robinson Dorion @ 06:15

With TMSR OS being the deliberate innovation and redesign of computing and me taking the call to head the project, it then follows I ought write out as soon as possible what I understand my responsibilities for ownership to be.

This is written as a starting point. As the work unfolds, I expect more responsibilities will become evident. The comments are open and welcome for feedback and corrections to accelerate my process of perceiving and prosecuting my responsbilities.

The first pillar to raise in is that I must be the coherent entry point of the project.

@Mircea Popescu

You're the coherent entry point, that's what you do, own it as such.

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 :

La Serenissima does not recognise nor will ever enforce any sort of claim of any entity that purports to impinge on the sovereignty of persons. No entity may claim rights to person's identity under this rule, and if they try to they're being the enemy and should be treated like the enemy. For all intents and purposes identity is allodial property of the person therein represented, and no convention may touch it.

And layering on the factor of the leverage of invested individuals the advantages amplify.

If project C has a decision making system formed out of 18 elements, which each obviously will require a separate pitch, as well as 39 groups formed out of the 18 elements in varying compositions, while project D has a decision making system formed out of one single person, we can say that D offers leverage and couldn't be bothered to mention C again.

The second pillar is tried and true management.

mircea_popescu: http://logs.ossasepia.com/log/trilema/2019-11-25#1953458 << nothing new or different, same old thing management always was. write a plan, get people to ~commit~ to parts, chase the commitments, reschedule as needed and so on.
ossabot: Logged on 2019-11-25 14:32:04 dorion_road: http://logs.ossasepia.com/log/trilema/2019-11-25#1953428 << my initial bias is to say, yes I want it. Before I take the claim though, I have to better understand what the responsibility of heading the project means.

How then do I interpret these into concrete tasks ?

1. Initial Tasks

  1. Write the plan.
    1. Implementing TMSR OS was an initial outline of the technical work to be done and with it came clarification on priorities and challenges.
    2. TODO Maintain a page on Dorion Mode for each of the 8 sub-components that provides context on the approach and tracks the status of the work done and to do.
    3. TODO articles to write below.
  2. Get people to commit to parts.
    1. bvt is on the kernel and taking December to test and report on Gales. The vpatches to the kernel bvt produced thus far may be sufficient for now. Integration of the kernel into the system is the highest priority in the short term 1.
    2. spyked is mapping the uefi-1/2 cleavage and aiming to test and report on Gales in December.
    3. ave1 is the tentative owner of the compiler and c library. I chased him Monday, December 9th and await his reply for a week or two. jfw has Bitcoin wallet work these next couple weeks, if ave1 hasn't committed by the time jfw's freed up, I plan to offer gcc and c library to jfw.
    4. lobbes is writing an article to explain his understanding of the gentoo ebuild system.
    5. Coreutils, Package management, install and process supervision and logging decisions will be informed by further testing and reporting on Gales and Cuntoo, lobbes' report and the discussion to ensue. Someone will have to take each of those.
    6. The Graphical Interface, is a big consideration for C library and the static/dynamic linking appraoch. jfw has a series of recipes for hand building the X11 stack on musl-dynamic, which could be a good starting point once the decision of how to package the build is approached.
  3. Establish the Initial Timeline for TMSR OS "genesis".
    1. In addition to the design decisions this includes every dependency of the Implicit Clients of TMSR OS to be V-ified.

2. Articles to Write 2

  1. Qualifications and best practices for contributing. Due to be published by Saturday, December 14th.
  2. Mission statement and long term vision.
  3. Reasons why it's +ev to contribute.
  4. Dependencies of the implicit clients of tmsr os.
  5. Re-state distribution. What does it imply for each person to maintain a code shelf ?
  6. Start on code shelf.

3. Regular Tasks

  1. Maintain my work plan and reviews 3

  2. Cultivate conversation in #trilema when it's my turn 4.
  3. Read/Comment on all related articles.
  4. Read/Comment on work plans.
  5. Maintain a unified timeline of deliverables.
  6. Talk to people about contributing technically and in general integrating it into their operations.
    1. Defining the work and understanding what known parties want to commit will determine how much outreach on the technical front will be needed to start.
    2. Integrating TMSR OS into the operations of JWRD will be a primarily mechanism of talking to people about becoming operators.
    3. The new Panamanian administration is making an effort to attract the computer industry, working the meat-WoT to explore opportunities there will be a Q1 2020 priority.
    4. A strategy for growing hands remote/digitally needs due consideration.

4. Long Term

  1. Implement for leveraging in the process of raising the quality 5 and quantity of republicans, giving more reason for the elite to defect 6.
  2. Stabilize development environment for Bitcoin, Eulora, Gossipd, etc.
  3. Leverage to develop a consulting business with lifetime support and/or full process insurance venture 7.
  1. I don't estimate this to be a big job, depending on what bvt wants to do, helping spyked to tackle the uefi problem or helping stabilize the compiler and c library would be good uses of time to my eye and, of course, there's other options. []
  2. I expect this list to grow as I get into the writting, and suggestions are more than welcome. []
  3. Maintain weekly work plans and reviews on Young Hands. Publish monthly TMSR OS plans and reviews on Dorion Mode with January 2020 being the first* monthly plan.

    * I claimed I'd publish a plan for December, but counsel from Diana Coman has caused me to simply keep weekly plans this month and start January with the monthly. []

  4. Hold initial conversations in #trilema because everyone reads every line anyway, and where Mircea Popescu makes himself available to guide correctness. A #tmsr-os channel is looks like a good idea for new comers once the "genesis" has been achieved. []
  5. How much time will be saved once an OS with sound priciples that works is in hand ? []
  6. In my mind this principally includes less time and energy mining salary on imperial salt farms []
  7. As Diana Coman aptly pointed out, it'll all come down to the people :

    There is for sure a lot of potential in there and moreover having the TMSR OS in the first place is simply a prerequisite for being able to do anything like code review&insurance (in 2012 when I first read that article on trilema, my thoughts were precisely - yeah, great idea, except it would take rebuilding the whole environment from ground up because nobody can sanely provide insurance in the swamps). But as everywhere otherwise (and as I'm quite sure you know already), the crucial part is getting in the right people to do this with, on all sides and as it grows.

    []

November 29, 2019

Implementing TMSR OS

Filed under: TMSR OS — Robinson Dorion @ 17:44

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 1, chat 2, publishing 3, "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 :

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 ?

  1. The Linux kernel
    1. Owner: bvt
    2. Status: Linux 4.9.95 was genesis'd and feeding the RNG with FG is implemented.
    3. 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.
  2. The Compiler and C Library
    1. Owner: ave1 (tentative) 4
    2. Status: Work towards a GCC 4.9 genesis underway, unknown how far developed.
    3. Questions:
      1. 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 ?
      2. C, C++ and Ada are the desired initial GCC front-ends.
      3. 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 ?
  3. Coreutils
    1. Owner: unowned at present
    2. Status: Cuntoo bootstraps from Gentoo stage3, Gales Linux bootstraps from Busybox.
    3. 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 ?
  4. Package Management
    1. Owner: unowned 5 at present
    2. Status: Cuntoo uses Gentoo's portage/ebuild based on Python, Gales uses a custom, shell based build script system.
    3. 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.
  5. Graphical Interface
    1. Owner: unowned
    2. Status: needs reporting
    3. 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.
  6. The Install Process
    1. Owner: unowned at present
    2. Status: livecd/usb, initramfs
    3. Questions/Comments: Process for creating and using install media for deployment.
  7. The Boot Process
    1. Owner: unowned at present
    2. Status: BIOS, bootloader, init
    3. Questions/Comments:
      1. 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.
      2. Bootloader: LILO, grub.
      3. init: Gales Linux uses a 57 LoC init in combination with djb's daemontools.
  8. Process Supervision and Logging
    1. Owner: unowned at present
    2. Status: Gales uses djb's daemontools and multilog while Cuntoo imports Gentoo's OpenRC based init system.
    3. 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.

  1. The Real Bitcoin []
  2. ircd as a predecessor to gossipd []
  3. MP-WP, see The Whet and billymg's v-tree []
  4. He shared the news of his genesis efforts in the log, yet to respond to my ping about his status. []
  5. 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. []

Powered by WordPress