IRC channel logs

<matrix_bridge><cosinusoidally> stikonas: yep, but I already trust sed and xxd on my host system. My own rule of thumb for this is that I want to be able to create the seeds inside a minimal Linux chroot (eg a debian minbase) using lowest common denominator Linux utilities. I actually don't normally use xxd since that is not available in a minbase I actually use a mix of sed/tr/fold/printf...

<matrix_bridge>... https://github.com/cosinusoidally/tcc_bootstrap_alt/blob/master/mk_seeds

<matrix_bridge><cosinusoidally> I also rule out things like python/perl as they may not be available on every minimal linux system.

<matrix_bridge><cosinusoidally> I had to try sed/xxd on slackware 8.1 as that standard mk_seeds script didn't work there.

<matrix_bridge><cosinusoidally> It's also easier for someone to convince themselves a shell script is correct rather than having to reverse engineer a 256B binary.

<stikonas>well, xxd is also not available everywhere...

<stikonas>it's part of vim

<stikonas>sed is probably simpler

<stikonas>but anyway, up to you how you generate bootstrap binaries

<oriansj>exactly, everyone is free to make their own bootstrap seeds in a manner they trust; that is why the hex0 language is so minimal.

<oriansj>something anyone would be able to create in an hour (even with toggle switches)

<oriansj>or via BootOS or builder-hex0 or ${pick any language or method you trust}

<aggi>finally... tccboot and kernel JIT-compile works; a recent i386-tcc used to compile/link linux-2.4 AoT works too, no crashes

<aggi>BUILDHOST is leaking into BUILDTARGET with i386-tcc cross-compiler, even with all precautions taken

<aggi>moved from aarch32 to x86/slackware11 buildhost... problem solved

<aggi>besides, tccboot compilation responded sensitive to -O2 with gcc6, while it didn't with gcc3

<aggi>and what's strange too, i cross-compiled an entire userspace with the mentioned i386-tcc, and this didn't cause any problems (while ago)

<aggi>what's concerning me: i can't find what's broken, and i fear the leakage is still there even when it doesn't cause undesireable side-effects

<pabs3> https://lawngno.me/blog/2024/06/10/divine-provenance.html

<pabs3>"Testing the provenance of the most popular crates against their upstream repositories"

<matrix_bridge><Andrius Štikonas> The methodology wouldn't catch trusting trust bugs though...

<matrix_bridge><Andrius Štikonas> We had one such bug during risc-v bootstrap bringup...

<matrix_bridge><Andrius Štikonas> Where tcc binary that we originally built had a bug that was propagating even to tcc versions that had that bug fixed

<aggi>funny how, my wording made it into public... "supply chain attack", that's the terminology i had introduced

<aggi>"reproducible builds" was another one, when i worked for Volkswagen

<Foxboron>aggi: Both of these things has history detaing back to the 90s, so I doubt that statement

<Foxboron>dating*

<aggi>of cause, the technicalities are obvious, yet the terminology wasn't

<Foxboron>I'm talking about the terminology

<Foxboron>the DoD described the supply chain of software delivery in the context of security at the start of the 2000s

<Foxboron>and "Reproducible Builds" in the context of build artifacts from the late 90s

<aggi>i do remember exactly when among NetBSD a project ignited, shortly after i left system integration in automotive business

<oriansj>I am just glad the ideas are starting to catch on

<Foxboron>I'm just pointing out that these concepts are in some way "old" and multiple people have realized these things over atleast 20 years. Independently and/or inspired.

<oriansj>if only people stopped downloading binaries and just built from source; so that the true mess of a situation we have could become obvious to everyone.

<aggi>recenelty some job placement inquiries of mine were rejected, _again_

<aggi>two days ago, german railway announced, they had to postpone operation of a new railway station, again, because their "digital data hub" wasn't ready

<aggi>although railway and telekom (that's how it is related), cover an even broader set of requirements, dating back to 1970s

<aggi>with X.25 involved, which was questions i had asked while ago, and was denied job placment there too

<aggi>Telekom completely abandoned support for it, while railway still relies upon this protocol, for critical signaling

<aggi>yet, the network-infrastructure was virtualized, that's how i would describe it, meaning critical signaling is carried by tcp/ip networking nowadays, instead of circuit-switched networking

<aggi>all of the sudden, they announced another surplus of 11billion Euros cash of subsidies required, for their "digital data hub", which should have been operational already

<oriansj>aggi: that is pretty normal for some reason these days. Heck nothing cost me more promotions than saving state of Michigan tax payers $200+M through solid engineering work.

<aggi>german government will dump another dozen billion cash of subsidies into Intel, another 5 billion for microsoft

<oriansj>probably, most government budgets have huge cash grants to corporate sponsors.

<aggi>few weeks ago, after i proposed some project work to employers, and being denied again, employment agency argued that's "hobby"

<aggi>to pay apartment rent, i had to work in grocery store disposing paper wate and baking bread there

<aggi>that's why, i had to close project maps, as i told more than a year ago

<aggi>i was trained for _technical_ management at Telekom University (last remaining one in germany, that finally closed december 2023)

<aggi>meaning, i am not particularly good at x86 real-mode assembly, because there's many other critical expertise to reason about

<aggi>linux caught my interest rather late, in 2004, 20 years later seeing what happened to "free software", not to mention the hardware we got for this

<aggi>because then, you would arrive at some 1970s era stuff, which couldn't do any of the typical bootstrapping known

<aggi>nor any hardware development, without Altera licensed on some windows host... which would never pass any acceptance criteria for system integration

<aggi>the WiFi/Telekom stuff, that's all blobbed, and ITU-T standards written and published with Microsoft Word

<aggi>thanks lord i left this business 20 years ago already

<aggi>and i do see how that's related to critical networking infrastructure for X.25 railway

<aggi>there's no manufacturers for this remaining, i was reading

<aggi>Airbus/EADS chose SPARC 20 years ago, not that it matters, there's no relevant toolchain support for bootstrapping any system in compliance with acceptance criteria

<oriansj>aggi: well we could certainly do a SPARC port for stage0

<oriansj>that'll be fun

<aggi>oriansj: they already announced to jump onto RISC-V

<oriansj>aggi: legacy work for legacy systems is often still well funded

<oriansj>but yeah the RISC-V work should be well on its way to being properly bootstrapped (on a POSIX kernel) but a RISC-V port of builder-hex0 or stage0-uefi might be needed

<aggi>i would recommed trying to avoid gnu-toolchain and llvm

<oriansj>aggi: well stage0 and the full mescc-tools set do; and with unxz, unbz2, ungz, untar and sha256sum; one can do some rather extensive package work.

<oriansj>and tcc work for risc-v appears be making good progress.

<aggi>granted, nonetheless a kernel was required too, and tcc was blocked against kernel since version 2.5/2.6 already

<aggi>didn't try any BSD (nor QNX of cause) with it

<aggi>really depends, and there's completely different ones, such as ThreadX operating system, which is controlled by microsoft too

<oriansj>well Fiwix can be built with TCC and is good enough for all kernel needs for bootstrapping (thus far explored)

<aggi>some other decent kernels i would consider (fiwix, minix, hurd), miss USB/ethernet/dsp often

<oriansj>well, find the one that is the closest approximation to your desired end state and improve it in the direction it needs to improve for your use case.

<aggi>currently, i am merely thinking of a developer-workstation i would be willing to work with myself

<oriansj>aggi: that is a hard problem; mostly due to the ability for your expectations to change. For example for years I used rxvt with the tabs extension and refused to use st and only recently did I migrate to st with tmux providing that tab functionality.

<aggi>oriansj: i had even removed tmux from my list, because autotools/automake

<aggi>i removed Xorg/gtk etc. too, because of it's flawed unicode implementation (transitive c++ dependencies, among other issues)

<oriansj>so no wayland I am guessing

<aggi>exactly

<oriansj>just raw terminal with potentially screen or emacs multiplexing

<aggi>but there is a tiny niche, to mention a few projects: dvtm terminal multiplexer, yaft, for linux-2.x there was an in-kernel window-manager "fbui" which i might try

<aggi>emacs didn't pass here (i didn't intend to drop it), vis-editor integration was relatively clean

<aggi>that's how, as soon as some specific acceptance criteria are flocked... what remains then

<aggi>one such criteria, tcc-toolchain only (as a sanity check at least), no c++ dependencies

<aggi>no python (hence gentoo tooling will be gone), lua integration was much easier

<matrix_bridge><cosinusoidally> TinyCore Linux use a cut down fork of xvesa https://github.com/tinycorelinux/tinyx instead of X. They are a < 20MB linux distro with a GUI.

<oriansj>aggi: no lisps nor schemes either (except mes.c)

<oriansj>as most of those need either GCC or clang

<matrix_bridge><cosinusoidally> Fabrice Bellard also created a text editor https://bellard.org/qemacs/ . I've never used it, but presumably it will compile with tcc. Looks like there's a github repo too https://github.com/qemacs/qemacs

<lanodan>Well with https://github.com/michaelforney/velox I think you could still have wayland, at least https://git.sr.ht/~mcf/oasis (same author) is making use of it.

<aggi>i got no way yet, to publish what i would consider stage0-x86-tcc.iso (speaking in gentoo terms, be capable to bootstrap any later GNU stuff with)

<aggi>it was blocked against kernel compilation issues, and currently i am re-iterating over libc to try

<aggi>any experience with newlib? it too would need some patching to pass with tcc-asm in it's startup code

<aggi>to avoid binutils, i had to re-write the bootcode stuff from linux-2.4 for any other assembler, tcc hasn't got 16bit x86 real-mode on board

<aggi>or, re-considering Oasis linux, who completely(!) re-integrated binutils already, with their lua build-system

<aggi>at least i can scrape some dependency tracking from gentoo-crossdev (which i verified for various architectures already, and too with tcc-supprt hacked into)

<aggi>so, i got ebuild-logfiles for this, and too oasis linux could help, if i want to re-establish a packaging tree

<aggi>with guix i was scared away because of lisp (no offense)

<matrix_bridge><cosinusoidally> M0 can probably do 16 bit code if someone wrote a x86_16_defs.M1 file

<aggi>i consider the #bootstrappable parts with mesc etc. a separate preceeding task, i would merely trust and rely upon it can provide a tcc-toolchain

<aggi>well yes, the 16bit bootcode parts are blockers (with a potential circular dependency introduced again, even when binutils were re-integrated with the mentioned lua buildsystem avoiding autotools etc)

<aggi>it is a few hundred lines of assembly "only", which build up a gigantic dependency graph against binutils

<aggi>i think in the early days, linux used a different assembler than binutils, for x86 16 bit bootcode

<aggi>for the time being, i merely set LD=binutils-ld for bootsect.S (there's no other place binutils would be required), and keep that on hold until the issue can be resolved

<aggi>gladly, for the few 32bit assembly parts inside libc, bootstrappable already patched musl iirc

<aggi>to my understanding #bootstrappable completely avoided a kernel relied upon 16bit bootcode, and instead you're loading some self-made assembly first

<aggi>i think that's how 16bit unix was related, which was unsupported, until FuzixOS showed up... maybe that's the missing link in the chain

<aggi>16bit unix had the benefit, there was free and open hardware designs, such as the Z80 SoC

<aggi>yet, now get the irony of it, the SDCC compiler, is written i c++, and doesn't run native on such a device of cause

<aggi>it is interesting how, NASA had issues with their i8086 16 bit supply chain already, and terminated their "space shuttle" due to this

<aggi>since, 16bit it was which carried the ISS into orbit

<aggi>with a giant tonnage of electronics waste floating high in the skies

<aggi>Airbus/EADS chose SPARC, and are heading for risc-v since recently (see sparc leon and the vendor web site)

<aggi>FPGA development is plagued by proprietary malice anyway, and sourcing _original_ 16bit z80/8086/6502 and similar relies upon dumpster diving on ebay

<aggi>just like NASA had to

<aggi>the j-core.org project, which too involved free/open hardware, it's developer mentioned acceptance criteria from EADS, hardware must be documented as VHDL and similar

<aggi>well, SuperH was a big deal for BMW (reading on wikipedia), close nearby EUrofighter development Munich, and it hasn't got clean bootstrapping either

<aggi>EUrofighter itself relied upon some 68k stuff besides, too texas instruments did with their malicious TI89 series for example

<aggi>texas instruments too is pointing at Munich again, where they got an office

<aggi>just for fun, i too did some reading about the TI series calculators... no chance, their computer algebra system is proprietary and hidden on some tax heaven island

<oriansj>aggi: well writing assemblers and linkers are fun to do

<oriansj>so replacing binutils for a few hundred distinct assembly instructions seems like a weekend task (or week long depending on free time)

<aggi>even if, i wouldn't want to see any precious development man power wasted

<oriansj>and yes ultimately I am planning on expanding mescc-tools to be ported to *EVERY* architecture

<oriansj>aggi: there is no wasted effort here. Only people doing the work they find useful and sharing it with others.

<oriansj>if other people don't use my work, that just hints of slightly different goals and that is fine. We don't all have to agree on the goals just the basic common ground. We are here to bootstrap; human written source code only

<oriansj>all work under FSF approved licenses.

<aggi>oriansj: i am not worried about permissive licensing, i am worried about the quality of software (and too hardware)

<aggi>that's my critique towards FSF: quality issues

<aggi>FSF itself had documented inside their info docs from gcc (version 2.7 iirc), they haven't got clean bootstrapping for it

<aggi>yet, they advertised it as "free software", when instead since EGCS such software was abused to support proprietary malice and vendor chaos, for decades already

<oriansj>aggi: I understand the desire for quality software. And I agree more quality work should be done.

<aggi>and it's too political, because i see problems rooted in anti-competitive practices from USA, such as their "semiconductor chip protection act" (SCPA), 1984, around the time when FSF/GNU emerged

<oriansj>I too wish to eliminate proprietary malice and vendor chaos; Guix is my step in that direction.

<oriansj>aggi: humans are messy, complicated and have legitimate reasons for their self-centered actions. All I can do is appeal to long-term self interest and short term fun to carve out a niche of trust and shared understanding.

<aggi>oriansj: i want to share all my work, yet try to avoid confusion, and i don't want to see corrupt corporations scraping from me ever again

<aggi>currently, after my job placement inquiries were rejected, _again_, i must re-apply for a permit here

<aggi>and guess why, because i am "unproductive" "incompetent" "non-competitive" "distanced to labor market" "without recognized education"

<oriansj>well the state of Michigan is always hiring programmers; you have the good engineering taste needed to do well.

<aggi>other than the one i had at telekom university that closed

<aggi>oriansj: i wasn't trained as specialist/expert

<oriansj>aggi: we hire people with no programming training but either good references (other programmers they worked with) or good public work (publicly posted source code that they have written)

<aggi>i was trained for management

<oriansj>and one of our technical leads was trained as a chemical engineer

<oriansj>and a different technical lead was trained as an English Major

<oriansj>paper work only filters out organizations that don't look for talent where it exists.

<aggi>i think, it's up to domestic bureaucracy/politics in germany, to re-iterate of those dozens of billions of cash wasted

<aggi>and what i was obligated to do, in germany

<aggi>cutting down a little on NATO spendings

<aggi>Unix, that was Telekom, but that's a completely different perspective

<aggi>if telco backbone required a little management too

<aggi>yet telekom headquarter didn't bother to ask, why i left, 20 years ago

<aggi>*over

<aggi>besides, there is reasons why most/all WiFi/UMTS chips are blobbed and closed

<aggi>as far as bootstrapping of this was concerned, to retain networking, AX.25 with a software modem caught my attention

<aggi>direwolf project on github for example

<aggi>telecom backbone, what was the final stroke? SIGTRAN, i've had enough of this

<aggi>the measurement equipmen (scopes, de/modulators, protocol decoders) etc... most of it proprietary

<aggi>same situation, as mentioned with hardware and software, arriving at a Hays300 at best, to keep that free/open for bootstrapping

<aggi>because, this was another acceptance criteria, my development setup had to remain connected to the internet at least

<aggi>otherwise i had departed into Gigatron/Z80 stuff already

<aggi>what was it with german military? they had wasted another 8billion cash for their military radio, because system-integration of it failed

<aggi>in public, that was merely discussed as some parts didn't match each other... another 8billion gone

<aggi>meanwhile, i was forced to dispose paper waste in grocery store, threatened with extortion letters by the landlord

<aggi>to pay rent

<aggi>the SIGTRAN and X.25 one was notable, because, historically, it was circuit-switched networking with out-of-band signalling which carried TCP/IP/BGP

<aggi>nowadays, telekom signaling is virtualized atop packet-switching, simplified speaking

<oriansj>aggi: I understand your frustration. It seems so obvious that things could have been done better. but being outside of those organizations I have no ability to move things in a better direction.

<aggi>ITU-T was the oldest international organization of the united nations

<aggi>who too sponsor some FSF/GNU stuff btw. such as the flawed unicode implementation for X11/GTK

<aggi>so i may read telecom standards in farsi language

<aggi>X.25 too was/is used for signaling within the power-grid, railway etc. etc.

<aggi>"critical infrastructure", "minimum acceptance criteria", "supply chain attacks"

<aggi>i haven't checked the accounting of Huawei yet, how many trillions of cash were dumped into 5G of theirs

<aggi>that i wouldn't accept connected to my development workstation, with WiFi connected anywhere

<aggi>i got a residence permit until 31.07.2024

<aggi>germany's employment agency central, is a few hundred meters away from my current apartment

<aggi>they had not processed my inquries for more than a decade

<aggi>well, i've made a little noise in politics due to all this

<aggi>suicide rate among telecom france staff was reported significant, that's where much of the GSM/ETSI related "standardization" is stamped

<aggi>reminds me of Bellard again, who had some affiliation to telco stuff too, and an interesting "tiny" project

<aggi>i see Fabrice Bellard, did hack some stack for "mobile switching center" too

<aggi>amarisoft or whatever this company was

<aggi>this is what European Train Control System (ETCS) had issues with, to implement reliable signalling over GSM-R

<aggi>which may or may not involved AX.25

<aggi>reading further, some ETCS reached obsolescence before it was ready for production (according to my estimates)

<aggi>variant

<aggi>yet i could neither afford an office nor a railway ticket

<aggi>and they want another 11billion, out of nowhere

<oriansj>well who wouldn't want another 11 Billion out of nowhere to do the things they want done?

<oriansj>heck with 11 Billion I could hire all bootstrappers and let them work on bootstrapping as their priorities for life.

<oriansj>spending only interest and still have money to hire even more.

<aggi>thing is, France is nuclear power

<aggi>USA too is

<aggi>i was reading, in USA they're relying on PDP-11 stuff still, and intend to prolong indefinitely, without staff available

<aggi>although i fear PDP-11 is virtualized nowadays

<aggi>whatever else the situation in France was, they had issues with their power plants too

<aggi>and Germany, shut down nuclear april this year

<aggi>because then, that's the future prospect, none of it is necessary (including bootstrapping) with a bright 5G future ahead

<aggi>the former Soviet semiconductors are gone mostly too (there was some relevant z80-era parts, nearby Chernobyl)

<aggi>coming from GDR, our semiconductors are gone (besides we spoke german language here, not english)

<aggi>besides germany was/is not member of the infamous "Five Eyes"

<aggi>subject to COCOM proliferation, that's how i see bootstrapping issues related, on the political side

<aggi>nowadays it's coped with by "anti-trust regulation", among EU

<aggi>but that's all "false flags", subverted by lobbyism and corruption, if there was any ruling

<aggi>ministry of the interior does certify equipment too, for critical sections

<aggi>German airforce generals tapped on their Cisco WebEx telco discussing Taurus/Mephisto warhead deployment... few weeks ago

<oriansj>yeah the term we use is SNAFU

<oriansj>"Situation Normal; All Fucked Up"

<oriansj>other people will do wasteful and dumb things. But it is their lives to live; all we can do is offer advice and let them choose to use or ignore it.

<oriansj>Who does decides

<aggi>i was told at "employment agency" that's all just a "hobby", few days ago

<oriansj>tell them that bootstrapping work is considered the fundation of trust for 38 global Militaries

<oriansj>and 138 Financial institutions.

<aggi>better not, since this attracts too much attention among charlatans who seek profit with telecom and nvidia stocks

<oriansj>aggi: the crypto-community has already started using our work (over 1K cryptocurrencies at last count) and in the past did send death threats. So it is unlikely for them to do much more.

<oriansj>minus dongcarl; they generally left but dongcarl did the bitcoin/guix work and generally has been a positive member of the community.

<oriansj>part of me wishes dongcarl did another bitcoin talk called: Trust; in which the hard work completed is pointed out and then spends the next 20 minutes slamming the community for its past bad behavior.

<lanodan>11 billion sounds like a lot, NLNet NGI0 for example got 11 million grant total between 2018 and 2022 to fund libre internet projects.

<aggi>that was the railway one only

<aggi>*Comecon it "was"

<aggi>and it's weaponized again, under different terms, against russia

<aggi>myself, isn't a spie, from former GDR

<aggi>but it seems, noting rudimentary russian language basics in my CV didn't help either

<aggi>i remember Ukraine Telekom headquarters were shelled some month ago, no clue why

<aggi>since i left 20 years ago already, i had not taken any contact data with me ever, and trusted the institution to remain

<aggi>in germany, the last remaining telecom university closed, december 2023

<aggi>most ITU-T "standards" are "confidential"

<aggi>and among automotive, when contracted with QNX and their documentation, that's subject to NDA

<aggi>although i consider the related management chaotic beyond reason

<aggi>ACTION needs some vodka

<aggi>at least, RFCs are writtin in ASCII text, not some microsoft word documents floating inside a sharepoint server at ITU-T

<aggi>most basic terminal I/O caught my attention too, fyi, matrix plotters (epson 9pin can be used as terminal out)

<aggi>DEC is defunct since 1998, and gone with them were their sixel support for terminal

<aggi>and printers

<aggi>related to bootstrapping, this is what early terminals used, a plotter for terminal-out, and punched paper strips to load tinybasic and similar

<aggi>wikipedia... can still be used, incuding sixel graphics inside w3m browser, atop yaft terminal (with a minor patch)

<aggi>anyway, tty handling is scary

<aggi>fundemental distrust against the state, that's what oligarchs were beheaded for in Russia

<aggi>i distrust german government

<aggi>currently they assmble at "G7 summit" italy, and the pope had to say something

<aggi>oh, Stoltenberg NATO secretary live on TV... who was it? to pamper his Norwegian Pension fund with military spendings as biggest investor into tech sector globally

<aggi>the last remaining Telekom University that closed, december 2023, in Leipzig city, kept _original_ analog telephone switching equipment inside their museum

<aggi>the German LC80 deserved a place inside the computer history museum, i haven't seen any myself, to touch it once

<aggi>typing into hex assembly with it on a calculator type keyboard (that's how programs were loaded, by typing them)

<aggi>the Robotron 300 (IBM 1401 clone) had a reputation for decent documentation too, in Dresden

<aggi>i was born too late, to ever see it in operation, nor meeting the developers and engineers

<aggi>in a brief documentary, the engineers explained the difficulties to acquire most basic parts, including copper-wiring (or gold)

<aggi>in former GDR, which was isolated from global markets, hence engineers had to produce almost everything themselves

<aggi>official history was, GDR was lacking behind global markets, and their tech sector considered non-competitive

<aggi>although they did have a full Z80 clone implemented, including documentation written in german language instead of farsi word documents

<aggi>nowadays, it's Suadi/Quatar moneys to negotiate among UN security councils

<aggi>Russians jumped onto Itanium, with their Elbrus CPU, i suspect... linux kernel abandoned Itanium iirc

<aggi>i don't care

<aggi>the missing pieces seem to be 16bit computing era anyway

<aggi>that maestro evil Bill Gates considered "brain damaged" chip, the i286, to support x68 multi-tasking with

<aggi>it's this x86 16bit stuff, which is loaded first, as BIOS, until today

<aggi>reading further, CP/M developer had a fatal accident

<aggi>i consider 16bit too limited for Unix, although FuzixOS does implement it

<aggi>ACTION has to dispose some paper waste

<aggi>the other appartment neighbours here accumulate a notable amount of it

<aggi>and after 5hous of sleep, i woke up from speeding car's noise here

<aggi>some arab/yugo whatever music

<aggi>to my understanding, it is Saudi/Quatar moneys flowing, into Euro Soccer, UN councils, and tech sector

<aggi>all i see is, whom they're invested with, in Germany

<aggi>i won't watch Euro Soccer, although i hope Scotland will win the opening match this evening

<aggi>moment, Department of Defence (DoD), considered tty messaging higher priority than voice-calls?

<aggi>while Telecom was separated into a dedicated ministry... to provide consumers with TV and analog phones instead

<aggi>similar to how NetFlix is competing for bandwidth, that's not a defence project

<aggi>in germany it's "magenta tv", for fullHD soccer streaming, flooding unmaintainable networks with junk

<aggi>i think, the real issue isn't IPv4 limited address space, but BGP routing tables which blew up in size

<aggi>and IPv6 has the potential to make it _worse_, because of the increased address space, among other issues of "dual stack" required

<aggi>my ISP, that was KabelDeutschland (cable germany, docsis internet), transferred ownership to Vodaphone (british telecom)

<aggi>who denied me a public/static IPv4 with a DNS record made

<aggi>2Mbps synchronous had sufficed, for my individual needs

<aggi>they offered me 1000Mbps, without the desired configuration though

<aggi>and i couldn't have the 2Mbps neither, which can be multiplexed though

<aggi>within SONET, managed by SS7 (if that's still the case, i don't know)

<aggi>since i had seen ISDN specs, i rather stayed away

<aggi>even when ethernet wasn't made for low-latency streaming with guaranteed bandwidth

<aggi>X.25 supposedly provided "virtual circuits", if this was relevant at whichever layer of OSI protocol stack

<aggi>circuit switched, is fundementally different

<aggi>real-time, synchronous

<aggi>SS7 was known for fail-over switching circuits below <2ms latency

<aggi>not on localhost, not within lan, global(?) WAN

<aggi>at Telekom University, they chose to lecture motorola 68K

<aggi>tcc-toolchain hasn't got 68k, and it hasn't got sparc either... not blaming anyone

<aggi>this simply rules out some options

<aggi>aarch64 is a little rigged, without going into details

<aggi>but i do speculate, the industry had reasons to innovate with RISC-V now (although there was MIPS, OpenRISC, etc before)

<aggi>in case something went wrong with ARM

<aggi>with regards to tcc-toolchain, i couldn't compile any kernel for aarch32 or aarch64

<aggi>if i missed any, that's my mistake then of cause

<aggi>PCC had sparc/64, but it wasn't a complete toolchain to my understanding, required to bring full POSIX 32bit to live

<aggi>i see RISC-V heading into the same direction

<aggi>or who would be willing to port fiwix or gnu hurd or anything for it?

<oriansj>16bit computers were an evolutionary dead end. 8bit computers had 16bit address spaces and there is little reason to limit one to 16bits in a 32bit address space. (or even 32bit when you had over 1GB of RAM)

<oriansj>I see no real value with 16bit processors; when 8bit processors are simpler to build and 32bit processors are not much more complex to implement.

<oriansj>and greatly simplify software development.

<oriansj>and right now, outside of embedded environments 64bit is the default standard.

<aggi>16 bit machines (simplified speaking, Z80 had 4bit ALU), had a huge benefit, for deployment onto FPGA or designing hardware with TTL chips

<aggi>with bank-switching adress was extended significantly, not sure if that's related to segmented memory adressing

<Foxboron>g98

<Foxboron>wops

<aggi>the infamous 640KiB, that's 10 memory banks

<aggi>i am not aware of a single opensource SoC deployment onto FPGA with 64bit processors

<aggi>and whole amd64/x86_64 is plagued by various other issues

<aggi>i had in mind to re-consider a no-mmu kernel, sometimes i can't grasp the confusion with segmented and paged memory access

<aggi>Z80 was/is the longest lasting most produced chip until today, according to wiki

<aggi>and real-mode that is, how modern 64bit systems boot, until today

<aggi>with UEFI involved, things seem different, i am not interested in this

<aggi>16bit is a missing piece within bootstrapping, including the fact it's unkown how most proprietary vendor bios were implemented

<aggi>i was reading, when FreeBSD forked from 386BSD to remove AT&T code, an agreement was reached some bootcode-related parts remained closed

<aggi>that's the BIOS stuff, as far as i could tell, 16bit

<aggi>on typical aarch32/64 instead, uboot-loader is common, that introduced a transitive dependency against c++, for the boot-loader

<aggi>ludicrous

<aggi>not sure where RISC-V will be heading, to boot their machines (hadn't seen any yet)

<aggi>and typical linux kernel versions for it can't be compiled without c++ involved (inside the required toolchains)

<aggi>i remember 68k had decent documentation for their system-initialization, basic adress registers to configure i/o port ranges and similar

<aggi>it's not supported by tcc either

<aggi>it's noteworthy too, TI abandoned the TI89/92 series (with 68k inside), but continued production of their TI-83/84 variant with Z80 on board

<aggi>Z80, that's in essence the original 8086 16bit real-mode, if i am not in error

<aggi>i keep it at 32bit x86 for a little while

<aggi>thinking of coreboot/seabios in the bootstrapping chain, require gcc/binutils -> circular dependency

<lanodan>I think coreboot and the like could be considered another OS and I guess it's the kind where you'd need to cross-compile (I guess from an arm/risc-v machine).

IRC channel logs

2024-06-14.log