Actions
Forum Thread Details
  • Replies 26 replies
  • Subscribers 59 subscribers
  • Views 2893 views
  • Users 0 members are here
Related

Angstrom

Former Member

Interesting discussion over on the beagleboard google group https://groups.google.com/forum/#!category-topic/beagleboard/kz3M-It3U5Y

 

Reading between the lines, you get the impression that angstrom was a one man show and that the CircuitCo employee who was that one man has now left for another company.

Exactly what that means for any boards currently using angstrom is as yet unclear.

 

However, if true that angstrom was effectively one person it may explain a lot of the issues people here have seen with it.  Unfortunately the risk is that if angstrom ends up effectively unmaintained, any boards using it as the default pre-installed distro could well get stuck in a dead-end.

 

The beagleboard folks have so far steadfastly stuck with angstrom in spite of the obvious problems, I think it'll be interesting to see what happens next.

  • in reply to morgaine

    Morgaine Dinova wrote:

    Anyway, back in Linux time, I think we can safely say that the Linux kernel is happy with any amount that one is likely to find on an ARM applications processor board.

    the kernel itself will run with very little, lots of those cheap wifi and adsl routers run linux and have as little as 8MB, of course the userspace component is hugely cut down and specialised compared to any regular distro.

  • in reply to morgaine

    Morgaine Dinova wrote:

    LFS qualifies!

    Sure, but then base LFS is quite restrictive, it gives you just about enough to be able to build other stuff, but isn't really anything you'd call useful... unless you enjoy compiling more stuff image

  • in reply to Former Member

    selsinork wrote:

     

    Sure, but then base LFS is quite restrictive, it gives you just about enough to be able to build other stuff, but isn't really anything you'd call useful... unless you enjoy compiling more stuff

    You mean that some people don't?  Sounds a bit hypothetical to me .... image

     

    To be serious for a moment, presumably LFS is being used as the basis of bottom-up O/S Engineering courses, as a more practical version of those that used to use Minix.  Knowing every detail of what goes on under the hood has awesome educational value, and there's no harm in using a platform for it that is practical as well.

     

    Morgaine.

  • in reply to morgaine

    Well yes, but to get much in the way of what most people would think of as useful you'll want to progress to the second book, Beyond-Linux-From-Scratch. That's where you'l, eventually, get to build a GUI environment, and it's not until something like chapter 14 of BLFS where you build a dhcp client. So for practical purposes, lots of people will get bored of it quickly.

     

    Yes, great educational value, but likely more useful if you know just enough to build some bits and pieces out of order.. useful stuff like dhcpcd, sshd and your editor of choice tend to make life a lot more plesant.

  • in reply to Former Member

    selsinork wrote:

     

    Well yes, but to get much in the way of what most people would think of as useful you'll want to progress to the second book, Beyond-Linux-From-Scratch. That's where you'll, eventually, get to build a GUI environment

     

    Isn't this conflating two different things?  On the one hand, evolving a target O/S about which one knows everything, and on the other hand using a development environment about which one may know little or nothing?  Those are two very different things, and they coincide only if the goal is not merely to learn everything about the operation of a target, but to bootstrap the development environment onto that target simultaneously --- a vastly more difficult proposition.

     

    What makes it extremely difficult (and also highly unpleasant) is that word "simultaneously".  It's no problem at all if the two things are not simultaneous, and they certainly don't have to be --- powerful development could migrate to the target only once the evolving target can support it.  Although some things are done the hard way on principle (like retro pastimes), the sensible engineering approach to LFS is to cross-build, not to painfully and slowly raise your development abilities from zero as your target slowly matures in capability.  Restricting development capabilities has no educational merit as long as the operation of the target is not hidden by the tools.  (Admittedly, some high-level IDEs do hide it.)

     

    Which brings me to your mention of the GUI environment.  There are some elements of graphical systems that have educational importance and need to be understood by proto-engineers who will one day be creating them.  The LFS approach to understanding systems does well to cover even graphic environments, but again, there is no need to sacrifice powerful tools just because the target does not yet support such abilities.  Cross-development avoids making sacrifices that are not educationally necessary.

     

    It's a bit like learning to drive or fly.  Just because we haven't yet completed our own driving or pilot training is no reason to avoid taking a taxi or flying to our holiday destination by jumbo jet.  In the context of LFS, the target and the development environment can be entirely separate, and educational productivity actually increases by avoiding hardships that are unnecessary to the educational process and interfere with the flow of learning.

     

    Morgaine.

  • in reply to morgaine

    Morgaine Dinova wrote:

     

      Cross-development avoids making sacrifices that are not educationally necessary.

     

    That's Cross-LFS you'll be wanting then image

     

    The whole suite of LFS stuff is quite comprehensive, covering both cross and native builds. There's different reasons for doing both and while you may get different things out of those two experiences, the methodology appears to be surprisingly similar.