Active Topics
-
Swype stopped working (1)
to Nokia N9 / N950 by smartblu9 - 2 days, 17 hrs ago -
Maemo repository (16)
to Community by nieldk - 4 days, 4 hrs ago -
Error after installing Leste on sdcard (19)
to Maemo 7 / Leste by Arno_11 - 6 days, 4 hrs ago - more...
|
2012-01-23
, 15:27
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#2
|
Originally Posted by mr_jrt
That's the root of all problems. As long as we need an old kernel to support proprietary blobs to run our hardware we will keep falling behind Debian's state of the art. One of the main problems is the phonet firmware. How long have the nitdroid people been trying to get that working?
Having an old kernel is a big problem, yes, but unavoidable if we're going to have to maintain binary compatibility.
Or have a look at the Lemote Yeeloong! This netbook was shipped with some sort of Debian Lenny but the kernel included some proprietary blobs that make a complete dist-upgrade to Squeeze impossible and Wheezy will not be an option on that device. So the lifetime of these devices will be over after the support for Squeeze will be ceased. The same will happen to a "Debian-N900" that sticks to kernel 2.6.28.
It's situations like these that make me forget my pragmatism when being stopped by proprietary software requiring people to do the same work again and again stumbling in the dark.
Originally Posted by mr_jrt
I see that as the only realistic way to have a system that has long-term support and is up to date. Imagine you'd be forced to use Sarge today!
In my eyes, strictly speaking I'm not too bothered about being part of the "mainline" Debian repos, and indeed I might wonder if that was too big a constraint.
Originally Posted by mr_jrt
The difference between us and Ubuntu is that we are in a tiny niche while Ubuntu is huge, in some aspects even bigger than Debian.
What I'd be more than happy with is a relationship akin to Ubuntu's, where we share source packages, have some packages of our own, push and pull source from Debian, and have bugs linked to those in their BTS.
They talk to each other at eye level, we can't. So we either have to integrate or we won't participate.
Originally Posted by mr_jrt
Really? What's the difference? I see two of them but none of them qualifies to accept being tied to proprietary software or having to be separated from Debian's mainline:
Mobile devices if nothing else will always have different sensible defaults than desktop packages!
1. Different interfaces: That's purely a userland topic. So there's no reason why mobile packages should conflict with desktop packages. It's as easy as installing another desktop environment.
2. Different performance: Mobile devices will always be weaker than desktop computers. But they are already strong enough to run most desktop applications. I still have a desktop computer that runs Debian fine but is outperformed by my N900.
| The Following 3 Users Say Thank You to sulu For This Useful Post: | ||
|
|
2012-01-23
, 17:17
|
|
Posts: 2,154 |
Thanked: 8,464 times |
Joined on May 2010
|
#3
|
Originally Posted by Android_808
New page about kernel status is here: http://elinux.org/N900
sulu: I had the elektranox site thats linked to in the page you gave.
https://elektranox.org/n900/kernel/status.html
With regards to X, omap-drm is slowly coming together but doesn't support HW accel 3D
| The Following 11 Users Say Thank You to pali For This Useful Post: | ||
|
|
2012-01-23
, 21:53
|
|
Posts: 249 |
Thanked: 277 times |
Joined on May 2010
@ Brighton, UK
|
#4
|
Originally Posted by sulu
I appreciate where you're coming from, but I suspect we'll have to disagree
That's the root of all problems. As long as we need an old kernel to support proprietary blobs to run our hardware we will keep falling behind Debian's state of the art. One of the main problems is the phonet firmware. How long have the nitdroid people been trying to get that working?
We have a great team at the moment backporting things to our current kernel. As long as we have developers fulfilling that role, then it gets us something workable now that lets us work on the higher-level functionality so it'll be ready when (and realistically, if) the open source drivers arrive. What we have to accept though is that out N900s won't live forever. One day, we will have to migrate to new devices, and we obviously will if we want to have a healthy community. Debian wouldn't be such a success if it only ever supported a single Compaq model.
Originally Posted by sulu
Don't forget that Debian is so very much more than just a kernel. If Debian can support a BSD kernel (or even the Hurd!) then it can support a distinct N900-kernel, a HTC-Hero-kernel, a E7-kernel, etc.
Or have a look at the Lemote Yeeloong! This netbook was shipped with some sort of Debian Lenny but the kernel included some proprietary blobs that make a complete dist-upgrade to Squeeze impossible and Wheezy will not be an option on that device. So the lifetime of these devices will be over after the support for Squeeze will be ceased. The same will happen to a "Debian-N900" that sticks to kernel 2.6.28.
It's situations like these that make me forget my pragmatism when being stopped by proprietary software requiring people to do the same work again and again stumbling in the dark.
Originally Posted by sulu
That's true if you artificially limit yourself to a single device. Widen the scope to a Debian-based distro optimised for ultra-mobile devices (aka. phones, and probably tablets too), and then you start to have enough mindshare to justify sitting at the big table. There are a few existing projects that may be worth collaborating with, emdebian coming first to mind, the aforementioned pure Debian N900 work for another.
I see that as the only realistic way to have a system that has long-term support and is up to date. Imagine you'd be forced to use Sarge today!
The difference between us and Ubuntu is that we are in a tiny niche while Ubuntu is huge, in some aspects even bigger than Debian.
They talk to each other at eye level, we can't. So we either have to integrate or we won't participate.
Originally Posted by sulu
Speed is only one factor (which I agree, is decreasingly important).
Really? What's the difference? I see two of them but none of them qualifies to accept being tied to proprietary software or having to be separated from Debian's mainline:
1. Different interfaces: That's purely a userland topic. So there's no reason why mobile packages should conflict with desktop packages. It's as easy as installing another desktop environment.
2. Different performance: Mobile devices will always be weaker than desktop computers. But they are already strong enough to run most desktop applications. I still have a desktop computer that runs Debian fine but is outperformed by my N900.
There are several that spring to mind, actually:
- Input devices - Being usable with a mouse vs. Having a UI that is finger friendly, but can deal with a stylus and also supporting both multi as well as single touch. Look at the number of Linux apps that are easily ported to the N900, but are completely unusable due to a) no right click, b) small widgets, c) an inability to move the pointer without clicking...
- Power - Phone batteries are much, much, much more limited than even Laptop batteries, let alone desktop computers. Software really needs to be optimised to use as little battery as possible, which is hardly a concern for desktop software.
- Screen Size - Mobile devices have very limited screen sizes. The resolutions are usually sufficient for a lot of old desktop software, but as they're so small, they can be impossible to click on or read. This is far more than just a different WM - few UIs are built to be scalable.
I'm sure there are a few more, but those are the easy ones.
| The Following 2 Users Say Thank You to mr_jrt For This Useful Post: | ||
|
|
2012-01-23
, 22:24
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#5
|
Originally Posted by mr_jrt
Well, I have to disappoint you. I totally agree with what you say here.
I appreciate where you're coming from, but I suspect we'll have to disagree
btw: I intend to use my N900 "forever". I had my last mobile phone for more than 5 years and that old desktop computer I was talking about will become 14 years old in summer. I expect my N900 to become at least 5 years old too and I have two replacement N900's in my closet. And by the time all of them are gone my eyes will be to bad for those little screens anyway.
Originally Posted by mr_jrt
The difference between Hurd/BSD and N900 is that the former actually are something special. They need their own userlands because you can't run an existing flavour of Linux binaries on them. That's totally different for the N900. It has a Cortex A8 CPU so it runs normal armel respectively armhf binaries if you use a Linux kernel.
Don't forget that Debian is so very much more than just a kernel. If Debian can support a BSD kernel (or even the Hurd!) then it can support a distinct N900-kernel, a HTC-Hero-kernel, a E7-kernel, etc.
If you want to use a BSD kernel that would be a different story because you'd need some architecture like kfreebsdarmhf but that stil doesn't make it special for the N900. It would just be a regular armel port for FreeBSD kernels which runs on the N900 too.
Originally Posted by mr_jrt
I guess we're just talking about different time frames here. A separated project is the way to go for short-term development because you are more flexible. But once you have that project running you should try to integrate it into the mainline to have the long-term profit that comes from the Debian infrastructure.
That's true if you artificially limit yourself to a single device. Widen the scope to a Debian-based distro optimised for ultra-mobile devices (aka. phones, and probably tablets too), and then you start to have enough mindshare to justify sitting at the big table. There are a few existing projects that may be worth collaborating with, emdebian coming first to mind, the aforementioned pure Debian N900 work for another.
Originally Posted by mr_jrt
You have a point here.
[*]Input devices - Being usable with a mouse vs. Having a UI that is finger friendly, but can deal with a stylus and also supporting both multi as well as single touch. Look at the number of Linux apps that are easily ported to the N900, but are completely unusable due to a) no right click, b) small widgets, c) an inability to move the pointer without clicking...
Originally Posted by mr_jrt
But the power consumption is much lower too. I see no real difference to laptop computers here.
Power - Phone batteries are much, much, much more limited than even Laptop batteries, let alone desktop computers. Software really needs to be optimised to use as little battery as possible, which is hardly a concern for desktop software.
Originally Posted by mr_jrt
Another point for you.
Screen Size - Mobile devices have very limited screen sizes. The resolutions are usually sufficient for a lot of old desktop software, but as they're so small, they can be impossible to click on or read. This is far more than just a different WM - few UIs are built to be scalable.
So the bottom line is that the GUIs of applications beyond what's managed by the WM is an important topic to take care of. I haven't looked into that many programs yet but all I've been looking up seemed to be rather hard to adapt to small screens (Claws Mail, Micropolis, OpenOffice just to name a few). In most cases it would require significant source code rewrites which can hardly be done without a close cooperation with the upstream developers.
| The Following 3 Users Say Thank You to sulu For This Useful Post: | ||
|
|
2012-01-23
, 23:17
|
|
Posts: 249 |
Thanked: 277 times |
Joined on May 2010
@ Brighton, UK
|
#6
|
Originally Posted by sulu
I may have been ambiguous here, I'm just saying that having a separate kernel for each device in the Debian style for our mobile distro is no big deal. I not saying that you can't run an existing userland on top of the N900 kernel (addressing your point about the Hurd et al.), but you don't have to be running the head Linux kernel. The backports and amazing work done so far on the head kernel buys us a lot of time, but just as the users of Debian stable run old kernels quite happily, so can we, to a (far off) point. For me being able to use a mainline kernel is just something to aspire to once we can. The desktop 3D drivers have had a LOT of attention over many years and they're still not as complete as the closed source ones. We could be waiting forever for those drivers. In true project management style, you really want to reduce the critical path
Well, I have to disappoint you. I totally agree with what you say here.
btw: I intend to use my N900 "forever". I had my last mobile phone for more than 5 years and that old desktop computer I was talking about will become 14 years old in summer. I expect my N900 to become at least 5 years old too and I have two replacement N900's in my closet. And by the time all of them are gone my eyes will be to bad for those little screens anyway.
The difference between Hurd/BSD and N900 is that the former actually are something special. They need their own userlands because you can't run an existing flavour of Linux binaries on them. That's totally different for the N900. It has a Cortex A8 CPU so it runs normal armel respectively armhf binaries if you use a Linux kernel.
If you want to use a BSD kernel that would be a different story because you'd need some architecture like kfreebsdarmhf but that stil doesn't make it special for the N900. It would just be a regular armel port for FreeBSD kernels which runs on the N900 too.
Eventually, we will probably hit the point where a shim around things like the 3D drivers becomes necessary as too much software relies on impractical-to-backport kernel changes. Hopefully it shouldn't be too problematic as our side of the interface is a known, so adapting things should have a minimal performance penalty. It's hard to say though. If ndisloader can run Windows drivers on Linux I suspect we can run old Linux drivers on new Linux kernels given enough motivation.Idealism gets the hard, boring things done (the last 20%), and for that we should all be eternally grateful. Practicality gets the majority done (the first 80%).
|
|
2012-01-24
, 07:09
|
|
Posts: 961 |
Thanked: 565 times |
Joined on Jul 2007
@ Tyneside, North East England
|
#7
|
A lot depends on what people actually want, and the form factor.
To get things compact and very power efficient is going to need some clever silicon, which will have a 99% chance of being closed.
I understand even the Raspberry Pi, which is about as opensource and community focussed as is possible has some closed blobs around the broadcom silicon.
The RPi has the potential to make for some interesting hardware running debian variants including the likes of mer. I have read bits on the web about interfacing various touch LCDs, including N900.
If you could bundle all that up, then you could have a cost effective alternative which is potentially very feasible
To get things compact and very power efficient is going to need some clever silicon, which will have a 99% chance of being closed.
I understand even the Raspberry Pi, which is about as opensource and community focussed as is possible has some closed blobs around the broadcom silicon.
The RPi has the potential to make for some interesting hardware running debian variants including the likes of mer. I have read bits on the web about interfacing various touch LCDs, including N900.
If you could bundle all that up, then you could have a cost effective alternative which is potentially very feasible
__________________
______________________________
Nokia 770 (2gb) since Aug 2007
Nokia N800 (32gb) since Dec 2007
Nokia N810 (16gb) since Sep 2009
Nokia N900 (64gb) since Aug 2010 ______________________________
______________________________
Nokia 770 (2gb) since Aug 2007
Nokia N800 (32gb) since Dec 2007
Nokia N810 (16gb) since Sep 2009
Nokia N900 (64gb) since Aug 2010 ______________________________
|
|
2012-01-29
, 09:53
|
|
Posts: 1,203 |
Thanked: 3,027 times |
Joined on Dec 2010
|
#8
|
thanks for the link pali.
according to the messages linked to on that page, were looking at kernel 3.4 before full modem support is included. How this will compare to the default Maemo or Meego kernel I don't know. Meego iirc uses ofono in its stack so that side should be far easier if driver is compatible.
With regards to debian, I think given that the system needs to be stable, we need a stable base like 6.0 rather than testing. However, given the specs of the n900 and the applications likely to be run, I would want to look down the root of recompiling for optimization and to remove unwanted features compared to the original debian packages.
with regards to packages in general, I would want to define a standard UI toolkit. with Fremantle, we started out with GTK, then incorporated QT. I have no problem with either but would prefer one to reduce memory consumption.
according to the messages linked to on that page, were looking at kernel 3.4 before full modem support is included. How this will compare to the default Maemo or Meego kernel I don't know. Meego iirc uses ofono in its stack so that side should be far easier if driver is compatible.
With regards to debian, I think given that the system needs to be stable, we need a stable base like 6.0 rather than testing. However, given the specs of the n900 and the applications likely to be run, I would want to look down the root of recompiling for optimization and to remove unwanted features compared to the original debian packages.
with regards to packages in general, I would want to define a standard UI toolkit. with Fremantle, we started out with GTK, then incorporated QT. I have no problem with either but would prefer one to reduce memory consumption.
|
|
2012-01-29
, 10:32
|
|
Posts: 1,225 |
Thanked: 1,905 times |
Joined on Feb 2011
@ Quezon City, Philippines
|
#9
|
Originally Posted by Android_808
WRT 1 - I beg to differ. I believe that we can easily put togther a rolling release distribution - there is absolutely no point in performing large, multi-deca-MB, CPU-hungry upgades on a mobile device. (No, Nokia's SSU method is not as seamless as Nokia would like you to think.) Has anyone here used Arch Linux? As long as you have active devs updating their packages frequently and people get notified of glibc and binutils updates, everything stays nice and happy (however, by doing this with apt we'd need to use apt-get dist-upgrade every time we want to update. No biggie.)
With regards to debian, I think given that the system needs to be stable, we need a stable base like 6.0 rather than testing. However, given the specs of the n900 and the applications likely to be run, I would want to look down the root of recompiling for optimization and to remove unwanted features compared to the original debian packages.
with regards to packages in general, I would want to define a standard UI toolkit. with Fremantle, we started out with GTK, then incorporated QT. I have no problem with either but would prefer one to reduce memory consumption.
WRT 2 - It's as simple as this, really:
Keep rolling with GTK - we get to keep Hildon
Keep rolling with Qt - we need to find a decent WM (it could be argued that Hildon stack could be redone in Qt though)
The merits of each are outside this discussion, as both of them perform pretty much the same and have similar memory footprints.
__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
|
|
2012-01-29
, 13:05
|
|
Posts: 1,203 |
Thanked: 3,027 times |
Joined on Dec 2010
|
#10
|
I use arch and maintain a few packages so i fully understand its merits. my point was more of a third party consideration further down the line.
take iOS. development is easier because its locked down hardware with set s/w versions. android on the other hand has multiple versions, multiple h/w configurations etc so developing anything closed source requires more model/version specific changes, testing etc. At present we only have n900, but what happens further on if we want to port to other devices and commercial vendors take interest.
take iOS. development is easier because its locked down hardware with set s/w versions. android on the other hand has multiple versions, multiple h/w configurations etc so developing anything closed source requires more model/version specific changes, testing etc. At present we only have n900, but what happens further on if we want to port to other devices and commercial vendors take interest.
http://talk.maemo.org/showpost.php?p...&postcount=693
For reference: