Actions
Forum Thread Details
  • Replies 26 replies
  • Subscribers 59 subscribers
  • Views 2886 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.

Parents

  • Probably about as close as an official response you're likely to get from Jason in this thread:

    https://groups.google.com/forum/#!category-topic/beagleboard/GK8Chte-4Xs

     

    I don't think there's any huge surprise that his requirements seem to come down to bonescript, capemgr and dtbo's for known capes on top of <insert OS here>.

    What I find interesting is that they're prepared to discuss a move, have sensible requirements before doing so, and have obviously been doing some work around getting a version of Debian to that point already. I'd not seen anything suggesting it would even be open for discussion previously.

  • in reply to Former Member

    selsinork wrote:

     

    Probably about as close as an official response you're likely to get from Jason in this thread:

    https://groups.google.com/forum/#!category-topic/beagleboard/GK8Chte-4Xs

     

    I don't think there's any huge surprise that his requirements seem to come down to bonescript, capemgr and dtbo's for known capes on top of <insert OS here>.

    What I find interesting is that they're prepared to discuss a move, have sensible requirements before doing so, and have obviously been doing some work around getting a version of Debian to that point already. I'd not seen anything suggesting it would even be open for discussion previously.

    That's good news on Debian.  I'll be looking forward to it -- I wonder if it can run decently on a 128MB BeagleBoard B4?

  • in reply to johnbeetem

    John Beetem wrote:

     

    I wonder if it can run decently on a 128MB BeagleBoard B4?

    I wouldn't like to guess.  In the end, base requirements will continue to rise, pushed ever upwards by x86 systems that will reasonably have terabyte drives and 8-16Gb ram. Trying to push an OS designed with easy availability of resources onto an Arm board that more closely resembles where x86 was a decade or more ago can't be the easiest of things to do.

    I'm not convinced Debian is the best choice for an embedded board, but then I don't really have a better idea. Debian does have the advantage of having a much bigger pool of active developers than we could hope for on a beagle* only distro. 

  • in reply to johnbeetem

    John Beetem wrote:

     

    That's good news on Debian.  I'll be looking forward to it -- I wonder if it can run decently on a 128MB BeagleBoard B4?

     

    I've run Linux in 16MB of RAM and it's known to run in a lot less than that, so the answer is undoubtedly "yes" as far as the kernel is concerned.  Although the kernel codebase has grown massively over the years, it's so modular that tiny kernels can still be configured.

     

    On the user-space side, to make a distro fit a small embedded board just requires disabling superfluous subsystems, of which there are typically vast numbers in any modern distro.  I doubt that 128MB represents a serious constraint at all for an embedded environment.  This even applies to desktops, but there it's subject to personal expectations of what needs to be present.  Some people require not only the kitchen sink to be running, but 5 of them simultaneously.

     

    Morgaine.

Reply
  • in reply to johnbeetem

    John Beetem wrote:

     

    That's good news on Debian.  I'll be looking forward to it -- I wonder if it can run decently on a 128MB BeagleBoard B4?

     

    I've run Linux in 16MB of RAM and it's known to run in a lot less than that, so the answer is undoubtedly "yes" as far as the kernel is concerned.  Although the kernel codebase has grown massively over the years, it's so modular that tiny kernels can still be configured.

     

    On the user-space side, to make a distro fit a small embedded board just requires disabling superfluous subsystems, of which there are typically vast numbers in any modern distro.  I doubt that 128MB represents a serious constraint at all for an embedded environment.  This even applies to desktops, but there it's subject to personal expectations of what needs to be present.  Some people require not only the kitchen sink to be running, but 5 of them simultaneously.

     

    Morgaine.

Children
  • in reply to morgaine

    Morgaine Dinova wrote:

     

    I've run Linux in 16MB of RAM and it's known to run in a lot less than that, so the answer is undoubtedly "yes" as far as the kernel is concerned.  Although the kernel codebase has grown massively over the years, it's so modular that tiny kernels can still be configured.

    I first used Unix on a 256KB PDP-11/45, with multiple users.  If two people compiled at the same time it would slow down a bit, but normally people were editing (using ed, natürlich) so the PDP-11/45 could support quite a few users.

     

    While a 128MB BeagleBone is physically small, I like to think of it as a small mainframe and bloat-free software runs quite well.

  • in reply to johnbeetem

    John Beetem wrote:

     

    I first used Unix on a 256KB PDP-11/45, with multiple users.

    ...

    While a 128MB BeagleBone is physically small, I like to think of it as a small mainframe

    Ah, the reminiscing. image

     

    Well a PDP-11/45 almost was a mainframe, compared to its younger sibling PDP-11/34 on which I first ran Unix V6 and V7 (and something called "mini-Unix" prior to V6).  Unfortunately I can't remember how much RAM it had, but the likelihood is less than your 11/45.  We didn't have a lot of money ...

     

    I never had a chance to bring up Unix on our 11/20, as it got upgraded to the 11/34 at the same time as I was discovering the joys of "ls -l" and "cc -c" on another department's larger PDPs, but it probably had even less memory and was still known to run Unix.

     

    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.

     

    Morgaine.

  • in reply to johnbeetem

    John Beetem wrote:

    and bloat-free software runs quite well.

    good luck finding anything bloat-free these days image

  • in reply to Former Member

    selsinork wrote:

     

    good luck finding anything bloat-free these days

     

    LFS qualifies!

     

    Being required to know what each piece does puts a very severe cap on bloat. image

     

    Morgaine.

  • 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.