This is an automated email from the git hooks/post-receive script.
git pushed a commit to branch master
in repository 0d-edi.
View the commit online.
commit 88e2eec28ec46e6d0a8b136037c890f273251e92
Author: rhoyerboat <[email protected]>
AuthorDate: Fri Sep 26 22:49:15 2025 -0400
Cleanups to .md
---
README-0drift.md | 148 +++++++++++++++++++++++++++++++++++++++----------------
1 file changed, 106 insertions(+), 42 deletions(-)
diff --git a/README-0drift.md b/README-0drift.md
index 5fb86c8..5cd9dc8 100644
--- a/README-0drift.md
+++ b/README-0drift.md
@@ -1,69 +1,133 @@
-##
+a 0drift build of Edi - The Enlightened IDE
+===
-# README - 0drift build of edi (a lot of works in progress, which is why I wanted a minimalistic
- IDE that needed some work so I could practice.)
-In gentoo, assuming the emerge package manager is being used, the include and library paths
-will not be in places expected by the existing meson scripts so certain command line options
-must be used in order to specify those.
+## Introduction to 0d:
-Already in this revision of it (not prepared to call it a fork,) modifications to have been
-made to select BINDIR from /usr/lib/llvm/19/bin after it doesn't find the likely debian
-path of /usr/local/opt/llvm/bin. These modifications were made to scripts/clang_include_dir.sh
+0drift is: many works in progress, which is why I wanted a minimalistic
+IDE that needed some work so I could practice my actual programming.
-Assuming llvm-clang was installed by emerge, it is likely the following command that need be
-run: (I am not a gentoo maintainer by any stretch, in fact I am trying to essentially
-jailbreak it down to x86_64 architecture specifically and lose emerge in the process, which
-has gotten complicated to the point of being like its' mechanics were being deliberately
-obfuscated so, no promises.)
+It will do everything a daily driver does, including wine/Steam, but
+without rust or systemd. Which to me both represent long-term supply
+chain attacks, either against DIY/FOSS philosophy in general or directly
+against the compartmentalized architecture that GNU inherited from UNIX.
+Projects like Enlightment and Wayland make it look good.
+
+My experience is not so much in code as it is in DevOps and Support with
+some substantial time in the big chair in NOC work at a VoIP WISP/CLEC.
+
+Everything about 0d is meant to work backwards to stage1, human readable
+sources only, then build back into stage2 & stage3 in the hands of it's
+end user. It is meant to teach people who don't know what these phrases
+mean what these phrases mean. And the entire process. Imagine a spiffy
+tutorial interface in a compositing livecd that teaches shell scripting
+and the rest of the unix-like shell essentials as if it were a game.
+Or in the hands of advanced users it simply provides a consistent 0trust
+starting point.
+
+If there turns out to be funding down the road I will certainly kick a
+decent share back at the gentoo foundation, whether or not I really
+trust their product anymore they have done and do a TON of HARD work.
+
+## What was different about edi on this architecture:
+
+(mainly its really the librsvg business that will be written about
+later, the rest is simple distro-specific differences experienced
+users might take for granted that new users might struggle with.)
+
+Right now I start with gentoo.
+
+In gentoo, assuming the emerge package manager is being used, the
+include and library paths will not be in places expected by the
+existing meson scripts so certain command line options must be used in
+order to specify those.
+
+In this minor revision of it (nowhere near a fork/merge,) modifications
+have been made to the script that selects the BINDIR from which clang
+runs.
+
+Just an elif statement so that /usr/lib/llvm/19/bin is selected after it
+doesn't find the (likely debian derived,) path of
+/usr/local/opt/llvm/bin. These modifications were made to
+scripts/clang_include_dir.sh
+
+
+The two other consistent differences are the libclang-headerdir and
+libclang-libdir:
+
+On my setup, llvm-clang version 19 was running and emerge placed it at
+/usr/lib/llvm/19
+
+So the command that need be run:
meson setup ./build -Dlibclang-headerdir=/usr/lib/llvm/19/include/ \
-Dlibclang-libdir=/usr/lib/llvm/19/lib64 -Db_pie=true -Dbuildtype=plain
-This is a multilib system which prefers 64 and it wouldnt link to ./lib
-Also this kernel utilizes loadable modules so the position-independant executables (pie)
-option is important.
-Your mileage may vary.
+Also, this is a multilib system prefering 64 so it wouldn't link to
+llvm-clangs priority 32 bit ./lib
+
+This kernel utilizes unloadable modules so the position-independant
+executables (pie) option is important in case I utilize that. I wouldn't
+normally in prod but its a test box.
+
+Your mileage may vary. Check the meson options, I had to ;)
+
+Another thing: depending on how your system is configured you may have
+to set:
+
+ export PATH=$PATH:$whatever_prefix_you_assigned/bin
+ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$whatever_prefix_you_assigned/lib64
-Another thing: depending on how your system is configured you may have to set
- LD_LIBRARY_PATH=$whatever_prefix_you_assigned
-In my case, because I don't normally use this prefix but did here for testing,
-(but /usr/local/bin was on PATH)
+I just set it disposably at runtime:
+ PATH=$PATH:/usr/local/bin LD_LIBRARY_PATH=/usr/local/lib64 edi
- LD_LIBRARY_PATH=/usr/local/lib64 edi
-
-Voila!
+Voila! edi is running on a rust free library. rust is cool but the hype
+and money and sheer complexity of it make me think it is important for
+people to have non-rust options even if that means backtracking pretty
+far in some cases and redoing work and sacrificing some very shiney
+software-objects.
-Other changes - *edi is at a 0.9 version and intl was deprecated before I got here.
+Lets just say I think modern gnu/linux deserves a solid redistributable
+correlary to OpenBSD. That means winding some things back a decade and a
+half or so, when not more. I've been running like this the whole time
+and I am not sure what I am missing out on unless I am going to use
+jackd to actually do live production with random pieces of hardware.
+
+
+
+## Other minor changes:
+
+*edi is at a 0.9 version and intl was deprecated before I got here.
src/bin/meson.build had references to it removed entirely.
src/tests/meson.build as well.
-Reasoning:
+## Reasoning:
The straightforward build was blocked in gentoo by libintl being blocked by a virtual glibc package.
It has been a long day and I am spacing out on how that led me to fix a compilation problem with
- the last rust-free version of librsvg, 2.40. I run a hardened gentoo and I wonder if those security
- problems that led that project to migrate to rust were related to some distributor having disabled
- -Werror in order to get it to build, when really the developer behind that code block had acknowledged
- its hackyness in the comments and misused some of the provided structs. (This resolved all sorts of
- whole stack issues I was having in my attempt to patch together a new-looking old-school-under-the-
- hood style distro I am speccing out, but it was a huge day for me.) I was just about to start running
- JetBrains CLion in order to look into the relationship between libxml2 and librsvg when I found a
- low cost workaround for the problem, although it is likewise hacky. So I moved back onto building
- edi. A few added lines to scripts/clang_include_dir.sh to find where gentoo stuffed llvm-clang and
- a few variences to -D for the modular kernel, headers and libraries, and now I am looking forward to
- using edi rather than something else. I know JetBrains are great products but just not so rewarding
- to use as something that is written elegantly and has work-to-be-done on it to boot.
+ the last rust-free version of librsvg, 2.40. Ohyeah, it was that emerge wanted to build 17 sequential
+ copies of rust before it would get started on librsvg which is important to EFL.
+
+ I run a hardened gentoo and I wonder if those security problems that led that project to migrate to
+ rust were related to some distributor having disabled -Werror in order to get it to build, when really
+ the developer behind that code block had acknowledged its hackyness in the comments and misused some
+ of the provided structs. (This resolved all sorts of whole-arch stack issues I was having in my attempt
+ to patch together a new-looking old-school-under-the-hood style distro I am speccing out. (it was a
+ huge day for me.) I was just about to start running JetBrains CLion in order to look into the
+ relationship between libxml2 and librsvg when I found a low cost workaround for the problem, without
+ disabling any safety features. Although it is likewise hacky. So I moved back onto building edi. A few
+ added lines to scripts/clang_include_dir.sh to find where gentoo stuffed llvm-clang and a few variences
+ to -D for the modular kernel, headers and libraries, and now I am looking forward to using edi rather
+ than something else. I know JetBrains are great products but just not so rewarding to use as something
+ that is written elegantly in FOSS and has work-to-be-done on it to boot.
-References I am saving:
+## References:
https://gnome.pages.gitlab.gnome.org/libxml2/html/SAX2_8h.html
https://mesonbuild.com/Build-options.html
-For other reasons, currently haggard from 4am to 8pm session.
- https://wiki.archlinux.org/title/Bubblewrap
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
