home.social

Search

15 results for “stikonas”

  1. I've just updated my gentoo-bootstrap overlay (gitlab.com/stikonas/gentoo-boo) with fixes to GCC →OpenJDK 8 bootstrap. (There was a bit of breakage due to some old ecj tarballs disappearing from distfiles.gentoo.org)

  2. @filippo Meanwhile, bootstrapping a current OpenJDK involves compiling multiple ancient packages (each with its own set of outdated dependencies, of course) and then going up all the way from Java 7, version by version.

    @stikonas has described this tedious process and developed some ebuilds for Gentoo here: git.stikonas.eu/andrius/gentoo

    This also applies to Rust in a way, but at least it's not as bad there – not yet, as the old versions might eventually succumb to bitrot, too.

    Please, dear programming language community, can we do better at this? For resilience, for reproducibility, for reliability, for portability and for preservation?

    #bootstrappablebuilds #bootstrapping #reproduciblebuilds #trustingtrust #gentoo #openjdk #rust

  3. #GNU Mes 0.27.1 released: A bug-fix release that supports

    * development build with gcc-14
    * building with M2-Planet 1.12.0
    * building on x86-linux with M2-Planet 1.13.0
    * building bootstrappable-tcc using 1.00.02 <= NYACC <= 2.02.2

    <lists.gnu.org/archive/html/inf>

    Thanks to @ekaitz_zarraga and @stikonas!

    #GnuMes
    #bootstrappable
    #BootstrappableBuilds
    #ReproducibleBuilds
    @reproducible_builds
    @fsf
    @fsfe
    @gnutools
    @nlnet

  4. I was just reviewing the new x86 hex0 bootstrap seed: github.com/oriansj/stage0-posi. Big thanks to Noah Goldstein for making it smaller.

    Now it is only 190 bytes. Excluding ELF header that's only 106 bytes of code.

    For a couple of years hex0 binary was 256 bytes and before that hex0 was 357 bytes (this is the number that is still mentioned in guix.gnu.org/manual/devel/en/h).

  5. @harrysintonen @vegard These days we also have that prevent this kind of attack (at least at the software level).

  6. There is now an interesting guide by @mid_kid (mid-kid.root.sx/git/mid-kid/bo) on installing from just source and a tiny 200 byte kernel. At the moment it's a bit longish and starts with then pivots to to obtain 64-bit toolchain and finally bootstraps from there.

    Potentially some steps could be optimized, and removed but it works.

  7. @yrlf @jschauma Reproducible Builds don't help here, you can be reproducibly malicious. What you need is a bit stronger, i.e. . If you build the world starting from a tiny sub 1KiB binary, you can prove that there is no self replicating backdoor coming from software. You could still have one from lower levels, e.g. hardware. Those are both significantly harder to implement but also hard to solve.

  8. @ekaitz_zarraga and I have finally bootstrapped on starting from GNU and (and eventually tiny binary if you go further back).

    The binary that we have built is self-hosting and can build itself, though perhaps a few more bugfixes will be needed to reach the newest version of tcc.

    @janneke
    @efraim

  9. @janneke @aziz @fsf @fsfe @reproducible_builds @ekaitz_zarraga Indeed! Right now we can bootstrap all the way from to , then use to build very first build of (we can call it mes-tcc). mes-tcc can then build the next build of tinycc (boot0-tcc). Unfortunately, at the moment boot0-tcc segfaults. Today, I fixed one crash which was due to Global Offset Table being all zeros but it turns out we are now hitting another segfault, so more work is needed.

  10. now supports setting F2FS labels:

    invent.kde.org/system/kpmcore/

    This means you'll need to use non-ancient f2fs-tools package (f2fslabel command was added at some time in 2021)