Nice to hear from you Rob! The below thread was already part of the discussion, but it was good to see additional input. :) The latest mail should be dated Aug 2.<br><br>Dave<br><br><br><div class="gmail_quote">On Mon, Aug 13, 2012 at 4:52 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 07/12/2012 09:24 AM, David Henderson wrote:<br>
> Wow and I often complain about my schedule! :) Seems like you're<br>
> working on 28 hour work days! lol This might be a good opportunity for<br>
> you to possibly offload some work then - at least on the distro<br>
> creation/maintenance side.<br>
<br>
</div>Apparently, a chunk of messages from a month ago got missed. Catching up...<br>
<br>
(It's possible I already answered this one, but if so I don't remember it.)<br>
<div class="im"><br>
> My replies are in-line below to prevent confusion...<br>
</div>...<br>
<div class="im">> Define "their work"?<br>
><br>
> I did "boot to a shell prompt on serial console, with native development<br>
> tools", targeting various qemu platforms. This let people build code<br>
> natively.<br>
><br>
> I didn't really tackle "what tools do you need on target", because<br>
> everybody's needs are different and if you can build it natively, you've<br>
> got wget and a toolchain.<br>
><br>
> The proliferation of boards is kind of amazing. A half-dozen projects<br>
> from buildroot to OpenEmbedded accumulated buckets of board<br>
> configurations, but never cleanly separated them out from toolchain and<br>
> root filesystem config, and I decided the correct thing to do was get<br>
> defconfigs upstream into linus's git.<br>
><br>
> Their "work" would be anything the user normally does during the day:<br>
> email, word processing, listen to music, watch videos, program, etc.<br>
<br>
</div>This is not a bounded set. Different people do different things.<br>
<div class="im"><br>
> While the distro won't contain all of the software for everyones "work"<br>
> (e.g. CAD users), it'll start with a set of software to perform the most<br>
> common tasks.<br>
<br>
</div>Unfortunately the "most common tasks" really isn't a bounded set either.<br>
People are strange.<br>
<div class="im"><br>
> As time elapses, more and more can be added to include<br>
> users with more rare "work". This software, however, will be installed<br>
> with their "personal data" as mentioned below.<br>
<br>
</div>Good luck with it. I think that's a can of worms.<br>
<div class="im"><br>
> > 2. Although the OS can be installed and run from a storage device,<br>
> it's<br>
> > intended to take a minimal amount of memory as it's home - RAM based.<br>
> > This should make upgrading as simple as replacing a single file!<br>
><br>
> I remember ten years ago working out how to combine a kernel and root<br>
> filesystem into a single file, and patching lilo to have a "length"<br>
> parameter so it would only load the kernel and not the whole root<br>
> filesystem into memory.<br>
><br>
> <a href="http://landley.net/aboriginal/old" target="_blank">http://landley.net/aboriginal/old</a><br>
><br>
> I even worked out some unused space in the ELF header (for user mode<br>
> linux, the emulator I was using at the time) which was the old floppy<br>
> boot sector on real kernels so either way "unused space" that I could<br>
> stamp a 4 byte length to say what offset losetup should use creating the<br>
> loopback file for the root filesystem. (I used zisofs because squashfs<br>
> wasn't merged yet.) Getting an initrd built into the kernel so it could<br>
> do the loopback setup and hand off is what got me poking at initramfs in<br>
> the first place...<br>
><br>
> Good times, good times...<br>
><br>
><br>
> Wow thats pretty interesting! Currently XiniX uses grub, which I don't<br>
> think has an option like that.<br>
<br>
</div>Neither did lilo, hence<br>
<a href="http://landley.net/aboriginal/old/lilo-length.patch" target="_blank">http://landley.net/aboriginal/old/lilo-length.patch</a><br>
<div class="im"><br>
> Also, XiniX has the "firmware" and<br>
> Kernel separated (I didn't even know those two could be combined).<br>
<br>
</div>Firmware turns out not to be a well-defined term, but between initramfs<br>
and Greg Ungerer's "Linux without a bootloader" (slides<br>
<a href="http://elinux.org/ELC_2010_Presentations" target="_blank">http://elinux.org/ELC_2010_Presentations</a> video at<br>
<a href="http://free-electrons.com/blog/elce-2010-videos/" target="_blank">http://free-electrons.com/blog/elce-2010-videos/</a> ) there's no reason you<br>
_can't_ do such a thing today. But it would be fairly hardware-specific.<br>
<div class="im"><br>
> I suppose the integration of the two can help maintain system stability<br>
> since everything is tested and released together...<br>
<br>
</div>Not necessarily. Having orthogonal modules you can test independently<br>
and swap out different implementations of can help make the system work<br>
better too. Otherwise you get horrible version skew instability like the<br>
way udev only ever works with specific kernel versions.<br>
<div class="im"><br>
> Did you ever run<br>
> into any negative aspects when working like this? The only one I can<br>
> see off the top of my head is that if the distro isn't updated<br>
> routinely, the kernel will get dated and present exploitable bugs to<br>
> crackers.<br>
<br>
</div>If you're allowing arbitrary third parties to run random userspace code<br>
on your system, it needs to be administered. But if all it's got is a<br>
simple web server serving static pages out of a chroot there may not<br>
actually _be_ any way to exploit it.<br>
<br>
But the packaging mechanism was only mildly interesting, and I stopped<br>
doing it years ago because the bootloader built into qemu was a better<br>
solution for what I was trying to do.<br>
<div class="im"><br>
> > 3. Having an easily usable interface that's common among the various<br>
> > devices while being as simplistic and efficient as possible.<br>
><br>
> Shell prompt? xfce? Web gui for headless boxes?<br>
><br>
> Just getting the _drivers_ right for a wide variety of boards was a huge<br>
> pain for me, and I was focusing on qemu. And I have to regression test<br>
> them every kernel release and bisect some really nasty stuff sometimes.<br>
> (I'm doing a writeup the most recent round of git bisect to teach people<br>
> how to bisect bugs under adverse conditions. The one that broke armv5l's<br>
> scsi driver was buried several bugs deep behind "the serial console<br>
> broke", "build break", and so on...)<br>
><br>
> Currently XiniX is CLI only, but hopefully by the end of next month the<br>
> graphical side will be up and running.<br>
<br>
</div>So it's been a month. How did that go?<br>
<div class="im"><br>
> In order to keep the size down<br>
> while maintaining flexibility, the GUI is entirely web-based so it works<br>
> with head and headless devices in a uniform, consistent way. Also it<br>
> does have software such as QT and/or GTK installed for software that<br>
> currently doesn't have a web-interface-only alternative (and is also<br>
> required for the webkit backend).<br>
<br>
</div>Back up: what problem are you trying to solve?<br>
<br>
With Aboriginal Linux, I'm solving the problem of cross compiling, by<br>
trying to eliminate anyone else's need to do it (at least as part of<br>
Linux development).<br>
<br>
The solution is in two parts: substitute native Linux development<br>
environments running under emulation, and perform the cross compiling<br>
necessary to _get_ to that native development environment in a<br>
reproducible way for a lot of different plaforms (so you're not trusting<br>
my magic binaries but don't have to do it yourself either).<br>
<br>
In the process I'm answering some related questions: "how small and<br>
simple can I get a native development environment" (to reduce the bits<br>
that need to be cross compiled), how do I get the utterly sucky<br>
performance of emulators to a point people are willing to put up with it<br>
(pick a good emulator and install distcc to help out), and "how do you<br>
bootstrap up from there to more complex native build environments in a<br>
target-agnostic way" (all those build-images as examples).<br>
<br>
But the core idea here is "get rid of the need for cross compiling", and<br>
that lets me know where my project STOPS.<br>
<br>
It lets me know I don't care about drivers for specific boards, that I<br>
don't care about QT, that I don't care about package management on the<br>
target, or target code installation (bootloaders, jtags, sdcard<br>
partitioning)... These are all things where once people have a working<br>
native development environment, they can take it from there. I don't<br>
_have_ to solve that for them.<br>
<br>
Your project seems to have a less clear dividing line between what you<br>
do and what you DON'T do. If you can't say "this is not part of this<br>
project", you get feature creep...<br>
<div class="im"><br>
> Maintaining stability for various aspects such as the drivers mentioned<br>
> above can be a pain. While there will have to be testing and such for<br>
> third party hardware, the business will release "official" hardware that<br>
> will obviously be tested with the XiniX distro so that these issues<br>
> won't be a factor as often.<br>
<br>
</div>Do you have any idea how _much_ third party hardware there is out there?<br>
<div class="im"><br>
> > 4. A better, more logical division of the system and user for various<br>
> > reasons.<br>
><br>
> Um, like Apple did with macosx? Like that /usr->/usr/bin move? Like<br>
> gobolinux where they just went "screw it" and moved everything for no<br>
> apparent reason?<br>
><br>
><br>
> Yeah something like that. :) For example XiniX actually doesn't have a<br>
> /usr directory at all, but instead software is considered "system"<br>
> (which will be added to the firmware /bin, /sbin), "personal" (~/.bin,<br>
> ~/.sbin), or "community" (/home/public/.bin, /home/public/.sbin). This<br>
> is done, again, to separate the system from the user/userbase and is<br>
> necessary for some of the design goals. There are a few other<br>
> non-traditional aspects of the system too.<br>
<br>
</div>Apple got away with it because they're apple. Fedora is trying to make a<br>
very minimal change in a backwards compatible way. You're adding<br>
_hidden_ executable directories... I really don't see that ending well.<br>
<div class="im"><br>
> > While those are just a handful of ideas behind the distro, I'm not<br>
> sure<br>
> > if that's what you were looking for. Currently the distro (named<br>
> XiniX<br>
> > - pronounced "zen ics") uses busybox, but I'd love to replace it with<br>
> > toybox once the required binaries are incorporated.<br>
><br>
> I'm all for it...<br>
><br>
><br>
> Great! I'll keep my eye on the development and incorporate it as soon<br>
> as I can!<br>
<br>
</div>I'm working on it. Got a bit mugged by real life again...<br>
<div class="im"><br>
> That's pretty much where I stop. I provide a basic tool, what people do<br>
> with it from there I'm intentionally agnostic about because there are a<br>
> more use cases for a knife than for nail clippers and vegetable peelers<br>
> combined.<br>
><br>
> That simple system would be ideal for a VM server though, don't you<br>
> think? After all, that system should *not* contain anything but the<br>
> necessities to boot and run whatever, more complex systems via VM's right?<br>
<br>
</div>Sure. I'm always happy when people find a use for the tools I provide,<br>
but I'm trying hard to stay agnostic about what use those tools might be<br>
put to.<br>
<br>
I'll happily respond to "I need it to do X because Y", that's great<br>
feedback. But "my hammer keeps scratching the surfaces I'm pounding<br>
dents out of" means I say "here's how you can wrap some cloth around it,<br>
and some example cloth", not "from now on it will come wrapped in cloth<br>
by default".<br>
<div class="im"><br>
> So are you trying to accomplish the goal of developing an SDK with<br>
> aboriginal Linux? What are your goals and intended audience with that<br>
> distro?<br>
<br>
</div>See above. "Make cross compiling go away."<br>
<br>
Note that cross compiling includes "building a uClibc system under a<br>
glibc system", and next up a musl system. (Assembling a toolchain in<br>
general is hard and fiddly.)<br>
<div class="im"><br>
> Rob<br>
> --<br>
> GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.<br>
> Either it's "mere aggregation", or a license violation. Pick one.<br>
><br>
><br>
> Looking at your signature, it reminded me of another questions I wanted<br>
> to ask you. If I were to guess, I'd say that you were more of a GPLv2<br>
> guy. Having said that, and I know this could take up pages worth of<br>
> information, but as an overview why the dislike for the GPLv3? Perhaps<br>
> 'dislike' isn't the right word, but I'm sure you understand what I'm asking.<br>
<br>
</div>I need to finish writing up my thing on that. I've got a long file full<br>
of notes...<br>
<div class="im"><br>
> As always, thanks for your time!<br>
> Dave<br>
<br>
</div>Sorry I'm so far behind. I need to amend the kernel MAINTAINERS file to<br>
exclude the device trees subdirectory, but I've been holding off until I<br>
get the PGP signatures to reestablish <a href="http://kernel.org" target="_blank">kernel.org</a> access so I can put a<br>
git tree up there I can submit stuff through, and sometimes "I refuse to<br>
fix this until I do it RIGHT" can lead to piles of side effects imposed<br>
upon oneself as a weird sort of peanance. My inbox is like that right now.<br>
<div class="HOEnZb"><div class="h5"><br>
Rob<br>
--<br>
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.<br>
Either it's "mere aggregation", or a license violation. Pick one.<br>
</div></div></blockquote></div><br>