saponga | # 461 | 2013-06-20, 20:23 | Report

i've just got arch working on my eeepc 701 and i'm in love with it ! t boots within 10 secs or so... i think i'll give a shot on my n900. Thanks a lot for give us the rocks way.

Skry | # 462 | 2013-06-20, 20:47 | Report

I'll try to put up a new rootfs this weekend.

Älä hakkaa | # 463 | 2013-06-20, 21:05 | Report

It's the most complete and free mobile available. Someone should tell Richard Stallman. And it makes for a great Raspberry Pi alternative. I just ordered a second n900!

Skry | # 464 | 2013-06-21, 14:28 | Report

btw guys, since you've the one using this, what do you think?

- Should we default to 2.6.37 kernel? This way we would have working hardware at least. 3.x kernels could be offered as packages to install separately.

- I'm really, really busy nowadays. I don't have time to maintain additional packages, many of them requiring patching and constant recompiling. So, I can concentrate on the system core, but would there be people ready to maintain extra packages?

- There are many things in both Arch and Arch Linux ARM nowadays that I don't like. One of them is the fact that NEON optimizations are not used anywhere. How about if we take Arch base, rebuild it with optimized settings, and define some baseline which we would maintain together and offer as separate repository, also compiled with optimized settings. In addition to that, we could use Alarm repos but keep it lower on priority. This would pretty much make this an Arch Linux spin. This would make everything easier to maintain, in theory at least, we could do something like monthly rebasing to Arch base with our own repositories, so everything wont blow up when something is updated on official repos. Security updates would be priorized separately ofc.

- Relating to the above, I was thinking about something that focuses on Wayland and Enlightenment. Also, everything neon/thumb compiled for cortex-a8, and EGL/GLES support enabled where available.

- For all this, I would need/want beaglebone black or similar as a distcc master, and possibly people participating as distcc slaves. If someone wants to donate hw, cpu-time or coin for purchasing such, please contact.

- Hey, we would have our own distro to toy and learn with, that could actually be something quite unique, wouldn't that be interesting?

- Your ideas how to continue/proceed, or any thoughts, please?

---

Last edited by Skry; 2013-06-21 at 14:30.

Estel | # 465 | 2013-06-21, 16:58 | Report

+1. Practical usefulness above everything else

+1, sounds natural.

Definitely!

This is only reason why I decided to post, despite having so low amount of things to say

/Estel

Skry | # 466 | 2013-06-21, 18:07 | Report

@Estel

Hey, at least you bothered, thanks!

caveman | # 467 | 2013-06-21, 18:13 | Report

@Skry: you have brought up several interesting points. From my point of view, our most scarce resource is manpower, so I would focus on what we don't have at first, instead of improving what we already have in less-than-ideal form.

So:
* I would go with the mer kernel
* I would stay with some available and maintained base (arch linux or debian or mer comes to mind)
* and put some effort in the wayland/e17 stuff as we currently lack a good graphical touchscreen-enabled environment.

Skry | # 468 | 2013-06-21, 20:54 | Report

This is very true, though I personally think a good solid base is needed for anything that builds on it. It is also true, that there are some things that would be needed asap, like the usable touchscreen UI. This however is a difficult task, as long as I'm in this alone.

I've actually thought for a while whether I should move my contribs to that Debian rebase project and/or Mer. Anyway, keeping with Arch ARM means that the packages we want to optimize, need to be separately maintained, with their respective dependencies. Some of these are widely used libraries, some require patching, some need rebuilding against rebuilt libraries etc. This makes maintaining everything a task so tedious, that from my point of view it would be easier to maintain own repository, which would also give us the benefit of _fully_ cortex-a8 optimized system. Using snapshots from a rolling release base would also give a small team time to adapt to changes that would normally break something (like custom packages now).

To name a few packages that would need to be rebuilt and/or separately maintained:

Mesa
Pulseaudio
libpng and similar
zlib and similar
everything with egl/gles disabled, like cogl
pixman, cairo, pango...

My thoughts exactly. Concentrating on one (excellent) choice would be beneficial to everyone, even though it might limit the concept of choice. If we go so far that we begin to construct our own UI based on what already exists, that would truly benefit everyone. I think this combination is the best option to go with out of the choices we currently have. Assuming we get it to work

Älä hakkaa | # 469 | 2013-06-22, 14:14 | Report

Good point! Best optimized kernel as default. We don't have to support different types of hardware. There's only one n900, so yes to NEON and other such optimizations too.

You know, Arch means anus in German, nevertheless its base repo is a good starting point. But before going into extras, GL-graphics etc., I'd like to cater for early options and alternatives to it like a busybox base, a plan-9 base and statically linked bases. The philosophers have some interesting thoughts about these http://sta.li/

Skry | # 470 | 2013-06-22, 14:41 | Report

If we think about the compiler options used, in practice we would be optimizing for cortex-a8 with neon and thumb2. This would be a benefit for other similar devices too.

No wonder Arch users are a**holes then..
I don't have any allegiance to Arch Linux anymore, but I want to keep using pacman. Regardless of how I feel about the distro in general nowadays, it's still best there is, out of the similar choices. So, the base would always be 1:1 as much as possible, extras etc would be superseded with our own, and official repos would be left as (from my point of view) unsupported "fallbacks" -> lower on priority.

I want to avoid busybox as long as possible. For now, mksh is what I've planned on using, ideas and opinions are welcome with this matter too. I've been following starch and been playing around with musl for awhile now, won't go into details yet but if I get anything usable done, it'll be in here.