3 ms·

Free software doesn't typically have an SDK. A compiler is just one of the available programs. So is a text editor, a shell and script interpreters, some incarn

by tosti 10d ago

Free software doesn't typically have an SDK. A compiler is just one of the available programs. So is a text editor, a shell and script interpreters, some incarnation of make, etc. There's nothing really special about the compiler and you can write perfectly fine programs without ever touching it. That said, port trees usually have devel-* sections. Does that count?

sylware 9d ago
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).
- tosti 9d ago
  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.
  - sylware 9d ago
    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.
    - tosti 8d ago
      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.
      - sylware 8d ago
        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.
        tosti 8d ago

by tosti 10d ago

sylware 9d ago

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).

tosti 9d ago
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.
- sylware 9d ago
  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.
  - tosti 8d ago
    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.
    - sylware 8d ago
      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.
      - tosti 8d ago