Menu

Main Menu
Talk Get Daily Search

Member's Online

    User Name
    Password

    Arch Linux ARM on N900

    Reply
    Page 47 of 64 | Prev | 37   45     46   47   48     49   57 | Next | Last
    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.

    Edit | Forward | Quote | Quick Reply | Thanks

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

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

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 2 Users Say Thank You to Skry For This Useful Post:
    nokiabot, Älä hakkaa

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

    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!

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following User Says Thank You to Älä hakkaa For This Useful Post:
    Skry

     
    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?

    Edit | Forward | Quote | Quick Reply | Thanks

    Last edited by Skry; 2013-06-21 at 14:30.
    The Following 6 Users Say Thank You to Skry For This Useful Post:
    caveman, Estel, goodgod261, madry72, mlwane, nokiabot

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

    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

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 3 Users Say Thank You to Estel For This Useful Post:
    nokiabot, Skry, Älä hakkaa

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

    @Estel

    Hey, at least you bothered, thanks!

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following User Says Thank You to Skry For This Useful Post:
    nokiabot

     
    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.

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 2 Users Say Thank You to caveman For This Useful Post:
    bingomion, fw190

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

    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

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 5 Users Say Thank You to Skry For This Useful Post:
    ArchiMark, bingomion, caveman, Estel, fw190

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

    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/

    Edit | Forward | Quote | Quick Reply | Thanks

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

    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.

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 2 Users Say Thank You to Skry For This Useful Post:
    Estel, nokiabot

     
    Page 47 of 64 | Prev | 37   45     46   47   48     49   57 | Next | Last
vBulletin® Version 3.8.8
Normal Logout