Ohohoh! The complexity and cost of the various "open source SDKs" is on stellar scale. I build my own distro, and I usually remove SDKs to switch to linear orthogonal brutal build shell scripts... and I am going to warn you, you are going to see a lot of ugly close to insane.

You'll see also a good amount of more than questionable code generators. And when you will have a look at some _GNU_ makefiles of big corner-stone projects, you will question the sanity of their authors (the "makefile" itself is often, but not all the time, very questionable too nowdays). Everything was with a good intent, turned sour and painful on the long run.

On our modern computers, we should have "one-compilation-units" for most, if not all binary products (exes or shared libs) anyways. "Same language" binary static linking in the open source world should not be a thing anymore (have a look at those 'header-only' projects).

The invisible backdoor injectors (namely compilers) are a problem, for many reasons that most know here (barrier to implementation of real-life alternatives, [open source] developer lock-in, etc). The more complex is the syntax of a computer language, the worst it is (on c++ syntax complexity scale, or with a heavy/intrusive required runtime like many "new" languages do shove down your throat).

If you don't see any issue, get cproc/qbe C compiler (and the binutils gas assembler), then you compile linux (with a brutal and linear shell script, let's say for a real life x86_64 desktop) and we'll talk again after, ok? And once you succeed, we'll see how it holds in 7-10 years (the time ISO takes to break in a non pertinent way many things).

I reckon what you call SDK is what I'd call the build tools. C++ projects tend to use CMake and that's what I dread most. There have been projects where I brute forced my way on the command line towards succesfully compiling a binary. It's rare, but I kinda know the pain.

If I'd want to roll my own distro again, I'll have a look at an old dir with lots of scripts and patches where I tried doing just that. (I bet almost none of it works with current tarball versions.)

I think I'll retire with NetBSD. Keep up the good work though, someone ought to highlight the insanity of build tools building build tools.

In the SDK, I do include the "compiler": the computer language syntax complexity is critical here since it is a barrier of entry of any new "real-life" alternative compiler. NetBSD won't protect you here.

For this major reason, computer languages with a "simple" syntax and "alternative" real-life compilers should be favored (or you know it is reasonable to build one from scratch). The current _LESS WORSE_ alternative is C and similar. But this is far from a silver bullet. I think our only way out, namely getting rid of all this toxicity is assembly without abuse of any macro-preprocessor, that's why worldwide non-IP locked ISA standard like RISC-V are so much important.

NetBSD can be compiled from another OS and a compiler can be compiled to shell script. You'd take a minimal compiler (eg lcc), compile it to shell script, run it on the target, have it compile itself, older gcc and work your way up to one that builds the rest of the OS.

If you really want to start over from scratch, some form of assembly is indeed required :) And the first assembler would have to be assembled by hand. I'm not sure if riscv is useful for that, I'd try finding the oldest m68k still serviceable. And the sooner you get to C, the better. Starting from scratch is one thing, doing it all in asm takes more than a lifetime. And from C to various interpreters, of course. Most programs can be written in a scripting language and have fewer bugs than if they were written in more verbose languages.

I did not get everything you said, sorry.

But where I do agree: I presented the "assembly saving the world from big tech toxicity" would come with very high level scripting languages (probably a mess... but less toxic than what we have today), but with their interpreters/JIT "compilers" written is such assembly without abuse of any macro pre-processor.

I gave some thoughts about porting Bellard quickjs to pure hand written/tool assisted RISC-V assembly.

I'd favor more incremental steps. The sooner you get the specific CPU instructions out of the way the better. Otherwise your liberation party might be short lived.

What I described is an example of build bootstrapping. There's a website about it, https://www.bootstrappable.org/

Here, only regulation can help, there is no going against corpos with billions of $ and backed by funds of thousands of billions of $. Much of Big Tech abuses non pertinent complexity and size, not to mention their manic usage of planned obsolescence. There, the regulation should secure and set in ice a basic subset of file formats and protocols for interoperability which are known to be reasonable to implement again from scratch with "Small Tech". And by subset, I meant for instance noscript/basic HTML for the web; UTF-8 text files for text; I guess JSON should be favored over XML; a subset of PDF (certainly not all of it...);etc. If an online service have a 'chat', a basic IRC bridge should be there with a properly display access URL, etc, etc. That does not block "new" and "innovative" things to happen in any way.

Some of Big Tech hates "small is beautiful" and stability in time then will fight hard with their $ for that not to happen (administration "corruption"). Complexity and size (including the SDK then the computer language syntax complexity) is their bread and butter to keep "control" and keep alternatives away.

For the "bootstrappable", it is the starting point of building from 'small and simple' toward big and complex, aka the SDK 'binary seed'. At the time anybody would expect a 'simple C compiler' with a simple linker and assembler buildable with that simple C compiler... but people at the gcc steering commitee and the usage of many C extensions without maintaining proper fallback to assembler source files (in kernels, hence linux) broke the chain of 'sanity' for good. Now you must have an ultra complex c++ compiler to "bootstrap" (~LFS), not to mention the required zillions of complex tools required by the "build systems". Lately, it seems AI coding may be the salvation here... How? AI seems to assist writting c++(insert you computer language with a complex syntax here) to simple C "transpilers" (somebody pretended to have done the same with a rust->simple C transpiler, was published here on HN). I have to say I have never used AI, since they are gated with the web engines of the whatwg cartel (I cannot even get a token to use some web API), I have never tested.

The conclusion: fixing the software stack to let sane small alternatives to 'exist' and be 'real life' is probably not going to be calm and quiet.

Re: regulation, there were antitrust laws well before the Internet, but they haven't been properly enforced wrt big tech. I see no need for new laws (especially laws that cover technical details because politicians always screw those up), but it would be about time to invoke them. Else I hope they enshittify their way to collapse. The way things are going I think that's likely although it could take until 2038

Re: bootstrapping, your computer, your OS, your choice. When I power on my laptop it starts grub, linux, a shell script, sysvinit, at the moment openrc then kicks in (I want to replace that one), and all that's left running is init, sysklogd, chronyd, cronie, and agetty.

And I don't think vibe coding is going to help much at all unless you want another templeos. I think it could do that.

Here, "regulation" is more about a "minimal platform for interop" than anti-trust.

That "minimal platform for interop" would be made of simple but able to do a good job enough and stable in time file formats and protocols. This minimal platform must be reasonably implemented with "Small Tech" (excluding de facto the whatwg cartel web engine and computer languages with ultra-complex languages or heavy runtime this is common sense).

That "minimal platform" should probably be made with subsets of current file formats and protocols. As I said, for instance a subset of PDF (with validation tools), mandatory handling of basic UTF-8 text files, no script/basic HTML for the web, brutally simple SMTP support (aka self-hosted, not paying for DNS, or email addresses with IPs literals, only the commands to send actually emails without fideling around), IRC bridge for chat, etc.

BTW, on the "assembly to save us", I was talking about very high level languages with interpreters/JITs coded directly in assembly (aka binary specifications), then Mr. Bellard quickjs, but also obviously python (but it seems its syntax is going amok which is bad omens)/lua/etc.

This "platform" should slow down a lot the endless enshitification cycle we are into.

If AI coding is that powerfull (cannot test it as its access is gated by the whatwg cartel web engines), it can probably help: like I said, since we are not alone, look at what the others like me did: they are using it to write transpilers from ultra-complex computer language syntaxes, I saw on HN this norvegian guy who is using AI coding to help write directly in 'human readable' assembly (here x86_64) the binary specifications of its own everyday software.

This plaform must be very rigid, but not completely, namely rational removal/restructuring could happen. Basically, implementation "from scratch" by "Small Tech" must always be reasonable.

Aside of all that, there is the ultimate hard truth: for much software developement, but not all, it is extremely hard to justify a permanent income and that honestly. Making all that very complicated to fit in any economy.

Politicians don't understand the Internet, never mind its protocols. That's why they use silly terms such as "cybercrime". "Cyber" means "the Internet and I don't understand any of it"

Code written in assembly is more error prone, more difficult to debug and harder to understand than higher level languages. After years of reading and writing code I know being able to reason with others about the source code of a given program is more important than what the actual language is, or any of the other purities programmers like to keep. Without readable source, the program either dies a slow death or becomes some kind of minefield. And besides, throwing out decades of development is such a waste of effort.

I don't understand your comment on permanent income and the economy. Sorry.