Dorion Mode - A blog by Robinson Dorion.

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 Linux⁽ⁱ⁾ 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 objectives⁽ⁱⁱ⁾ 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 ⁽ⁱⁱⁱ⁾ 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 ^(iv) 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 ^(v) :

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 specification^(vi).
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 [^]