(answering these old mails in chronological order... I was working heads down on the shell for 2 weeks, hence the silence)
On Sat, Mar 26, 2016 at 1:00 AM, Rob Landley <[email protected]> wrote: > > > On 03/26/2016 01:36 AM, Andy Chu wrote: >>> The problem to solve here is that Debian is currently broken when using >>> toybox. That's a real problem that needs to be fixed, but there's more >>> than one way to fix it. Debian introduced this bug within the past few >>> years and maybe we can convince them to fix it on their end, that's one >>> possible fix. >> >> What's the goal of toybox with respect to Debian? I looked through >> the design and roadmap pages and didn't see much about Debian >> specifically. > > I take it you haven't read http://landley.net/aboriginal/about.html > (specficially http://landley.net/aboriginal/about.html#hairball ). I think there is a good point here, to have a universal foundation and root of trust for different distros, although I wonder what work has been done toward this goal? I also wonder if the Debian maintainers would be on board with it. It seems like it would increase the maintainers workload to test with both coreutils/etc. and toybox. It's a pretty big moving target, because they update their packages with every distro release. I'm quite familiar with debootstrap, which is the big shell script used to bootstrap a Debian/Ubuntu system. You can use it to create just the runtime environment, or also the build environment, which can in turn rebuild the set of required or buildd packages. It's like a big 4000 line shell script, and it doesn't seem like it is very highly maintained (it's extremely inefficient, for one thing). I guess the best thing you can say about it is that it does its job. (FWIW I was building scientific computing programs in R with containers from the ground up, with debootstrap, installing build dependencies of R like Fortran, building R, installing R packages and their runtime dependencies, and then installing R scripts on top... it was quite involved and I have several thousand lines of shell scripts that start with calling debootstrap to do this.) > My original goal when I started all this nonsense circa 2002 or so was > Knoppix. Linux From Scratch was over 100 megs but tomsrtbt was 1.7 megs, > and I thought if I could save Knoppix 100 megs of space on its CD they > could do WONDERS with it. The goalposts hae shifted a bit over the > years, but oddly enough knoppix was debian based too. :) I like the Aboriginal goal of being the simplest linux system capable of rebuilding itself. That is very crisp goal, and it has some nice applications in terms of provenance and security. My questions were more about the toybox goals. The Debian goal seems fuzzy, and a moving target. Maybe there's something I'm not understanding. Also, I would consider stuff like "factor" and probably "rev" to be cruft in toybox ... is there any evidence that people use that stuff? I mean sure you can compile it out, but it just seems like a distraction. In other words, Aboriginal has a crisp goal, but toybox seems to have 10 different goals. The goals here are not very crisp -- it seems like a bunch of research on similar prior systems: http://landley.net/toybox/roadmap.html >> Are you only talking about build time, and excluding runtime? i.e. >> using toybox to bootstrap the builds of other distros? > > They're separate use cases. I want one to work and I want the other to > be a reasonable option. So you want to rebuild all distros with Aboriginal/toybox, and having things work at runtime is a secondary goal? But I suppose Android's runtime is the main goal for that OS? Because for now the runtime is going to be used way more than building... I don't think there are many people with compilers installed on their phones. > The amount of in jokes in my code is actually reasonably correlated to > the amount of sleep deprivation I was under at the time. (Like now, it's > coming up on 3am here.) The "struct {forever[];} strawberry fields[];" > nonsense in ps is a milder example. I edited most of that back _out_ > before checking it in. Also that song actually has very little in the > way of lyrics so I COULDN'T pull a lot of variable names from it if I > wanted to. FWIW this was preventing me from understanding the sed code when I was in there... :-/ > A) it sucked in python as an environmental dependency, and the move from > python 2 to python 3 is a bit like the move from gpl 2 to gpl 3, > fragmenting the community into incompatible warring camps and making a > lot of old-timers walk. (It doesn't seem to be turning off newbies > nearly as much, though, so maybe python will survive this if then NEVER > do a python 4.0.) Personally I think the best thing about Python 3 is that it froze Python 2.7 in stone. Python 2.7 will still be with us 20 years now, and I'll probably still use it because it works great for a lot of things (I haven't used Python 3 yet really). It's like a de-facto standard for Python, since PyPy and a half dozen other implementations all target CPython 2.7. > I was a longtime mercurial supporter, but bowed to the inevitable > eventually. Yeah same here. I briefly worked on Google Code, which did Mercurial hosting, later added Git, and was recently shut down. Git is frustrating, but I get why it's popular -- it really is the best tool for collaboration. It enabled me to juggle a lot of patches I sent you in parallel, something I never did with Mercurial. I believe in code reviews, and when you have code reviews you will have overlapping patches which need to be updated asynchronously... that is not an easy problem to solve, and Git is the best at it. Andy _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
