[Aboriginal] Fwd: greetings!
dhenderson at digital-pipe.com
Thu Jul 26 06:17:14 PDT 2012
This email thread has started to become soup! So... I'll start a new
paragraph so we can start over. :)
Going back to the software included in the "firmware", the list should be
very small and only allow the device to get to the point for user
interaction. For example,
- busybox (later toybox) for core functionality including user management,
- clAPI (our own software)
- the appropriate mount binaries for ext, ntfs, nfs, and smb/cifs
- ssl (for secured headless devices or other communication)
- ssmtp (or similar) for automated outbound communication of device
* optional alsa (for sound enabled devices)
* optional graphics software for headed devices (headless will already be
handled via clAPI)
Items such as mplayer, samba, rdesktop, okular, perl, rsync, etc will be
outside the scope of the "firmware" because they aren't required to turn on
a device, login, and get to either the prompt or blank desktop (GUI). The
list above should enable a device to communicate/interact with other
devices on the most basic level, but nothing beyond.
Because the "firmware" is kept to an absolute minimum, I think any library
API changes will not really disrupt the device from working.
Regarding the musl switch over, I had no clue that uClibc has been shelved
for so long! Why wouldn't the switch to musl be more critical? Not only
would you get actively developed software, but the speed increases as shown
in one of the links below.
I can see your point about standardization in the qwerty keyboard example
provided, however, because of how Linux has evolved compared to the design
goals of the XiniX distro, it's easier to manage the OS by separating it as
I have. Otherwise, there would be an unwieldy amount of mounts to maintain
with software and configs going in various places (e.g. /bin, /usr/bin,
/usr/local/bin, /usr/share, etc). The layout for XiniX is uniform and
makes sense where things are located and why.
Thanks for all the articles on the GPLv2 vs GPLv3 - lots of reading to do!
I'm sure I'll have more questions for you once I'm done. :)
On Wed, Jul 25, 2012 at 3:10 PM, Rob Landley <rob at landley.net> wrote:
> On 07/23/2012 07:41 AM, David Henderson wrote:
> > On Wed, Jul 18, 2012 at 10:09 PM, Rob Landley <rob at landley.net
> > > Their "work" would be anything the user normally does during
> > > day: email, word processing, listen to music, watch videos,
> > program,
> > > etc.
> > That's a full distro. As the presentation I mentioned covers, there
> > a lot of distros out there already, which maintain enormous package
> > repositories with dependency information and build recipes and
> > information and all that, and it's a full-time team of a dozen or
> > people for each distro.
> > Combined, you're right that is a full distro, however, XiniX is just the
> > "firmware" to get the user to the point where (s)he can do the "work",
> > but doesn't include the software to actually do the "work".
> That line turns out to be hard to draw, or at least I found it so.
> > Basically
> > our goal will be to create XiniX and a base set of weblications to
> > perform basic tasks - surfing the Internet, communication (email, IM,
> > IRC, etc), and office tasks (Word Processing, Spreadsheets, etc) as well
> > as some common "at home" tasks like watching movies, playing music,
> > etc.
> There's an old problem in computer science: users only use 20% of your
> app's features. But they can't agree on which 20%.
> > Programs outside of our "official" umbrella will be left to the
> > community to add to (and maintain) the software repositories.
> There are literally hundreds of linux distributions trying to do this
> already. Just this week I bumped into
> > > While the distro won't contain all of the software for
> > > everyones "work" (e.g. CAD users), it'll start with a set of
> > > software to perform the most common tasks. As time elapses,
> > > and more can be added to include users with more rare "work".
> > This
> > > software, however, will be installed with their "personal
> data" as
> > > mentioned below.
> > I found it to be a can of worms. Read the presentation for details.
> > Which aspect - adding software "on demand" or combining software as part
> > of the users "personal data"?
> Figuring out which software to include, and maintaining the build
> recipes when some library decides to change its API again and two
> different packages need different versions of glib and so on...
> > I got a gui running on the Qualcomm Hexagon natively built under
> > aboriginal by following the beyond linux from scratch instructions in
> > 2010. (Alas, the scripts I wrote to do it were written on company
> > and stayed with Qualcomm. I haven't gotten around to recreating open
> > source versions yet...)
> > What were you using as the graphics backend? X11, DirectFB, etc?
> The board didn't have a graphics card so we exported the display to
> other machines through the net. (We tried getting the vnc plugin of
> x.org running but there was some problem, possibly not enough memory? I
> forget. Might just have been not enough time.)
> > But I also mean to switch gradually over from uClibc to musl...
> > Looking over the comparison chart at
> > http://www.etalabs.net/compare_libcs.html, I can see that it looks like
> > the developer of musl shares your design and coding philosophies. How
> > long will the transition to musl take?
> No idea, but the real limiting factor (other than my shortage of time)
> is when ports to the architectures I want to support show up.
> uClibc has been stagnant for half a decade. It's unblocked a bit
> recently but it's still impossible to bisect a problem between two
> releases (trivial problem: they branch-then-tag. Bigger problem:
> interstitial versions don't even compile.)
> > > Yeah something like that. :) For example XiniX actually
> > > have a /usr directory at all, but instead software is
> > > "system" (which will be added to the firmware /bin, /sbin),
> > > "personal" (~/.bin, ~/.sbin), or "community"
> > > /home/public/.sbin). This is done, again, to separate the
> > > from the user/userbase and is necessary for some of the design
> > > goals. There are a few other non-traditional aspects of the
> > system too.
> > Sigh.
> > http://landley.net/writing/hackermonthly-issue022-pg33.pdf
> > Great article! I actually wondered where all those directories came
> > from. lol I know it sounds like I'm no better than the others in the
> > article that re-arrange the FS layout, but instead of having all these
> > symlinked directories and crazy list of mounts, wouldn't it make more
> > sense to just provide a common structure between the various aspects of
> > the system? To me, it also provides an easy way to store all user data
> > (personal and community) under a single mount (/home). For example:
> The qwerty keyboard layout is universally acknowledged to suck.
> Everybody can sit down at a qwerty keyboard and type on it.
> The value _is_ that it's standardized. Not that the standard makes
> sense. Thus the only way to get any sort of momentum behind an
> alternative is to have somebody like Apple or Google behind it, and to
> be consistent for about 5 years before anybody starts to care about the
> new layout.
> > There's a corollary to Moore's Law, which applies it to software. It
> > says that 50% of what you know is obsolete every 18 months.
> > I have a corollary to that corollary, which says "The great thing
> > Unix is it's the same 50% cycling out over and over." This is how it
> > gradually builds a userbase, because you can wander away from it for
> > 7, even 10 years and come back and still find your way around the
> > stuff (posix-2001 still more or less applies), whereas over in
> > windows-land they obsoleted Visual Basic and replaced it with .net,
> > then obsoleted .net (whatever that was, they were never quite clear)
> > favor of programming windows 8 in HTML5...
> > [google how microsoft lost the API war, by joel spolsky]
> > Joel's article was absolutely fascinating! Thanks for sharing it!
> The web not only has cool things on it now, it had cool things on it
> before now. :)
> > I've
> > actually been telling people about the transition into the webosphere
> > for many years now. That's actually why I see XiniX being valuable to
> > people and organizations!
> The "transition to the webosphere" is what Google's Chromebooks were
> trying to address, and they're still dinking at it:
> It's what html5 is targeting. HTML5 fragmentation is fun to watch:
> Even Windows 8 is requiring everything to be html5...
> > > Looking at your signature, it reminded me of another questions
> > > wanted to ask you. If I were to guess, I'd say that you were
> > > of a GPLv2 guy. Having said that, and I know this could take
> > > pages worth of information, but as an overview why the dislike
> > > the GPLv3? Perhaps 'dislike' isn't the right word, but I'm
> > sure you
> > > understand what I'm asking.
> > Heh.
> > Lemme do a separate email for that one.
> I keep writing up _bits_ of it in various places. I wrote up a couple
> facets of "why busybox shouldn't move to gplv3 only" back in 2006:
> The most recent two are here, talking about splitting the community and
> undermining the network effects we'd benefitted from:
> A quick search brought up a bunch of random blog entries that wing the
> topic in passing. I need to go through these too:
> I'm assembling a list of topics at
> http://landley.net/toybox/oldlicense.txt that I should cover in a once
> and for all writeup.
> (Oh, and
> is really good, even if he's on the other side.)
> > I'll be interested to read it! :)
> Above is the slush pile. (And not even the _entire_ slush pile.) I need
> to digest that into something manageable.
> > Dave
> > _______________________________________________
> > Aboriginal mailing list
> > Aboriginal at lists.landley.net
> > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net
> GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
> Either it's "mere aggregation", or a license violation. Pick one.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Aboriginal