Pandora should leave Angstrom

[Kaepora Gaebora]

Bring us another OS, so I can ignore it for the most part. Well untill it gets polished and backed...

 

[laurencevde]

A pretty complete linux-install DOES fit in the NAND, so there's no reason not to. Requiring the use of an SD-card, even for basic usage, just complicates matters:


First of all, a run-of-the-mill sd-card will feel quite slow when used for os-purposes. The best choice is a sandisk extreme. Pretty much every other card I know of is quite a bit slower. €15,- for an 8GB. But I bought my Pandora 2.5 and am currently completely out of money (oh and it's a recession, so I'm not the only one)...


Result: one should either be included, or Pandora's front-page should include a line like "for the best user-experience, we strongly suggest users to use a linux-formatted Sandisk Extreme (also named Extreme III or Extreme HD video) in their Pandora".


Secondly, if used for the OS, the sd-card MUST be formatted with a filesystem that supports POSIX's filesystem-permissions, but many Pandora-users will be using Windows on their desktop, that can't handle such cards, and it'll also pretty much limit those cards to the Pandora.


This means that it must be VERY, VERY clear to users that they need to provide an SD-card JUST for the Pandora. No, NOT that card that you still have floating around that may have important data on it...


Thirdly, the Pandora pretty much must have a recovery-image sitting on the NAND, but as the main OS will probably quickly outgrow the NAND (why else are you doing this?), its image can't be on the NAND, and must either be provided on a second SD-card, a pre-formatted SD-card with 2+ partitions, or downloaded over WIFI. That third option is definitely preferred, but requires giving that recovery-image networking-capabilities, including wifi-configuration. But the usable wifi-configurators require a GUI, including toolkit etc, and you'll probably want to include stuff like gparted, filesystem-checkers, a webbrowser etc. you are now pretty much approaching a more-or-less complete linux install again... And you now have 2 OS's to maintain...


I agree, ängstrom isn't that great of a distro, but requiring the use of an SD-card is even worse...


Now, IF someone manages to install arch, gentoo or whatever to the NAND, we could just give it a "install to SD-card" option and be done with it...

 

[sebt3]

ängstrom isn't that great of a distro

If you forget that :


- it have been the *only* handheld distribution for over 5 years (I just dont want to say 10 as I'm unsure)


- it have always been the core of linux handheld community (linux on ipaq, remember anyone ?) with deep connection with community like linux-arm and such


- it's more or less a fork of debian (at least it have some common roots/tools) with the fat removed


than yeah I agree it's a messy distrib

 

[laurencevde]

Age doesn't make it a great distro. for starters, it's very basic, and its repository is minimal.


Oh, and it's built using OpenEmbedded, whose BitBake-recipes could be Gentoo ebuilds...

 

[TrashyMG]

It has a Linux kernel and a command line interface and a semi-decent graphic interface... what else do you guys need?


Although what I call a working operating system may be a bit lower than what you guys are used to.. I spent all of yesterday working on a 30 year old test system running on a DEC VAX/VMS system..

 

[Kaepora Gaebora]

I spent all of yesterday working on a 30 year old test system running on a DEC VAX/VMS system..

so you dick around all day or you needed to do that for work?

 

[Linux-SWAT]

Angstrom is fine for the NAND. It does the job. Just need some updates.


It boots Xfce (PC) or minimenu (phone), and if we want more software, some videos, music, we add a SD (keeping one free SD slot).


So the SD is mandatory, in a "normal user" point of view.


BTW, my Slackware port is almost complete, from a system point of view.


For user goodies, i already have a bunch of packages i compiled natively on OP (5 full days). I also tested some .pnd.


http://boards.openpa...post__p__130234


EvilDragon, i PM'd you a message about it.

 

[TrashyMG]

I spent all of yesterday working on a 30 year old test system running on a DEC VAX/VMS system..

so you dick around all day or you needed to do that for work?

This was at work, I was called in to diagnose a problem with it.. It hasn't been powered up in 8 years and most of the support hasn't touched it in 10 years.. I can read manuals so I became the expert on it.

 

[ShleeDragon]

The 512MB NAND is more than enough to store the uboot/rootfs/kernel/userland/Xorg/WM and a whole bunch of applications. The real problem is getting everything working smoothly out of the box, which considering the fact we've already got a bunch of smart people tweaking the angstorm OS, I doubt much will change for them... people complain about angstrom being outdated because they keep all of their code in house and manually apply patches downstream. Arch/archarm is an OS build around the bleeding edge source with as little modifications as required.


My arguement is using archlinux-arm and it's pacman repo as the core of the base NAND OS. The base/core can be made to include all of the default packages required for a booting the kernel/userspace.


Xorg/desktops/pnd managers can be maintained in another extra repo. All of the confirmed community/third party code can be packaged up into a third repo. PNDs would still work as is and nothing needs to change about those..


Arch offers the following: Turn on Pandora, run the pacman update command (pacman -Syu) and the pandora would update all of the core/extra/community packages. Every single Pandora is on the same baseline due to the rolling release style updates.


and ANOTHER issue is; using the current zexxon/superzexxon firmware release style... each major release will likely break packages built and tested on each release. Having a single rolling OS would hopefully remove this problem with duality of OS versions. If something breaks, it breaks for everybody - letting us figure out the issue and resolve it for everybody.


Quality control: The core/extra repo would be managed by the core team and would be tested heavily before being pushed live + you can rollback changes. The PND developers would keep doing their thing... wouldn't effect them in the slightiest.


This will hopefully lead to less bugs/problems with OS and third party releases.


bonus: If you're compiling source, these packages can be installed seperately/easily.


Update: I'm trying to remove fanboy hyperbole from this - Discussion is a good thing.


Slackware is a step in my direction, but that distro has a few "papercuts" which archlinux wouldn't inflict on us.. eg: archlinux has dependancy checks on pacman/rolling release/easier to maintain for the newbie.


I wouldn't recommend the slackware (or most linux) package management systems on my worse enemy, unless their a sadist. (ok it's not really that bad.. but it's not pacman/AUR)

 

[slaeshjag]

Arch is unsuitable as they have no separate doc/dev packages, it's all included in one. That add quite a lot of stuff. Get all the libs and tools that's in the current firmware, but with Arch's package manager, and do it with less than 400 MB. You have the boot from SD option, so go for it. All PNDs should also work in the enviroment you set up.


If you can do it, well, then people will take you more seriously. But I don't see the point in moving away from Ångström. It does the job and when the overlay is set up right, it'll be possible to keep the firmware up-to-date in the long run.


The current firmware uses something like 340 MB iirc.


And I haven't even looked into if Arch provides armv7 optimized packages. That would be a base requirement to even consider it imo.

 

[ShleeDragon]

Remember, we're talking arch-arm.. not the default arch


Do we currently use Glibc or uClibc?


Secondly, we would be able to compile every single package for the pandora. Everything would be compiled for the Pandora, so less bloat. If we want a slim public version and a fat debug version, that's really easy to do.

 

[slaeshjag]

Remember, we're talking arch-arm.. not the default arch


Secondly, we would be able to compile every single package for the pandora. Everything would be compiled for the Pandora, so less bloat. If we want a slim public version and a fat debug version, that's really easy to do.

Okay, show it. Don't expect anyone to do it for you. If you want to make a point here, you got to do it yourself. If you can produce a NAND-flashable version of Arch which has complete compatibility with the current PND's (well, good enough for anyone to consider using it anyway,) is easier to maintain than Ångström and doesn't break all the time (like Arch used to do for me, mumble muble), then I can see a trasition happening. But just talking about it won't make it happen.

 

[ShleeDragon]

Remember, we're talking arch-arm.. not the default arch


Secondly, we would be able to compile every single package for the pandora. Everything would be compiled for the Pandora, so less bloat. If we want a slim public version and a fat debug version, that's really easy to do.

Okay, show it. Don't expect anyone to do it for you. If you want to make a point here, you got to do it yourself. If you can produce a NAND-flashable version of Arch which has complete compatibility with the current PND's (well, good enough for anyone to consider using it anyway,) is easier to maintain than Ångström and doesn't break all the time (like Arch used to do for me, mumble muble), then I can see a trasition happening. But just talking about it won't make it happen.

Agreed, I haven't got a Pandora yet but half of this was already completed.


I'll put my money where my mouth is once I get a Pandora.. I'll help anyone willing to work on this project

 

[kaprikawn]

Glad to see you're willing to contribute. There's plenty of people bashing on Angstrom (I don't like it either for the record), but I don't see anyone stepping up to help Notaz.


Personally I would love to help, but alas my knowledge is not up to standard. So I'm currently trying to up my Linux IQ by installing and messing around with the likes of Gentoo and LFS (Linux From Scratch) on x86 with the hope of getting to the point where I can transfer over to the Pandora and do some stuff on there.

 

[ibisum]

What I think is more needed is a proper means for contributors to get involved in the current builds of Angstrom. If we had a common build server, with trusted developers able to contribute (and get builds from the server, continuous-integration style), it would really help Notaz out, I think. Time and again I've wished to participate, but the hassle and fuss of getting an OE build setup working, getting all the patches applied, sync'ing with the other hackers on the OP kernel project, and so on just makes it more difficult than it should be.


I know, I've harped on this enough in the past to warrant being called a dilettante on this issue, but the fact is that if there were just a little more leeway on being able to build a full, stock image, with all patches and tweaks as are available in the customer-releases, then I'd help out a bit more. As it stands, I don't want to have to maintain my own tree - I'd be quite a bit more happy to have a build server out there, watching my repo for checkins, which then delivers a working SD image that can be used for testing.


Also, the Angstrom repo situation.

 

[pmprog]

I know, I've harped on this enough in the past to warrant being called a dilettante on this issue, but the fact is that if there were just a little more leeway on being able to build a full, stock image, with all patches and tweaks as are available in the customer-releases, then I'd help out a bit more. As it stands, I don't want to have to maintain my own tree - I'd be quite a bit more happy to have a build server out there, watching my repo for checkins, which then delivers a working SD image that can be used for testing.

Either that or get something like sebt3's VM but for the firmware, where it's basically all set up, and there's some menus/scripts to download the latest version from git, compile and produce an SD image or whatnot.

 

[ivanovic]

My arguement is using archlinux-arm and it's pacman repo as the core of the base NAND OS. The base/core can be made to include all of the default packages required for a booting the kernel/userspace.


Xorg/desktops/pnd managers can be maintained in another extra repo. All of the confirmed community/third party code can be packaged up into a third repo. PNDs would still work as is and nothing needs to change about those..

Slightly wrong assumption there. The "problem" with pnds is that the binaries built there are built against the OS version of libs like libSDL, libjpeg, libpng and stuff like this. Now the problem here is that, with a non static OS you'd have to basically statically link the pnds to make sure that they also run in say 3 days when a libjpeg update is rolled out. Yes, this can easily happen and is a reason why a static OS makes sense for a system like the pandora. With the libpnd system is is possible to define a "minimum OS version" (okay, in theory it is possible) so you can somehow work with the static releases which are only updated every X month in some "more serious" way. This would no longer be possible with a rolling release distribution. Yes, for desktop systems where *everything* is only installed from software repositories and where you have more than enough space for "legacy support libs" this is no issue at all and why I love rolling release distributions for a normal case, but the pandora is no normal desktop/laptop system.


Besides wifi sucks for many users so updating the OS via wifi will take ages and is not a good option to keep the system up to date. The problem when only using the package manager to update everything simply is that you'd have to rely on the pandora provided networking, which is flacky for some users and "just slow" for many.

 

[laurencevde]

Breaking libs is trivially solved by just keeping the old libs around (well, almost trivial, as some libs don't like it when you load multiple versions of them in the same process, which can happen if a library you depend on loads in a different version of some lib than you do...)


So yes, if we switch to another distro, or upgrade angstrom, we must keep current angstrom's libs around somewhere.

 

[mcobit]

Breaking libs is trivially solved by just keeping the old libs around (well, almost trivial, as some libs don't like it when you load multiple versions of them in the same process, which can happen if a library you depend on loads in a different version of some lib than you do...)

So yes, if we switch to another distro, or upgrade angstrom, we must keep current angstrom's libs around somewhere.

It is about size restriction. Please read the rest of the topic.

 

[laurencevde]

Most actual libs (the .so's) (especially the ones without BC) aren't that big, and many versions of the same lib can fit on the NAND. Besides, it's only for PND-backwards-compatibility, so they could also be put on the same SD-card as the PND's. Libpnd can be made to detect needed old libs and download them.


Providing the old libs in some way is a requirement if we ever upgrade the OS, as PND's will break if we don't.