Have a question about the Next-Gen BeagleBone? Ask it here!

For anyone else with one of these, see

https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/G_QjWvBNXvc

you'll probably want to go to http://circuitco.com/support/index.php?title=Updating_The_Software and get the latest software image (2013.05.3 as of now) before trying to do anything with opkg

you'll probably want to go to http://circuitco.com/support/index.php?title=Updating_The_Software and get the latest software image (2013.05.3 as of now) before trying to do anything with opkg

Something must have been wrong with the build.  Looks like they pulled it.  I can see it in the change history so you're not a liar

Brian Welsby wrote:

 

spent days / weeks trying to get things working on Angstrom only to find that packages are out of date, built for 3.2 kernel, have bits missing

All distros have that problem though. Once you reach a certain point, and that might be just 100 or so packages, it starts to become a real challenge to keep up to date with everything and to handle the interdependant forward and backward breaking changes. 

Generally out of date only matters if there's a security fix or new feature you require that's missing in the old version.

Something being built for an older kernel generally isn't an issue and can often be a good thing. 3.2 really isn't old enough to be a big issue here.  However, if you think having things built for the current kernel is good, then I encourage you to rebuild glibc against the 3.10 kernel (use the --enable-kernel=3.1.0 configure option). When you find a bug in 3.10 that causes you to have to revert to 3.9.x until the bug gets fixed you'll have all sorts of fun when you reboot.

Bits missing is a bigger issue, most often when something's been built without some necessary feature.  Building something from source because there's no package available is usually ok. Building something where a package exists just to enable a feature comes with a much more interesting set of problems.

I have no doubt that Angstrom's goals are different, and the BBB's version of Angstrom different yet again.  That's not the problem.

The problem is that whatever those goals are, they do not include the distro being maintained in working order by a maintainer.  Instead, it's unmaintained so that problems persist over long periods of time --- monitoring the IRC logs shows the same problems coming up again and again as beginners arrive and report their woes.  Quite often they're even ridiculed.  And no bug tracker means no bug tracking and no responsibility for quality.

Nor do those goals include the distro continually being expanded with more packages so that end users used to other distros have a good likelihood of finding their favorite packages ready to install so that getting work done is just minutes away.  Instead they have to port any missing applications themselves, because the maintainer's principle is "I do nothing, if you want something done then do it yourself."

Such "goals" are, to my mind, not the goals of a distro worth using.  I can fix pretty much any problem after decades in the *nix world.  But why should I have to?

Because of the lack of bug tracking and responsible maintenance, the same problems are being fixed by thousands of users in parallel as they discover them, and then fixed again for each new image that they download and write.  What a total waste of everyone's time.

Every identified problem deserves a proposed solution, so here are my recommendations to Jason Kridner.  Since Angstrom is not just a hobby distro but part of commercial products and the quality of the supplied operating system impacts on Beagleboard.org and TI, do the following:

• Appoint a second maintainer in addition to the existing one.
• Make the new maintainer's first responsibility to implement a bug tracker.
• Make the new maintainer's second responsibility to implement an automated continuous build system.
• Make the new maintainer's ongoing responsibility to raise the quality of the distro by 1) fixing bugs caught by the continuous build system, 2) fixing bugs in order of priority on the tracker, and 3) adding packages identified as missing and/or requested on the tracker.
• Proactively add items to the bug tracker based on problems reported on the mailing list and on IRC.

I guess it's obvious enough, but sometimes even obvious solutions need stating.

I don't disagree with what you are saying, all I want is the basic kernel and the tools to build what I need.

As an example, I was trying to get Qt working...  On the BBB just install the Qt tools and you get Error required kernel 3.2.0 so check the BBB forums and the response there is that as opengl-es isn't yet available for kernel 3.18 you can't have it  so install with --force-depends and most of it will work. Ok so far so good but missing some functionality..  so I thought what about using Qtcreator on desktop and cross compile / develop Qt on desktop as per excellent tutorials on Derek Malloys site (written for BBW) you can download the toolchain etc etc but when you go to the Angstom site to get the toolchain you see the ones with qte were produced in 2011 and are Qt v4.6.1.

I thought I would see about bringing this up to v4.8.x but first of all try to build the tool chain as is.   I installed all the Angstrom build system, rebuilt the kernel etc all worked so then tried the bitbake recipe to build the qte toolchain. it started the process, got so far then error saying it couldn't find the compiler???  turns out it was looking for a different cross compiler to the one the system had built / installed so that then means getting into all the recipes understanding all the bitbake system etc etc..... just too much. It looks like I was using parts of the system that was created in 2011 with the current build system that has been put together for the 3.18 kernel development so even though the recipes are there they are no longer compatible.

On Debian I just install the Qt4 sdk and "everything" is there including qtcreator, and the demos and examples I installed xorg and fluxbox as the window manager and I had an application up and running within minutes. I downloaded the Qt serial port addon and it compiled installed and tested working. 

I have also installed on my BBB the software for my 3D printer I am building and yet again it just works.

If I want to use Java, Python, Perl, PHP, Ada, Fortran, or whatever I am confident that with Debian I can, with Angstrom I expect many issues.

In effect, you're saying that the distro is unmaintained and so its problems are revealed continually by users as they try to get work done, instead of being caught and revealed by an automated continuous build system.

That's a substantially shorter statement of the problem.

Morgaine Dinova wrote:

 

In effect, you're saying that the distro is unmaintained and so its problems are revealed continually as users try to work with it instead of being revealed by an automated continuous build system.

 

That's a substantially shorter statement of the problem.

Yes

Brian Welsby wrote:

 

Yes

I've added it to my list of recommendations as the new maintainer's "second responsibility".

Unfortunately the probability of Jason looking here is rather small, and this being a catch-all thread, all this will soon submerge without trace.  Even if seen, the likelihood of these concerns being shared is unknown and probably low, and the likelihood of change even lower.

Morgaine Dinova wrote:

 

Such "goals" are, to my mind, not the goals of a distro worth using.

I don't disagree, but you can't deny that if those really are their goals then they're doing well at meeting them

I would disagree with your other post though. Having just one additional maintainer isn't enough, it needs a team of people who are interested and will actively contribute. If the current maintainer is blocking the process then it's probably time to remove the roadblock.  The project as a whole won't survive on the shoulders of just one or two people, a distro is too big for that.

Yes there needs to be a public bug tracker, a mailing list, up to date documentation, and the full build system needs to be in a public git tree somewhere so that if the existing maintainers disappear or become roadblocks then others can fork the whole thing without a ground-up rebuild.

Brian Welsby wrote:

 

On the BBB just install the Qt tools and you get Error required kernel 3.2.0 so check the BBB forums

From what I can tell that error is from opkg.. Leaving aside the opengl-es part for a moment, you're looking at crap dependencies in the packaging here.  I'll say nothing more than that IMHO any distro that does dependencies in the packages is fundamentally broken as they all consistently make a mess of them.

The opengl-es part is always going to be problematic as you're off into GPU territory. We know the shiny new DRM/KMS driver for the BBB has issues, so it follows that things relying on it will too.  I really wish all of the embedded systems would just give up on the -es front and just use the normal OpenGL. My reason is fairly simple, using the normal one means you have far more help available from others in the community who wouldn't otherwise care about the -es side.

From my side, the whole angstrom build system with cross compilers and such like is a waste of time. I'd much prefer to be getting an app compiled than trying to debug why the toolchain can't find it's compiler. As such I strongly support the debian ideal of building everything natively.

If I want to use Java, Python, Perl, PHP, Ada, Fortran, or whatever I am confident that with Debian I can, with Angstrom I expect many issues.

In a lot of ways I'd argue that I don't want a lot of those on an embedded system at all.  I've come to expect issues with angstrom no matter what I try to do

Unfortunately angstrom remains useful as it'll be the place kernel fixes get developed and tested first.

Morgaine Dinova wrote:

 

That's a substantially shorter statement of the problem.

Can't we just go with "angstrom is $%!te" ?

Morgaine Dinova wrote:

 

That's a substantially shorter statement of the problem.

Can't we just go with "angstrom is $%!te" ?

selsinork wrote:

 

Can't we just go with "angstrom is $%!te" ?

That certainly hits the sweet spot for being concise.   But Jason's a good guy and deserves a bit more to work with.

I agree with your earlier point that just two maintainers probably would not be enough given the workload, but it would at least be a start.  What's most missing currently though is the will to maintain the distro and to work directly towards raising its quality.  In fact, I think it's fair to say that the aim is to avoid any distro maintenance whatsoever, as a matter of policy, so it's no surprise that its present quality is quite poor.

Morgaine Dinova wrote:

most missing currently though is the will to maintain the distro

and I do believe that trying to maintain a full distro on your own is likely to destroy any will that existed, quite quickly too.

I'm confused though, all the other bits like bonescript that seem to be done by Jason himself don't appear to have any particular reliance on angstrom. I can't think of a reason you couldn't layer them on top of debian, gentoo, or something else that would relieve the pressure of having to maintain a full distro yourself.

Which leaves it as a conscious choice to persist with angstrom and it's problems. I have difficulty understanding a choice like that.

selsinork wrote:

 

I'm confused though, all the other bits like bonescript that seem to be done by Jason himself don't appear to have any particular reliance on angstrom. I can't think of a reason you couldn't layer them on top of debian, gentoo, or something else that would relieve the pressure of having to maintain a full distro yourself.

 

Which leaves it as a conscious choice to persist with angstrom and its problems. I have difficulty understanding a choice like that.

According to my recollection, Ångström was the first OS to run on BeagleBoard and at the time beagleboard.org had minimal involvement with software and was happy to get help from anywhere.  I used Ångström quite a bit as a generic GNU/Linux OS, and it worked fine for my modest OS needs.  My understanding is that Ångström runs well with less memory than larger distros like Debian, which was important with only 128KB 128MB of DRAM on the original BeagleBoard.  Debian runs fine on a 256KB 256MB RasPi so Beagle might as well switch over.  IMO the key question is which OS is best supported on each platform, and that depends on the individual interests of OS maintainers.

Edit: oops

John Beetem wrote:

 

My understanding is that Ångström runs well with less memory than larger distros like Debian,

absolutely agree, angstrom seems to have cut out a lot of the bloat of the bigger distros, but that does come at a price.

which was important with only 128KB of DRAM on the original BeagleBoard. 

KB ?  Can I borrow your time-warp machine John ? 

IMO the key question is which OS is best supported on each platform, and that depends on the individual interests of OS maintainers.

Well yes, but given that for generic linux the real differences are all in the kernel... much easier to build a kernel that you can sit debian on top of than trying to re-invent debian

selsinork wrote:

 

I'm confused though, all the other bits like bonescript that seem to be done by Jason himself don't appear to have any particular reliance on angstrom. I can't think of a reason you couldn't layer them on top of debian, gentoo, or something else that would relieve the pressure of having to maintain a full distro yourself.

 

Which leaves it as a conscious choice to persist with angstrom and it's problems. I have difficulty understanding a choice like that.

A combination of history and no desire to alienate old acquaintances, I suspect.

Plus the fact that the immediate out-of-the-box experience with BBB tethered to a PC through USB is completely fault-free, which Jason may feel is good enough for PR purposes.  It's only later that problems appear, and unfortunately don't appear to stop.  It's entirely possible that Jason doesn't even use BBB outside of the USB tethered mode.

I agree entirely though.  BBB and the rest of the Beagle boards don't need their own distro at all, they just need their own kernel and a few special utilities at this time, and once DT stabilizes, not even that.  Moving over to Debian would be a solid move.  (I don't have any investment in Debian, I just recognize it as the "distro franca" of the Linux world.)

Morgaine Dinova wrote:

 

 

I agree entirely though.  BBB and the rest of the Beagle boards don't need their own distro at all, they just need their own kernel and a few special utilities at this time, and once DT stabilizes, not even that.  Moving over to Debian would be a solid move.  (I don't have any investment in Debian, I just recognize it as the "distro franca" of the Linux world.)

Well at the end of the day if Ti / Circuitco want to stick with Angstrom then so be it,  the good thing is we are not forced to use it we have choice.  

Judging by the posts in the Beagleboard forums a lot of users are on Debian  and Ubuntu rather than Angstrom.

Perhaps we should we have a system like  R-Pi  NOOBS where we can easily select what distro to install 

Morgaine Dinova wrote:

 

Plus the fact that the immediate out-of-the-box experience with BBB tethered to a PC through USB is completely fault-free,

I actually think that's a huge plus point for the BBB. It did take a bit of explaining to the folks at work though as the concept is a bit alien when you're used to the RPi.

Brian Welsby wrote:

 

Judging by the posts in the Beagleboard forums a lot of users are on Debian  and Ubuntu rather than Angstrom.

That should probably be a good indication to them that a change to the default could be a good idea.

selsinork wrote:

 

Morgaine Dinova wrote:

 

Plus the fact that the immediate out-of-the-box experience with BBB tethered to a PC through USB is completely fault-free,

I actually think that's a huge plus point for the BBB. It did take a bit of explaining to the folks at work though as the concept is a bit alien when you're used to the RPi.

I use BeagleBone White with USB for terminal connection and Ethernet for X Windows.  For me it's natural, because I learned X Windows development back around 1990.  But to a newcomer X Windows seems completely backwards -- the remote device is the client and the screen you're looking at locally is the server.  As with many engineering concepts, it doesn't make sense until you learn how it works internally so that you can pretend to be the remote device and imagine the packets flying back and forth across the link.