Active Topics
saponga |
2013-06-20
, 20:23
|
|
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. 
|
|
2013-06-20
, 20:47
|
|
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: | ||
|
|
2013-06-20
, 21:05
|
|
Posts: 15 |
Thanked: 26 times |
Joined on Feb 2013
@ Leipzig
|
#463
|
Originally Posted by saponga
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!
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.
| The Following User Says Thank You to Älä hakkaa For This Useful Post: | ||
|
|
2013-06-21
, 14:28
|
|
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.
- 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.
 |
|
2013-06-21
, 16:58
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#465
|
Originally Posted by Skry
+1. Practical usefulness above everything else
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.
Originally Posted by Skry
+1, sounds natural.
- 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.
Originally Posted by Skry
Definitely!
- Hey, we would have our own distro to toy and learn with, that could actually be something quite unique, wouldn't that be interesting?
Originally Posted by Skry
This is only reason why I decided to post, despite having so low amount of things to say
- Your ideas how to continue/proceed, or any thoughts, please?
/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!
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: | ||
|
|
2013-06-21
, 18:13
|
|
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.
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.
|
|
2013-06-21
, 20:54
|
|
Posts: 204 |
Thanked: 754 times |
Joined on Jan 2012
@ Finland
|
#468
|
Originally Posted by caveman
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.
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.
Originally Posted by caveman
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).
I would stay with some available and maintained base (arch linux or debian or mer comes to mind)
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
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
and put some effort in the wayland/e17 stuff as we currently lack a good graphical touchscreen-enabled environment.
|
|
2013-06-22
, 14:14
|
|
Posts: 15 |
Thanked: 26 times |
Joined on Feb 2013
@ Leipzig
|
#469
|
Originally Posted by 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.
+1. Practical usefulness above everything else
/Estel
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/
|
|
2013-06-22
, 14:41
|
|
Posts: 204 |
Thanked: 754 times |
Joined on Jan 2012
@ Finland
|
#470
|
Originally Posted by Älä hakkaa
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.
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.
Originally Posted by Älä hakkaa
No wonder Arch users are a**holes then..
You know, Arch means anus in German, nevertheless its base repo is a good starting point.
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
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.
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/