I think _wb_'s point is that combining the kernel and the various 'apps' (a lot of them already existing at the time linux became more than a personal experiment) is what's making a pretty universal system somewhat modeled after Unix. This is where Android differs with it's more limited scope, e.g. it isn't intended to be a developer platform (though you can use it as such if you really want, but it isn't the primary use case which it definitely is in the GNU vision). To me as a developer that makes Android a toy system.
The good
- Thread starter moz
- Start date
SNESFAN
Retro game fanatic
What I find disheartening is that view is shared by many. Where instead of adapting something to meet your needs, like create a framework for development into the user environment, instead just disregard the whole thing as as not capable and shun it for that flaw. To the point of ignoring any other benefits it offers because your need for that thing missing is so great. I see Linux as a tool OS, I only use it only for doing development work. All my other daily driver OS's are more user friendly and I can do things I can't do with Linux there or the same things I can do faster elsewhere. I don't dislike Linux, but just as people choose different applications to do the same or different tasks, I also chose the OS that does the task I'm looking for the best. If those functions were merged it would be the ideal situation. Keeping them exclusively separate and ignoring the benefits the other has to offer kinda strikes me as insane. I can't even begin to rationalize why someone would do that, that's why I get into these discussions so often, and yet am still unable to figure it out.
GNU/Linux is so versatile and robust that it can be used for anything from number crunching supercomputer clusters and web server farms to a desktop PC or even a handheld like the Pandora/Pyra. It does not make any particular assumptions about the hardware it is running on. The hardware needs for a server farm are different than those of a computer graphics render farm (and in both cases you don't even bother with things like screens or input methods other than a simple tty), which are different from those of a desktop PC or embedded system.
Android is comparably much, much more specific. Although it does of course have lots of layers of abstraction, it still assumes a LOT of things about the hardware it is running on. Take a look at http://static.googleusercontent.com/media/source.android.com/en//compatibility/android-cdd.pdf -- you'll find things like:
- the device must have a screen with a diagonal of at least 2.5", 426x320 density-indepent pixels, with an aspect ratio between 4:3 and 16:9, and dynamic orientation
- it must support OpenGL 1.0 and 2.0
- it must have an on-screen keyboard and is not allowed to have a hardware keyboard with a layout that is not standard QWERTY or standard phone 12-keys
etc.
Android is comparably much, much more specific. Although it does of course have lots of layers of abstraction, it still assumes a LOT of things about the hardware it is running on. Take a look at http://static.googleusercontent.com/media/source.android.com/en//compatibility/android-cdd.pdf -- you'll find things like:
- the device must have a screen with a diagonal of at least 2.5", 426x320 density-indepent pixels, with an aspect ratio between 4:3 and 16:9, and dynamic orientation
- it must support OpenGL 1.0 and 2.0
- it must have an on-screen keyboard and is not allowed to have a hardware keyboard with a layout that is not standard QWERTY or standard phone 12-keys
etc.
Why should I adapt something that was never intended for my use case to my use case when tere already is something that fits *all* my use cases perfectly? I understand the point and it would be valid if there were anything Android was offering that was outside the scope of the system I currently use. I'm not arguing that that couldn't be the case, but my personal requirements (a readily available native tool chain with acces to all mainstream APIs - allowing to port pretty much everything interesting with reasonable effort - and a couple of terminal windows with key bindings to switch between them) are currently satisfied out of the box on debian but require serious adaptation on Android. That might change in the future (though it doesn't seem likely to me within the next 10 years), but until then Android is not providing even a single incentive to use it. YMMV.
SNESFAN
Retro game fanatic
Completely valid point, if I had no use for Linux, I would obviously not use it. The same holds true for you I'm sure. For my purpose it does have a use that nothing else fills. On the flip of that my daily use of say windows or android is that in Linux I can't run stuff like silver light on desktop or some flash applications on mobile. For the desktop of Linux most of my needs has a linux alternative and most of the use comes down to application interface preference, with exceptional help from wine. For mobile the use limitation is way more obvious as compatibly layers are not as mature so without work I'm not capable of doing I won't have my requirements met. If alien dalvik is truly a robust option then my whole view might change, but with the current features and experience I find I have to carry 2 devices with 2 different operating systems.
Last edited by a moderator:
levi
Still fresh, damnit!
The GNU toolchain very much assumes the use of character input (e.g. a keyboard) and output (e.g. a screen). That's an assumption all digital computers preceding it made too (as far as I know), but I don't know a way to drive groff using a touchscreen, short of it emulating a keyboard, badly.
I've always liked keyboards on my phones, for data entry and messaging needs. It seems to me that if I can use GNU/Linux on that hardware and it's properly supported, that opens up so many more uses for the device than any other mobile OS gives me, but it does need a certain amount of learning to get the best out of it, so it's clearly not for everyone.
The thing I'm looking forward to most in the Pyra is its keyboard actually. The other day I was doing a little HTML coding, and closing an anchor consisted of left trigger-comma, fn+c, a, left trigger-dot. Forgetting that a symbol was shifted rather than accessible via Fn and hitting Fn meant either hitting it twice more or pressing they key then deleting the wrong symbol. Even in the best case it's quite the handheld gymnastics entering all that.
I've always liked keyboards on my phones, for data entry and messaging needs. It seems to me that if I can use GNU/Linux on that hardware and it's properly supported, that opens up so many more uses for the device than any other mobile OS gives me, but it does need a certain amount of learning to get the best out of it, so it's clearly not for everyone.
The thing I'm looking forward to most in the Pyra is its keyboard actually. The other day I was doing a little HTML coding, and closing an anchor consisted of left trigger-comma, fn+c, a, left trigger-dot. Forgetting that a symbol was shifted rather than accessible via Fn and hitting Fn meant either hitting it twice more or pressing they key then deleting the wrong symbol. Even in the best case it's quite the handheld gymnastics entering all that.
Similar threads
