Active Topics

 


Reply
Thread Tools
Posts: 432 | Thanked: 917 times | Joined on Jun 2011
#461
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.
 
Posts: 204 | Thanked: 754 times | Joined on Jan 2012 @ Finland
#462
I'll try to put up a new rootfs this weekend.
 

The Following 2 Users Say Thank You to Skry For This Useful Post:
Posts: 15 | Thanked: 26 times | Joined on Feb 2013 @ Leipzig
#463
Originally Posted by saponga View Post
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.
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!
 

The Following User Says Thank You to Älä hakkaa For This Useful Post:
Posts: 204 | Thanked: 754 times | Joined on Jan 2012 @ Finland
#464
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.
 

The Following 6 Users Say Thank You to Skry For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#465
Originally Posted by Skry View Post
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.
+1. Practical usefulness above everything else

Originally Posted by Skry View Post
- 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.
+1, sounds natural.

Originally Posted by Skry View Post
- Hey, we would have our own distro to toy and learn with, that could actually be something quite unique, wouldn't that be interesting?
Definitely!

Originally Posted by Skry View Post
- Your ideas how to continue/proceed, or any thoughts, please?
This is only reason why I decided to post, despite having so low amount of things to say

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following 3 Users Say Thank You to Estel For This Useful Post:
Posts: 204 | Thanked: 754 times | Joined on Jan 2012 @ Finland
#466
@Estel

Hey, at least you bothered, thanks!
 

The Following User Says Thank You to Skry For This Useful Post:
Posts: 191 | Thanked: 415 times | Joined on Jan 2012
#467
@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.
 

The Following 2 Users Say Thank You to caveman For This Useful Post:
Posts: 204 | Thanked: 754 times | Joined on Jan 2012 @ Finland
#468
Originally Posted by caveman View Post
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.
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.

Originally Posted by caveman View Post
I would stay with some available and maintained base (arch linux or debian or mer comes to mind)
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...

Originally Posted by caveman View Post
and put some effort in the wayland/e17 stuff as we currently lack a good graphical touchscreen-enabled environment.
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
 

The Following 5 Users Say Thank You to Skry For This Useful Post:
Posts: 15 | Thanked: 26 times | Joined on Feb 2013 @ Leipzig
#469
Originally Posted by Estel View Post
+1. Practical usefulness above everything else

/Estel
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/
 
Posts: 204 | Thanked: 754 times | Joined on Jan 2012 @ Finland
#470
Originally Posted by Älä hakkaa View Post
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.
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.

Originally Posted by Älä hakkaa View Post
You know, Arch means anus in German, nevertheless its base repo is a good starting point.
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.

Originally Posted by Älä hakkaa View Post
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/
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.
 

The Following 2 Users Say Thank You to Skry For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 10:32.