XLFS is a Linux from scratch designed to go from 0 to hero without fail. Currently, chroot1.go: cross compiles a cross compiler from 32 to 64 multilib then builds apps (some are older) X11R7.7+ and common utils, then makes a bootable USB with that on it. Currently the USB is clean and usable rescue but could run Xorg. (clean straight from chroot build not with XLF's specific boot (rc.d scripts, ipv4 network scripts, deamons). There is no root password set on USB. 1. makes chroot of it's 32 self 2. rebuilds itself to prove indepotence 2. cross compiles that fresh 32 build from 32 to 64, multilib 3. multiarch* is 32/64 is supported by not deleting 32 lib or bins 4. continues on to make some apps (xorg, motif, browser, qt, ...) 5. kernel and make-usb are items in build list, done if present 6. hd-hd-install is a simple script to copy to hard-drive (ex, mv's old OS to /os1 which is then a chroot, /home untouched) 7 XLFS does not attempt grub PHY install to HD, boots USB only 8. todo after hd-hd-install: run: tzselect, xdm-options Xlogin. NVIDIA-Linux-x86_64-515.57.run works without error: mv|cp|ln linux-?-?-?/ built dir to /usr/src/linux, cd /usr/src and sh ./NVIDIA-Linux-x86_64-515.57.run. don't forget to make gcc-10 the default compiler first for 5.11.8 kernel. 9. caveats: usb made is rescue disk style (no X or net on boot) While video and sound should work on Intel, little is yet done for Wifi though SysV has had wifi internet working in the past. While xlfs initially avoids Intel-only Linux-only script, things leading up to running Firefox are impossible w/o GNU linux. 10. it's a todo whether to up the cost of USB with /usr/src/dl/*.gz or to keep *.gz off USB and expect download off a website 11. If you want to "learn to build a Linux" just watch it run and read chroot1.go and build. Nothing is hidden. Not every build supplies a cpu-upgraded OS from scratch that runs real (not virtual) and also supplies the cross compilers also (and the data which worked): no distro I have found does so. I think that's why many forked distros but found there were glass ceilings which I hope this (script) undoes. However just recently new projects other than gentoo BLFS are offering an LFS , just since I began this project, though most "are virtual only". NOTE: is not suited for running difficult laptop hardware, there is not automatic setup for broken video or wifi either. if it didn't work in blfs or deb it definitely won't work here either. ultimately who sold you the laptop is who you should ask "why" to. ------------------------- BUILD all and make new pc-bootabble USB of it all OPTION 1 run on USB boot usb # cd /usr/local/src{8,9} UNPLUG INTERNET HERE (see Questions) # sh ./chroot1.go chroot_create_go OPTION 2 run on HD see INSTALL step - xlfs will not make HD partitions for you ------------------------- INSTALL OPTION 1 boot usb make a HD gpt partition and format it . xlfs won't do this step it's too likely to be problematic . xlfs currently uses 'parted gpt', make-usb.fdisk (mbr) is a todo # cd /usr/local/src2 # sh ./hd-hd-install OPTION 2 some other linux exists, install only xlfs-0.2 build scripts # mkdir -p /usr/local/src2/ # cd /usr/local/src2/ # tar -xzf build-0.2.tar.gz # cp -a /usb/usr/local/comp /usr/local/comp # cp -a /usb/usr/local/app /usr/local/app ensure build.conf states where we can mount *.gz read-only, check settings UNPLUG INTERNET HERE # sh ./chroot1.go chroot_create_go ------------------------- USE INSTRUCTION See: DIRECTORY for quick descripts of all files ie, ./spread-hack spreads a file to other src?/ but not chroots Configuring: . edit build.conf (do not change paths if you can help it, isn't trivial) once familiar you can build new roots changing just 3 items and new 'list' . edit file path, for stability /usr/local/src[2,3,4] should be hard coded . make sure ./mnt-disk works (and path path_[s]bin meet any path change) . create empty chroot1/mnt-src to try it, ls /mnt-src/usr/local/src/*.gz umount it and remove it before running go . rm *.done *.cur DO NOT CIRCUMVENT "mount read-only required" in build.conf chroot1.go You need it to protect. No mount in chroot should be rw, ro mounts only. # UNPLUG INTERNET HERE sh ./chroot1.go chroot_create_go # created in /usr/local/chroot1,2,3/ # creates chroot and building should begin and not stop for a while # if it stops and fixes are needed, commands can be used (see below) # sh ./chroot1.go chroot_continue. documenting the process is a todo path: edit this if your building an additional os from /usr/local/src? build.conf: highly sugg. you change only disk= /dev/sd? , is mounted read-only, where /usr/src/*.tar.gz are found) real target cpu (only intel64 tested not k8, core2 v. general is ok) hd-hd-install: only moves directories being replaced (ie not /home /foo2) * xlfs older System V boot scripts are NOT installed automatically * xlfs older System V boot scripts work but were intended for personal use not for distribution * xlfs older System V is not auto-installed, and is ipv4'ish. xlfs System V was designed to need little done to install. swap /etc /Users/{etc,scripts} and move a few server dirs in. ie: /User/{named,postgres} and /usr/local/{apache,sendmail}. Most of it's internet backbone servers are "destroyed" by newer linux changing things non-standard and big tech DATA CENTERS tons of eqipment to IP BLOCK (competitors), so several servers that had been fell to dis-repair. * it is supposed to be (usually is) hands free to get X logins up but when it needs a push - that may not be documented well . use newOS as / after testing and some local booting considerations you should use it for a while (boot to chroot) before changing over to it which you'd do by editing /etc/fstab, if this is your first go at it chroot1.go do_pivot: use is optional if you've made USB and wish to continue developing in chroot3 either for ENV reason or to be able to redo USB with updates, try it build.conf.n anything you change (disk=) must be in all During build can you chroot in to chrootn? yes. use "vis" and "more" in chroot1,2. ------------------------- Things to know: . chroot1.go and build automate extracting and compiling but downloads are not (expected you have a download dir with all *.gz) . ./build mostly is not supposed to know what a chroot is (separation of duties) and why is it runs in or out of one . ./build provides defaults for compiling: it does not require any pkg be built in any particular way. it offers defaults for recipe hoping pkg compile with no recipe if lucky . see DIRECTORY , ie learn about build.global.opt autoconf defaults (but dont change them before first run, may cause confusion) ------------------------- Questions: # UNPLUG INTERNET HERE . build-0.x attempts to prevent "not really open source" from downloading unknown things during build: redhat freedesktop.org have apps which acess the internet (in all cases causing build fail/stop not success) (note gcc-12 in future tries to make this "stick" by making forced internet access by cmake "an option that cannot be removed by any gcc options". note many such builds use root install authority to continue building rather than actually installing - another common deception Can you Not build it all on usb (slow usb disk) to speed things up? uhhh... + change your directory lCHROOT (a pair), that's where it all happens - no, you'd need xlfs dirs /usr/gcc /usr/libc /usr/local/src/linux (headers) so i guess you could Can you build multiple at once? yes... but keep lexical form "foo1 foo" edit file path in /usr/local/srcN that you copied over to srcN edit all build.conf.n lCHROOT1=/usr/local/lCHROOTb1 lCHROOT=/usr/local/lCHROOTb run chroot1.go edit path in /usr/local/srcN2 lCHROOT1=/usr/local/lCHROOTc1 lCHROOT=/usr/local/lCHROOTc SAVE YOUR FILES to build-0.2/ or run $ sh ./spread-to-chroots build.conf* path run chroot1.go Can you reset start over ? yes but auto delete of chroots not supported. rm do_chroot.*.done do_chroot.cur (in /usr/local/src2 where chroot1.go is) umount anything mounted in those chroots rm -r (any chroots you wish to remove) sh ./chroot1.go chroot_create_go Can you copy scripts changes between mutilple chroots? check ./spread-hack to see if paths used are suitable for your site $ NO - sh ./spread-hack build.conf* path (differ per srcN, would clobber) $ OK - sh ./spread-hack chroot1.go libc.list update.path Why are only C C++ built not other GCC languages? . see ERRATA Why isn't documentation built on some redhat freedesktop apps? . because i found in build-0.1 it was highly prone to build fail including in the root chroot1 chain . with source the builds failed and or still required INTERNET CONNECTION (requires foreign penetration during build and not really open sourced) (many builds build with root permission during install - I DO NOT ALLOW) . couldn't be alleviated by downloads because they required a fully built system which is impossible if truly compiliing from scratch . attempting to get source resulted in finding PYTHON MICROSOFT HACK SITES with 100 versions of same file disorganized . ... How to run X? . Long story. See /etc/X11/xdm-options/README ~ Xorg compile default -notcp does not mean X isn't fully networked ~ ~ Which means it deserves firewall consideration. ~ ~ While boot-rc should do that I ask you test it for yourself. ~ X is "network transparent". If you are configure you can run remote programs and see them locally or vice versa AND also run X remotely and your display is from a remote and also show X running in a subwindow. (today big tech charges for that: but they got it from Xerox) How do I run UBUNTU DEBIAN binaries? . some bins from Ubuntu 20.04.2 LTS run directly using src8 src9, I see . If you have a deb or ubu chroot you may be able to softlink libs in /usr/local/lib, run ldconfig, and run a binary that needed those libs. Since debian SARGE there are increasingly more bins that don't run under GNU compiled libs and will demand every ubuntu-ized lib from A to Z. . Or make a chroot, put debian in it. How do I run virtual KMS ? . No. xlfs target audience is native, real. Beginning with kernel options, running under Win10 is not setup/enabled. DiY . I've tried virtualbox quemu with older linux kernel they were SLOW, difficult to setup, get very bad X11 speeds and Win10 probably steals-by-cloud anything done inside it. You go ahead not for me :) . bochs-2.4.6 is provided as a leg up to run old software it is not going to win10 or linux well and is not configured - just a recipe to compile What about Arm support? . I don't have one cannot afford. Any support would be mere conjecture. I want to install to /usr/lib not /usr/local/app64/lib64 . xlf's glibc install used to require direct install "most generic" (a simpler glibc supported method is now used, indirect by tarball) . you can't because cross compiling requires multiple os/chains running because they are different and possibly 32 v. 64 also, and also you can't if you want both 32 64 support runtime. more below on lib?64 and what if 32 isn't wanted. Can I run newer xorg-server than 17.4? Older? . I had blackscreens with kernel built and my video cards (tested Nvidia built driver, intel HD630 vesa, nv vesa). A recent xorg-22 build in src9. For > 18.4 if you don't get a visual xorg DOES NOT restore linux console (forced reboot). 1.12.4 build in src9, ran ff107 at least. see src9's list.test.3 ------------------------- Audience: build-0.2 is a collection of 2 things: defaults that most software will build using and optional helpers for those that fail, also it makes enacapsulated run scripts for each build for reference. it evades issues of whither chroot1.go invoked it in a chroot or user did to build a pkg in /usr/local/src (but there are a few exceptions where it must act differently ie glibc install) ./build should NOT be run in an existing OS without chrooting it unless one is a little experience with what it does. also - don't guess GUEST_OS prevents all bad actions - it prevents some actions taken while building "normal apps that go in /usr/local" - ie: don't install glibc in / it might do it and crash the OS Cross "example" supported 32->64 is not canadian (multiple host not utilized). Canadian expects 64 target running 64 OS missing compiler (unusual i think). Cross ex. assumes older 32 OS with 64 linux kernel booted on new pc (upgrade). For K&R crowd note linux 64 means int=32, so you'd have to re-rebuild after all with new headers, assuming software was willing, for int=64. Xlfs does not transfer built bins to other hosts dynamically or have any host control bins - that would be like XCode on Apple debugging on iPhone sophistication; note you can't cross compile llvm compiler in Apple i'd think, which is part of what xlfs is - 32 to 64 from scratch not including multihosts. Not that xlfs runtime doesn't know network equiv, it's that i have no other hosts purchased to control dumb enough not to compile their own - i have a total of 1 semi-modern hosts and 0 androids. multi-what? many new projects are on (git web) and they tend to transfer compiled goods to or from emulators that way, so in a way that is like chroot1.go controlling a chroot build but no tranfer of products between chroots/emulators ------------------------------------- ERRATA . (new) linux headers go in $XLFS_BDIR as it turns out great place to be if you create new kernel but skip make-usb put them in src?/linux_next/ since that is not automatic (you also should boot that new kernel by updating /boot /lib/modules before building with new headers) . As long as binutils or libc do not interfere (some fail some interfere) gcc-4.7.4-32 and 64 compile 10.2.0-32 10.2.0-64 gcc-4.7.4 , 10.2.0 can each compile themselves 32/32 32/64 64/64 gcc-10.2.0-64 can compile gcc-4.7.4-64 and also reinstall after . biggest cause of "source repository damage" was: glibc-2.25 . glibc-2.36 never compiled 32 despite many ways tried, i will wait for a different version or keep trying . glibc-2.11 never compiled with binutils-2.36 despite many ways tried bu-2.36 breaks it using ".cfi" assembler changes (flavor hacks broke) . linux has begun "adding features which demand version bumping" seq_lock.h _Generic is the foremost one and even according to docs these new "lock flavors" are "not really required but forced anyway" _Generic is a back door for gcc to NOT do all the typecheck crap they enforced on everyone. newly MISSING FILES in headers like sg.h too. (summary: lk mission creep and win32 hacks will worsen - beware) REPTOLINE also a version bump: it is demanded by a kernel debugging module (only one using) which is set =n but causes upgrade need by debugged-lk.c having no #ifdef if reptoline using module is =n" . gcc-10 is big and slow. no firm physical reason to use it was found except to temporarily avoid intentful version bumping by linux-5.11.8 it has not compiled Qt yet mush less qtwebkit. without a "set of keys" (which i don't have) apps require alteration (due to NON-C type checks) but overall alterations are "few not bad" but there was no reason for. . build-0.1 used /usr/gcc /usr/libc and 4.4.5, 0.2 0.2 begins with 4.7.4 comp/ app/ so nixes build from 4.4.5 to 4.7.4 which is trivial and the recipe are still in build. comp/ app/ are 32 and serve as beginning srcdir/ copied by making-chroot1 and should not be removed because they are what allow 32bit apps to compile and run, keeping chroot1 chroot2 not necessary . you should not attempt trunking chroot3/ while building the same live ex. src8 compiles chrooth1,2,3/, you want to try chrooth3-new/ with a new list.test.3 , but src8/ is busy re-compiling chrooth3 DO NOT TRY THAT: the pathing is complicated and won't work fully . a.out .c .la store paths include /usr/local/src8/foo in them it's very possible (libfool) or what may notice and flub due to . XLFS_BDIR in xlfs scripts would be complicated to work around it thinks sr8 is used in / /chroot1,2 /chroot3 and has no facility why is the pathing is quite complicated if it doesn't, it would cause a need to prefix paths "like everywhere in every script" which i can tell you: is a nightmare whenever a change needed for "versioned trunking" beyond src1,2,3, chroot[a,b,c]1,2,3, either: 1) wait until sr8/ is stopped and swap trunk dirs simply 2) or start a src9/ . Enabling "default" languages on GCC, last time I tried on 4.7.4 10.2.0, worked fine. It takes significantly longer and isn't used in 0.2. However do it only in chroot3, I don't guess (some) would cross compile in chroot[1|2] without significant problems. . build-0.1 made /chroot1 from .deb files to build chroot2 32bit xlfs there is not a chance it would be preferred - build-0.2 is way easier and (with little change) build build-0.1's list OFF-TOPIC? Sick of lib lib64 cd dir dir dir lib not found lib64 not lib ? . you might wonder if lLIB_old=lLIB_new=/lib is possible. it is. but since "everyone" distributes software with libs having hard coded "/lib64/ld-linux.so" strings it would prevent using downloaded binaries. how is simple: compile chroot2 and 3 list in chroot3 with lLIB_new=lib as things install they will clobber /lib. when done lib64 can be deleted. delete any "old stuff" from /lib from local/comp that isn't from comp64. TODO: test that works as said. infact you might get away with editing the string in all binaries instead of recompiling (i logged in with hexiedit'ed bash after mv lib64 lib, it worked) ~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ BLOGGING BELOW ! The below should be viewed as un-moderated blogging. The 32/64 mentioned further below, switching to true int == memory register as C was designed to do (access all of memory without special hacks). Versions. If I haven't said it yet I believe REDHAT design is wrong: it's like a casino that marks cards to insure everyone must upgrade. When one developer compiles the compiler shouldn't "be a middle man marking cards" so that another developer gets it and must upgrade (these cards ld(1) reads). It should mark MINIMUM versions necessary so that upgrade is least likely. Example: printf("hello") should always result in marking LIBC5 markings (32 64 aside) never GLIBC-2.36 seen anywhere in the a.out to even see (not including in non-deterministic postscript). Unfortunately in a hurry I've blown past that and allowed the same to happen to this build. But GLIBC does have mechanisms to prevent "default version bumping". (I'd be surprised if it works since they seem to enjoy creating version bumps in any freedesktop pkgs they can - logging into mega servers to add things that do nearly nothing but bump version). I'd like to see that history "re-provided" without the spam. Compatibility. Other pet peves are pkgs that "load all .so whether or not the app users needs them loaded", requiring .so not required for what the user is actually doing (or requiring them for compiling when the software could option them out). (firefox opens like 5,000+ before you view 1 page !!!) Older software avoided those pitfalls (ie Netscape did) and some newer does. I'm sure we are all tired of it and are aware of it. lib v. lib64 is absolutely awful planning and design. but there isn't a way to "get rid of it" since it's use is now "prevailant". other LFS . however list of os from scratch asm which are undiscovered 1 collector? gotta love germany for some things - that collecting offering is one . Android x86 is not open nor does it allow Xterm - it is for asian laptops to run non-open binaries . buildroot says allot: then p. 200 "btw no compiler on target host" UGH!! others embedded (yokto) admit up front it will likely build fail . many linux builds require and run only in virtual boxes, not real . i *think* LFS BLFS used to offer full recipe - my info for 2021 is that it no longer offers full or any recipe in (the) book and there is not a download that fully builds from source (todo see if jhalfs does or if not or if failures are common?) . newly some lfs are appearing just since build-0.2 began but gentoo i cannot say what their cross-compile status is (gentoo had weak cross, but strong in redistributed maintainer base compile ability) Gengtoo has multiple os builds, but build fails, and IT'S MODERATED. If you say one wrong thing your IP BANNED for life by a nameless moderator who might just be hiding the truth. OFF-TOPIC: 64 is not true 64 if you are from K&R era. sizeof(*int) = sizeof(*char) in K&R, intentionally meaning after upgrade software compiled PORTABLY and getting access to the widest memory pointer, thus usable in OS code. THAT ISN'T WHAT THEY DID They made *int=32 and long long short short maybe maybe. This means properly written software will NOT benefit from upgrade while un-educated softare might or might break. Software will be 32 after upgrade unless "damaged with wrong headers" so might as well compile -m32, same thing. If you want true 64 edit headers and i would guess gcc glibc fall on face and fail entirely (a frequent thing without changes anyhow). I tried installing bins and libs one time from usr/local/sys2 in / (copied to by untar) and /usr/ so they are always found first, like build.early.list from 0.1. I got just segfaults after to chroot'ing in. I believe some parts of the system do badly if bins libs are multiply located and segfault on (any) bin except ldconfig(1) and bash. To date, softlinking "otherly located system files" to / seems to work best. Other common problems to check are missing links (like /etc/localtime pointing to old OS). . you can use strace to trace problems chroot'ing into chroot[n]/ but it's not easy. other than properly compiled and placed libs bins etc and share must be in order or you may get segfaults. /bin/sh must be right or you can't get in Why try an LFS? I fled from win95 back in the 1990 :) I found many problems with Win10 including "games have more authority than I do on anything" and my internet light shows gigabytes of downloads even when I've turned updates off and virus scan is not running. And no free tools or source code to find out "what is going on". Need I say gcc-12 has a feature that "downloads and runs code from foreign countries without ANY way to provide option to prevent it"? There's a reason to have your hands on source code. Highly unusual to put in such a feature without an option to turn it off: IMPOSSIBLY UNUSUAL. You need source to disable it or make it optional. REDHAT is pay only. Ubuntu/Deb src only builds if your "rebuilding the same thing they already packaged as bin" (and often fails even then). They will discontinue it and cause problems next release is "quite usual" (50,000 apps are depreciated??) I think it's well known by now that if Linux is an alternative to Microsoft that BIG TECH certainly will control it and make it awful. Not having the source? Makes a difference. Even with sources they can twist your arm allot. RH UBU MICROSOFT "made a casino of cards of ld symbol finding", shuffliing to obstruct so end users would find billions of build fails while the former "progressed" ... and meson win32 in linux make ... don't get me started. (they mark your cards highest version, and with other marks, and who gets your source/bins are forced to upgrade - plays in their casino not yours) Many have gone to llvm even euro freeBSD because distros like RH and Ubu have "made a casino of cards" insuring end users "must upgrade and even pay", which has I would say led to some linux wars of developers fleeing the "glass ceiling" platform. Which I think also has to do with trust, the old "trusted" meant bank level security while today it means a license manager that demands all passwords and remote cloud which steals your right of intellectual property and your right to speak to others on (forums). (I really like BSD but there aren't any BSD with good chinese hardware support and that simply cannot be ignored it is a huge issue) Many have fled to euro freeBSD google Win10 to flee RH and UBU only to find a different glass ceiling a different casino run by same big tech. That being said BSD (ie dragonfly for USA?) is really a better base sytem but "freeBSD" has been hacked to support RH7, gnu, and llvm and has little hardware support to show for it and no cross-compiled ability either. The fast cross compiling BSD C of the past was destroyed, gnu-ism replacing true posix, and the chinese hardware makers never "favored" BSD nor has Intel (graphics sound etc). Meanwhile Apple computer (nice bsd?) has gone "anti-intel" on low-cost models (had rant on apple.com but removed), but still has nice intel machines on upper end. I found many problems with Win10 including "drivers I had no source of that installed from china just whenever" and "my internet light flashes rapidly continually" despite I am getting no updates (have them turned off). Auto installs from MS app store that de-configured (shut off) my audio. Unstable apps esp. when internet on. Cloud share takes my IP but BIG TECH demands I pay for their IP. Lack of (free) network tools to see or change mystery inet use. No ability to kill certain programs, Games have higher authority than the administrator and in registry as root (and some use it maliciously). These kinds of things move one to want to see the source and have ability to The list goes on and on and users have complained and while MICROSOFT could "just enough to keep people content" they refuse. It appears they are more interested in "mangling linux to prevent competition" then to offer any true concessions. This seems trivial unless you've been around since the 1985's and know: they always have followed that path and have refused even free fixes. They aren't going to make concessions - corrupt domination is all they've ever shown interest in. __________ Some tried to make lfs from 32 to 64 back when that changeover happened and found fail after fail and were told they couldn't and this script (because it runs without failure) also serves as physical proof of why these people had problems in those days; tampering by big tech exposed in plain text/source fixes and notes how found. It's a fact. We all knew that big tech "with held recipes" they said, and withheld middleware also, ending in "$500/month rent for Redhat with demand to run a license server that spies on you" (some knew that was coming). However, Yes tree spikes found - not simple mistakes things who's only possible purpose was carnage of people and software. Proof the only goal was to create a casino of things that only casino owners could control. But there are other issues: allot of it was done using government money which suposedly can't be used to build glass ceiling OS and private companies. Well there is a LONG list of other important issues when you think about how paid, such as many bought paid forward the tools stolen by (some of big tech) and used against them using gov funds - a long long list let's say. Meanwhile this shouldn't be associated with Linux or Linus Torvalds - who does not distribute compilers or distributions. The kernel is still "modular" last I checked. You can say that's BLOGGING? But my own eyes have seen more than a few times newbie users ask about recipie and get mocking responses that "they can build their own OS that big tech shouldn't share anything" I WILL SAY: not only is allot of their code stolen or from free source, but today another huge problem - it's become GOVERNMENT FUNDED - which gets into whether it's legal to use gov money and attack and or charge others for use. OFF-TOPIC: What justifies an un-moderated blogging section? Why that? BIG TECH and democrats are a factor ... I've found a problem deleting "nasty comments in build-0.1" when which I did before uploading it to sourceforge During build-0.2 I was caught at un-awares having deleted nasty comments and ended up re-doing or spending time having forgotten which pkgs to be wary of. It matters not if your a democrat or republican :) There are things to be aware of if you plan not to spend extra time not having been made aware. Example: bison might have a win32 hack. I cannot possibly spend time determining whether it ever worked on win32 nor do I have time to write a book explaining why it is poison for linux. I have time to leave a nasty "virus" warning if the series has often been hacked by Microsoft and linux failures are found in adjacent or resulting script. I had countless fail repairs in build-0.1 and countless more in build-0.2. I simply didn't have time to do anything except say what was most probably true: "it appears to be malware by a competitor of linux" with possible swear words. If BIG TECH had not left so many "DRAGON DROPPINGS" - THOUSANDS - while actually mocking those doing fixes online (blogs, news) - I'd have had more time for code notes. That alone says it. I have a "job" of deleting comments in build-0.2 and wondering ... Should I delete all warnings? And leave myself and others unaware of (very) probable pitfalls to evade? I have junk/build.notes (in junk due to swear words had no plans to release), todo (grew so quickly and long it had to be separate from code notes I had no time for), and a few others that grew and grew with write-downs of what I needed to fix. And there are obvious stereo castings - the problems usually come from the same big tech crews. Why should they come off clean why not but blame on time? Infact - much of their work appears to be obstructing those who are "not big tech". Believe it or not the number of infractions (against GNU thoughful UNIX rules) is thousands. And isn't everyone aware of (political) accusations in the news by now are "about normal"? No longer whispering or kept off paper? I HAD SO MANY FIXES - despite already having done build-0.1, I DIDN'T HAVE TIME. so whatever. I had to write down the most likely warning and move to write next fix.