IRC channel logs
2026-06-10.log
back to list of logs
<aggi>ok, i've quickly cloned live-bootstrap-bake; i do recall some issue with export VARS by kame, seems bake can export (as usual i could be in error) <aggi>and i don't know yet, regular kaem can and does run atop rickmasters' stage0 kernel/loader - without a linux syscall abi <siraben>aggi: if you find any bugs/portability problems please let me know <aggi>siraben: if i may ask, does bake run atop rickmasters stage0 kernel? or does it need a /chroot atop a linux syscall abi? <siraben>all the dependencies are listed in the readme <aggi>siraben: that's the pico kernel/loader 4KiB in size which can launch kaem <aggi>moment... skimming the repo chaos in my workspace <aggi>this is the real and first entrypoint into live-bootstrap iirc, on x86 <siraben>On this is like, bootstrapping directly from boot? <siraben>impressive, that means with TCCBOOT you could live boot the linux kernel fully bootstrappable as well <aggi>not really, tccboot is _not_ re-integrated with the builder-hex0, which it had to be for a complete bootstrap, but it isn't <aggi>tccboot merely offered a JiT (instead of AoT) kernel compile, but tccboot itself isn't fully bootstrapped <aggi>it could be done though, but it's not been done yet (two years ago i merely re-confirmed tccboot would work still, re-compiled from source) <aggi>and some latest tcc mob/HEAD at that time, instead of tcc-0.9.21 (from year 2004 iirc) <aggi>anyway, something else, bake interpreter seems to divert from POSIX shell syntax, not sure about this tbh. <stikonas>siraben: builder-hex0 can run tcc which can be used to build Fiwix kernel <siraben>aggi: bake is supposed to be like make syntax but simplified <stikonas>2nd part is mini kernel with about 15 syscals that are translated into bios calls <stikonas>and 1st stage is just glorified hex0 that can load 2nd part into memory and jump into it <stikonas>gnu make is not super hard to build though <siraben>Right but this is at the very beginning, kaem has a lot of repetition <stikonas>but maybe bake could be useful for some stuff <siraben>when it could have things like topological sorting of deps already <stikonas>e.g. there is no way to run make in builder-hex0 or UEFI <siraben>I guess I can remove the bake files that already have make equivalents and compile make earlier <aggi>siraben: to clarify, of cause live-bootstrap can and does arrive at a fiwix/linux kernel, but it's not done with what's known as tccboot <aggi>tccboot had been an attempt 20years ago, to shrink the dependency graph for this at least, and not been maintained ever since <aggi>so when myself had a first look at bootstrapping, the first find had been tccboot, until i found bootstrappable.org had taken up the challenge and re-did everything from scratch <aggi>myself had NOT been a contributor to live-bootstrap, it's been many other people who did all this work <aggi>i've hacked the tcc-toolchain support for all later pieces to avoid gcc/binutils completely <aggi>which explains my obsession, since that's too been many years of work to accomplish this <aggi>and that's why i am concerned a little still over the many stunts done with re-compiling tcc/musl more than a dozen times <aggi>so far i could only chop one tcc re-compilation pass, and directly transition from 0.9.26 to HEAD <aggi>and, just as said, gcc/binutils are dropped as optional, python is dropped as optional <aggi>of cause, python can and must be bootstrapped, but it's not necessary to do so anymore to arrive at a bootable kernel <aggi>plus busybox, and a few other things (which is closer to the ideas from aboriginal linux which too predates live-bootstrap but was abandoned meanwhile) <aggi>another thing with aboriginal linux was, this too covered hardware development targetting SH2 <aggi>tinycc hasn't got sh2 support on board, although gcc4 and linux2.4 already had this, too the early qemu-0.14.1 already had it <aggi>hacking sh2 for tinycc is beyond my abilities, and the whole hardware development realm is neither practical (turtle boards aren't shipping) and there's is other options to approach this <aggi>meanwhile, mainline development is heading towards riscv/aarch64, and UEFI, anyway <roconnor>siraben: how much does this claude thing cost you? <siraben>My current account is free because I got their 6-month open source maintainer deal for something that usually costs $200/mo (the 20x Max plan). I pay for ChatGPT Pro ($200) myself to use Codex. So total spend once the deal is over would be $400/mo <siraben>I don't use API pretty much ever, that would be pretty costly <siraben>personally, the amount of utility I get out of these things is pretty ridiculous. A year ago it wasn't very productive to use them, but things have changed a lot in the last 6 months. <siraben>aggi: Hm, so if recompiling tcc has been done many times over the years, what would you like to see that would be much more useful for bootstrapping? Finishing off the UEFI boot? more arch support? <aggi>siraben: you're sure you got that right? "tcc has ben done many times over the years"??? <aggi>i mean, if you like, go ask ChatGPT and pay as much for it however you wish <siraben>aggi: I thought you were implying that people were recompiling tcc with alternate implementations? maybe I misred <stikonas>it's a bit sad though that now you might need to pay these AI companies. Hobby programming used to be completely free as long as you have a PC or laptop... <siraben>Well, you are always paying with something. If not money, then time. <siraben>philosophically I know it's not very compatible with free software <stikonas>but e.g. if you are say school kid learning to porgram <stikonas>you might have sufficient amount of time and no money <stikonas>and reading/writing lots of code used to be a good way to learn programming <siraben>The open weight models are getting better but I think the gap between frontier and open weight keeps widening <siraben>and the frontier models are getting pricier too <stikonas>well, those companies pour billions into training and inference... <stikonas>it's hard for open weight models to keep up <aggi>feeding their data-clusters without consent from authors who are doing real programming, document their work, and discuss it in IRC channels in good faith <aggi>siraben: for the record, i've not consented with any conversation here fed into ChatGPT <siraben>Sure. I've never pasted anything from this channel into LLMs <siraben>however it's probably already scraped via the public log <stikonas>you can't even easily self-host git forge these days <stikonas>so many scrapers immediately start attacking it <siraben>I have an instance with a friend and it's on our tailscale <stikonas>well, I had to put my forgejo behind anubis <aggi>siraben: to answer the last question of yours, and it's not an individual opinion of mine but common understanding <aggi>the situation with tinycc is complicated for several reasons <aggi>hence, if tinycc remains, which i think it will for a little while to come, regularly rebasing for tcc-head should be considered <aggi>that's too where most activity exists for riscv/aarch64 <aggi>of cause, there's too strong arguments to be made to pin down tcc-0.9.26 once and for all <aggi>i would merely want to know where live-bootstrap developers are heading finally <aggi>then next, again if tinycc prevails as is, there's rather many re-compilation passes.sh (i've counted more than a dozen for tcc+musl) <aggi>maybe it is possible to reduce the complexity of this <aggi>or, if mes-cc will replace tinycc entirely, to avoid such a problem in the future <aggi>then, in principle, a bootstrapping can reduce the amount of steps significantly, to arrive at a bootable kernel+libc+development utilities <aggi>furthermore, current status is, live-bootstrap is not engantled into any specific distribution build/packaging system (guix, gentoo) <aggi>this should not change in the future, in fact i see no need to bother with any distribution specifics for guix or any other <aggi>in fact, things like python may not belong into the live-bootstrap main package set <aggi>bootstrapping individual languages such as scheme, lisp, haskell, python can be separated (perl cannot because it's needed for autotools still) <AwesomeAdam54321>Hi, has anyone ever wrote a hex0 implementation for an 8-bit computer architecture? <aggi>then, thinking about it, bootstrapping individual languages can be distinguished from complete system-bootstrap <aggi>hence, i would propose some terminology: for a language-bootstrap (python, haskell, scheme, rust) and a system-bootstrap (that's ASM and C-toolchain plus kernel/libc mainly) <aggi>AwesomeAdam54321: since you mention it, an 8/16bit hex0 is particularly interesting when a system-bootstrap shall too cover hardware development to keep that simple <aggi>and, historically if you will, if a system-bootstrap is spawn from "real-mode" that too needs a few 16bit pieces <aggi>i am not aware of many 8/16bit systems to begin with, except Gigatron TTL, which i don't know how their software inside ROM was developed/bootstrapped <aggi>on the x86 side of things, typical BIOS development remains a mystery how that got bootstrapped, dating back to the early CP/M systems when that got first implemented <aggi>since it was mentioned today too, the TI84 series calculator is a Z80 1970s era design too, and most software development of that era lost <aggi>there's some free/open firmware alternative for it i think, but that does not contain the computer algebra system as far as i can tell <aggi>maybe the bootstrapping pieces are available with it <siraben>wouldn't most of the microcomputers' development take place on more powerful workstations? <siraben>maybe it was never really bootstrapped from the start <aggi>in 1970s (and earlier) powerful graphical workstations didn't exist, to state the obvious <aggi>then next, of cause, at that time systems must have been bootstrapped, but the bootstrapping chain may not have been documented and properlay maintained <aggi>another peculiar historical detail, the developer of CP/M and BIOS was beaten to death for some unknown reason <siraben>Funny that a bootstrappable thing is a rosy view of the world where things are done in order, properly documented, thought out. One step at a time, increasing levels of abstraction. <AwesomeAdam54321>CHIP-8 on its own doesn't have instructions for I/O (except the screen), and the CHIP-8Y extension provided exactly what was necessary <xentrac>siraben: on Friday I talked to Tom Jennings who told me how he used the macro assembler on a DG Nova at work to punch paper tapes for the 6800 he had at home <xentrac>not a workstation, those didn't exist yet, but a minicomputer <xentrac>on the other hand, IIRC, Steve Wozniak wrote Integer BASIC on paper and assembled it by hand <xentrac>Gary Kildall did some of the early CP/M work at Intel where he presumably had minicomputers, but I think his later work was on self-hosted 8080s <xentrac>Gates, Allen, and Davidoff wrote their Altair BASIC interpreter on a PDP-10 at Harvard, and I don't know what they were doing after they left Harvard <xentrac>I don't think it's accurate to say that Kildall was beaten to death <xentrac>> On July 8, 1994, at the age of 52,[11] Kildall sustained a head injury at the Franklin Street Bar & Grill, a biker bar in Monterey, California.[43] The exact circumstances of the injury are unclear. Various sources have claimed he fell from a chair, fell down steps, or was assaulted because he had entered the establishment wearing Harley-Davidson leathers.[23] Harold Evans, in They Made America, <xentrac>states that Kildall "stumbled and hit his head" inside the premises, and "was found on the floor".[7] <malina>in biker bar it's fairly likely they weren't playing "another one bites the dust" by Queen at least <aggi>i've been in error again, meanwhile a free/opensource computer algebra system was published for TI84 <aggi>seems to be a BASIC interpreter bundled with a math library <aggi>and the calculator can evaluate and display mathematical symbols - at least some simple ones such as sqrt() <aggi>no clue which floating point precision such software could handle on a 8/16bit CPU <aggi>an interesting detail seems, it's the less advanced Z80 CPU which survived until today, while the more expensive MC68000 of the Ti92 didn't <matrix_bridge><Jeremiah Orians> Well the z80 and the 6502 have large libraries of publicly available code that are generally high quality <matrix_bridge><Jeremiah Orians> Combined with their relatively low costs; gave them a survival advantage in the embedded market <matrix_bridge><Jeremiah Orians> Only when RISC-V and ARM leveraged FLOSS were they able to start driving the old 8bits out <jn>8051 too, it survived pretty well for a long time in embedded applications like USB peripherals <aggi>i'm only thinking for myself often, if my interests and efforts were invested into where those belonged <aggi>but it's started in grammar school, and then later telekom university, which didn't pay attentation to various important aspects of technology <aggi>after all, what are insanely expensive oscilloscopes, protocoll analyzers, logic analyzers and all this worth it, when it's not fully open and documented for students <aggi>and nowadays, telekom couldn't operate on Z80 with 56K modems even if anyone wished to <aggi>i can't keep up with the pace, i've not finished studying AX.25 nor GSM/2G yet - meanwhile the industry is rushing towards 5G <aggi>and i failed the analog signals and systems lecture almost <aggi>maybe there was a little more mental headroom, if Telekom didn't dump Oracle Database and Java Programming into the 4 years curriculum too <aggi>all of it, in parallel, 20years later they've closed down the last telekom university in germany - that's official since year 2023 <aggi>there the first lecture had been digital circuit design, hardware development of basic and simple digital circuits <aggi>for the computer science course, the other course was analog electronics (nachrichtentechnik, signals and systems) <aggi>anyway, then it became interesting, after digital circuit design the next lecture was Java and relational databases, in the first year of studying (in parallel to maths, physics, electronics) <aggi>why did management chose to combine digital circuit design with Java and Database systems there? <aggi>and then we were jumping back into the physics laboratory, for laser optics, next course EagleCAD PCB design <aggi>then back into the cisco laboratory, to do routing protocol tracing <aggi>however that's distinct to SONET/SDH ITU-T protocol realm, hence they sent us into the next laboratory with a stack of ITU-T protocol standards to trace this <aggi>in between there's been a little time for motorola assembly - what would i need that for at an Oracle RDBMS? <aggi>ok, next one, UMTS mobile protocol tracing (modulation schemes, CDMA i think that was, not that i could recall alot of this 20years later) <aggi>finally, high ranking science council from Berlin and Colgone intervened, and had forbidden Telekom Management and politics to interfere any further with academic activities <aggi>but they _never_ mentioned in their official report why that was <aggi>another management habit simply was to kick out any students which didn't keep up with the pace <aggi>hence they permitted far more students to sign up for studies and management knowing they would kick out 70% anyway, one more gone thats no loss <aggi>all this keeps me up awake all night 20years later still <aggi>the university library of telekom was not freely accessible to the neighbouring public university which too lectured electronics and computer science <aggi>so that's the benefit of this, at least _all_ students got access to the library <aggi>this science council in germany did not intervene for 20years before... weird <aggi>then it was just closed down, the laboratory buildings designated to the regular public university nearby <aggi>but telekom does continue to donate "digital transformation" lectures in the same spirit as they had done before <aggi>and then, when this science council mentioned in their report (almost 20years later since when i quit) <aggi>this Telekom University "did not meet academic criteria/standards" - this sheds a bad light onto ME, instead of politics and management involved <aggi>meanwhile politics and management are drowning in cash still <aggi>after all, nowadays they're pushing for fibre optics to home (FOTH) here, for Magenta TV soccer streaming <aggi>which is a whole other aspect of this, Telekom University was sponsored with $10million/year, while Telekom too sponsors Bavaria Munich soccer club with a recent contract that noted $250million <aggi>maybe it's merely been sales marketing they were intersted in? to showcase they invested a few million into one university <aggi>and that's why it's been no loss to science and education, because it's merely been a gigantic sales marketing outlet <aggi>in the end, global internet backbone is operational just fine <matrix_bridge><Jeremiah Orians> Great point jn, I think you can even find that in a few cheap SD cards <jn>(and i'd expect bunny huang's SD card studies hold the answer) <aggi>another aspect, if Telekom University didn't meet academic standards, and that's been made public, how many other universities were affected by the same problems, globally? <matrix_bridge><Jeremiah Orians> jn: well the decapping photos were quite cool and at the level of functionality now expected (wear leveling, etc) it isn’t surprising that they are using software to do it <aggi>telekom is more like a customer, who merely contracts and buys goods and services, without questions asked if any of this stuff was lets say "bootstrappable", meeting acceptance criteria <aggi>or if any of the ever more growing complexity of technology products was suitable for education at universities <aggi>after all, too *nix and c-compilers were developed for/at Bell Labs, in USA though, not Germany <aggi>but there's not been sufficient attention paid to keeping this bootstrappable, and fully documented, without the necessity of investing a lifetime of work and studies <aggi>backtracking this into 1970s era and earlier, products which couldn't compete on the markets for latest 5G and soccer video streaming <aggi>c-compilers and operating systems, thats a minor piece among many other, given the situation with blobbed WiFi products which plagues free software systems <aggi>so, if i wanted to keep this free/open/documented for my individual joy, it's who knows some slow modem and ax.25 at best <aggi>maybe, in aerospace the industry is less aggressive, i was reading recently Forth was driving some space probes still, x.25 radio remaining a common option <aggi>but who knows for how long, i'm almost certain SpaceX follows other ideas and ideals <aggi>Musk considers such systems bootstrapped, when he could keep running his Bitcoin infrastructure uncompromised (just speculating), as the first Billionaire in history <aggi>it's just overwhelming nowadays, maybe it isn't when you got a niche you found your peace with in technology sector <aggi>but if a university as a whole was "overloaded" and "did not meet academic criteria" anymore, when trying to keep up with the pace <aggi>i won't bother with rust-lang, simply because i can't stomach any more of this <aggi>if anytime i could spare time, maybe i pick up assembly programming again, i've just not decided yet which ISA that should be (6502, z80, riscv, whichever) <aggi>or which syntax variant was the latest greatest next best thing to follow along with <aggi>the moment when any was chosen, it's outdated again next week, such as 68k telekom favored 20 years ago <aggi>that's too been equipped into eurofighter, phased out already <aggi>yesterday's big "news" was, France and Germany didn't reach an agreement over their "Future Combat Air System" (FCAS) <aggi>there's just too many incompatible variants of pieces, not interoperable among different EU members and their militaries <aggi>german military reported (lost the link) they had to equip some of their infantry units with half a dozen different mobile radio systems <aggi>for battlefield communications, regular phone calls, satellite phone, the 1980s NATO low bitrate packet radio, and some latest greatest <aggi>which they found, 10Mbps shared medium didn't suffice, and a google maps type system reported an update interval of 15minutes or more (don't remember) <aggi>finally they've decided to re-establish manufacturing of the 1980s radio system, i think Thales France is the company for this <aggi>NATO had just another protocol stack for this too, besides ITU-T and Internet ones, and many others <aggi>seems telekom management missed to dictate this into the curriculum, dedicating another two days for this, and yet another exam to pass <aggi>and if you fail, it's all your fault, go find another job on labor market, which pays a little better than 600EUros/month for a telekom student <aggi>because, management staff, that should be the least qualified you could find for such jobs, hence its paid lowest as possible <aggi>and i really mean it, i'm glad global internet backbone is operational, reliable, it's been for many decades <aggi>it's only myself didn't take it for granted <aggi>same with electricity, there's been a lecture for this too at telekom university (Energietechnik, energy technics, concerned with interconnecting power plants and electric grid management) <aggi>but that's been for the analog electronics curriculum <aggi>after all, what i had noticed only from the computer science perspective, into electricity grids it's been some messaging/signaling system deployed <aggi>which isn't energy management, but telco and signalling, that connects power plants, railway, airfields <aggi>TelekomHQ decided first to "outsource" and then later abandon this department entirely, meanwhile this stuff was deployed at german railway still <aggi>although german railway alone soaks a dozen billion cash or two each year for the "digital" department alone <aggi>and again, i'm glad railway remained stable and operational, but it's become very expensive <aggi>which could be an indicator something could have went wrong there, but last time i allowed for applying for job placement there my inquiry remained unanswered as always <aggi>lately politics have been in a hurry with endless "special budgets", because "legacy" gear is phased out and scheduled for obsolesense completely <aggi>but the new (let say 5G, SpaceX) era hasn't arrived at full stability for long term operation <aggi>which who knows what will come next, aarch64, riscv, and a giant stack of new protocols and "standards" <xentrac>hmm, so what's the link back from the analog electronics curriculum and the phaseout of "legacy" gear to bootstrapping? <aggi>it's a total chaos, all of it <xentrac>so bring some order to it. how does it link back to bootstrapping? <aggi>bootstrapping is one MAJOR criteria to do things the right way <aggi>and even big tech players don't manage often, even when drowing in billions and trillions of cash <aggi>yet, even when it's done for let's say x86_32, it's "obsolete" the next day <aggi>and the whole system-bootstrap perspective onto compilers and operating systems is only one piece in the puzzle <matrix_bridge><Jeremiah Orians> In odd news, the super old FAT8 disk format oddly enough supports 256 files and in theory is capable of handling all of the files and the steps leading up to TCC <matrix_bridge><Jeremiah Orians> Although the 256byte sector size and the 20 sector overhead needed is quite dense (literally 1 sector for the FAT table, 1 sector for the boot metadata and 18 sectors to hold the 256 file names) <matrix_bridge><Jeremiah Orians> Giving it a leg up over the 144 file limit of CBM DOS <matrix_bridge><Jeremiah Orians> And if one does 4KB cluster size, it still would support 1MB of data <aggi>my mind is wondering off again, typical measurement gear used, scopes, logic analyzers <aggi>the low-speed (few MHz) 8/16bit didn't need a scope to catch a 5GHz signal on a 128bit data bus <aggi>as soon as anyone moves in with electronics clocked beyond 10MHz; and it could become a challenge in the future, because the analog measurement gear manufacturing vanished <xentrac>but if compatibility with Microsoft BASIC and efficient use of single-density disks aren't actual criteria (N.B. aggi: "criteria" is plural; the singular is "criterion"), you might as well use a less efficient filesystem that can handle more steps <aggi>in the end, that's all obsolete, and not asked for on the markets <xentrac>it maybe doesn't have to be more complex than FAT8, could even be less so. FAT8 supports fragmented files, which is "just" an optimization <matrix_bridge><Jeremiah Orians> xentrac: unfortunately the 64KB max file size makes it a non-starter if one wanted to remain compatible <aggi>being pushed around by HR, next day it's JavaEE in high demand again, so go study this too, another Oracle certification ahead <xentrac>the UCSD P-system only supported contiguous files, so sometimes you had to defrag the disk to create a large file <xentrac>but there was a utility program for it <aggi>the last time i played with does, with dissecting MBR in detail, too at telekom <aggi>just as said, that's too obsolete nowadays <matrix_bridge><Jeremiah Orians> Well the fat table is a nicer idea than storing the next sector in the last 2 bytes of the data sector <xentrac>so presumably the directory structure only needed a start sector and a length for each file, rather than the more complex structures required by FAT and CP/M <matrix_bridge><Jeremiah Orians> Well FAT8 only had an 8.3 name, a single 1 byte cluster number and 2 bytes for the file’s size <xentrac>yes, it is a nicer idea, but the only benefit of making your files linked lists like that (whether you store the next-sector link in a FAT or in the data sector) is to allow you to use fragmented free space without defragging it first <xentrac>well, or to interleave writes to multiple output files whose sizes aren't predeclared <matrix_bridge><Jeremiah Orians> With clusters 0xFF being end of chain, 0x00 being free cluster and 0x01 being reserved (bad sectors sort of thing) <xentrac>this is functionality that can be omitted if you're trying to make a filesystem as simple as possible at the cost of some efficiency <matrix_bridge><Jeremiah Orians> And there is a 1:1 mapping from the cluster ID to the sectors under it <matrix_bridge><Jeremiah Orians> Thus 0x02 through 0xFE just pointed to the next cluster used by the file. <matrix_bridge><Jeremiah Orians> Set the cluster size to 2 sectors and you end up with the 138KB FAT8 disks of old or to 16 and the max file size becomes the problem <aggi>almost missed that ... nd i'd expect bunny huang's SD card studies hold the answer <matrix_bridge><Jeremiah Orians> Or funnier still FAT8 encoded the number of sectors per cluster in a 2^N fashion. So in theory one could have 2^255 sectors per cluster and it thus effectively has a greater max file system size than NTFS and FAT32 <matrix_bridge><Andrius Štikonas> Even builder-hex0 "filesystem" is sufficient for bootstraoping... <matrix_bridge><Andrius Štikonas> And that is just a liked list of lenghths and file datas <matrix_bridge><Jeremiah Orians> I do enjoy builder-hex0’s solution to folders. <matrix_bridge><Jeremiah Orians> Literally just make them part of the name itself <siraben>aggi: ah, looks like PineappleCAS is for the CE only <aggi>yep, and it seems to target the proprietary firmware/BASIC <aggi>anyway, i've gotten a bit lost, my university got wrecked by politics <xentrac>oriansj: all of this is unnecessary complexity I think <aggi>another one i applied at in thuringia didn't consent with their council over anything in 6 month <aggi>so, i'm doing mental psychosis hopping mainly <xentrac>aggi: condolences! that sounds horrible <xentrac>oriansj: making the folder name part of the file name in a single centralized directory is also how it works in ZIP and in Oberon's filesysetm <xentrac>if you want a very simple filesystem that's compatible with existing software and without all of the complexity introduced by fragmentation and interleaving, ZIP is a plausible option. <aggi>for the later linux2-bootstrap realm i've picked rootfstype=squashfs and rebased a kernal patch for this, but that's a whole different realm than stage0 <aggi>a long-term stable filesystem is a burden, ext2 (available with fiwix) will be hit by y38k - not urgent but annoying <aggi>and in the linux2 era it's JFS2 available only which keeps timestamps unsigned to prolong until year 2106 - i can live with it for this use case <matrix_bridge><Jeremiah Orians> xentrac: yeah, I am noticing that a bunch of older file systems required contiguous storage for data and didn’t store file sizes in bytes but in sectors or blocks <xentrac>yeah, CP/M files were sized in 128-byte "records" <xentrac>aggi: what's the squashfs structure like? <xentrac>CP/M didn't require contiguous storage for data though <aggi>xentrac: i didn't study it in detail, there's differen versions of it too, merely ensured full support for it exists, including userland tools backported onto linux-tcc <aggi>i think mksquashfs was one of the very few pieces, which actually needed NPTL, there's been some problem but it's solved now <aggi>hence in tiny-bootstrap a make_bootable linux-tcc can load an initrd from squashfs burned onto cdrw, with some weird size limit of <500MiB inside RAM <aggi>just as said, that's solved, but i've not fully ported mkisofs/cdrecord into configurator/steps yet <aggi>idea being, a stage0 bootstrap will finalize with a readily burned cd-rw <aggi>i'll have to hack kexec-linux for this too, almost forgot, i think fiwix may not have the required kernel api for cdrecord <aggi>squashfs may even exceed 500MiB, but then it can't be loaded into RAM <aggi>i think 500MiB compressed rootfs storage should suffice for a complete development host <aggi>lame technical details, i've just been stuck in a loop for three month for other reasons <aggi>and there's zero mental traction remaining, to encounter any more HR and political management bs <aggi>in politics they're sharing the loot again, over a 500billion budget, but i've not reached any consent with any HR nor startup funding for anything meanwhile <aggi>just as said, i'm not referring to stage0 filesystem, but instead to the final bootstrapping target on x86 <aggi>and i'll keep any further work on this on hold until some political aspect was settled <xentrac>I think Turbo Pascal 3.01 for CP/M should suffice for a complete development host, although it would be a lot easier if it were based on a sane architecture like ARM or RISC-V instead of the 8080