| |||||||||||||
2011: The Year of Linux Disappointments (Datamation)2011: The Year of Linux Disappointments (Datamation)Posted Dec 14, 2011 19:50 UTC (Wed) by geuder (subscriber, #62854)In reply to: 2011: The Year of Linux Disappointments (Datamation) by b7j0c Parent article: 2011: The Year of Linux Disappointments (Datamation)
Android might be based on the Linux kernel, but the end product is far from any FOSS spirit. Although his headline is Linux he seems to think FOSS a lot.
Myself I'd like to continue to use a Linux phone, but after the death of Maemo I don't see any options besides trying to buy all N900s on the planet that don't have a broken USB port yet.
I'm not willing to put all my life into Google's DB (although I have a couple of accounts already)
(Log in to post comments)
2011: The Year of Linux Disappointments (Datamation) Posted Dec 14, 2011 20:03 UTC (Wed) by yoush (subscriber, #38940) [Link]
Maemo was indeed a big hope that failed completely because of incompetence of Nokia. It became visible at PR1.2 waiting story, and turned into a fact on the day when Meego was announced.
Since then, there is no usable smartphone. N900 depends on closed components too much, and those have ugly bugs that never will be fixed.
I'm currently living with Android (with everything from google disabled wherever possible), but it's broken multitasking, no-undo-in-text-fields and other "features" make me angry every day.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 12:04 UTC (Thu) by nye (guest, #51576) [Link]
>I'm currently living with Android (with everything from google disabled wherever possible), but it's broken multitasking...
What's broken about its multitasking?
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 12:28 UTC (Thu) by yoush (subscriber, #38940) [Link]
I type text in dialog popped by one app, switch to other app to get a hint what to type, switch back - and find just typed text lost.
I switch folder in mail client, it is slow to load over poor gprs link, I switch elsewhere, then switch back - and see mail cleint returned to original oflder.
And many similar examples.
There is no multitasking in android. There are only "save state - restore state" events, that some apps handle and some don't.
This is a 100% fail after what Maemo provided.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 1:58 UTC (Fri) by aryonoco (subscriber, #55563) [Link]
Well to be honest those are examples of application failures. The Android developer guidelines explicitly mention these and provide guidelines on how to make sure that state is always saved. A user shouldn't notice when a state is restored.
While it's not like traditional desktop multitasking, I don't think there is anything broken about Android's implementation, just that it's different (and has its own pros and cons). However it does require developers to understand the fundamentals of Android application lifecycles, which apparently many fail at.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 4:25 UTC (Fri) by yoush (subscriber, #38940) [Link]
These "application failures" are massive, and underlying reason is lack of proper multitasking at layer below applications.
There is no excuse for lack of multitasking these days. It's already 2011. And hardware this runs on is stronger than what was used to service lunar flights.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 4:43 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
Android is a fully multitasking OS. The issue is pretty straightforward - what do you do when you have applications that want more RAM than you have? You could swap, which would result in dreadful user experience as everything slows down. Or you could require that applications support saving their state and exiting, which (assuming applications are implemented correctly) will then be pretty much invisible to most users.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:08 UTC (Fri) by yoush (subscriber, #38940) [Link]
It does not matter that will be "then" if condition of your "if" is false.
The current situation is - quite a few applications don't save-restore everything, without any real improvement expected. Saving-restoring state of every element in every dialog is simply too cumbersome, joe developer will never do that.
And the result is - data loss, or generally things-not-done. I don't see this is anyhow better than slowness-because-of-swapping.
On n900 I was able to e.g. open a web page while at home, find needed information, and be sure it will be on-screen when needed in a few taps regardless of if mobile network is available or sessions expired on the server from where page originates. Or - fill in contact details looking for notes in a plaintext file before typing each field.
With Android all that causes pain. Perhaps among thousands garbage apps on market, there are handful of those that don't loose data in particular cases. However, (1) need to dig through thousands to find good one, for which I don't have time, and (2) even that won't help because it's not possible to test all cases in advance, I simply don't know all possible cases.
Multitasking is not an eye candy. Quite a few real-life use cases require it. And all those are causing poor experience on Android-based device.
Most don't care just because they are not trying to use devices seriously.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:18 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
so if the device doesn't have enough memory to run both apps at the same time, what would you want to happen?
would you want it to refuse to run the new program?
what if there is enough space to start the new program, but then it needs more memory later? do you want the new program to be aborted?
the Android spec says that programs are supposed to checkpoint themselves, and if you are running on a device with enough ram to run all the programs, they don't need to.
but if you are running on a device without enough ram to run all the programs that you are trying to run, and the programs don't checkpoint themselves properly, you run in to problems.
and P.S. the same type of thing happens on apple devices, if you run more than can fit in ram, the OS silently kills some non-forground process, which then must start from scratch (with whatever checkpointed state it has) when you try to access it again.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:45 UTC (Fri) by yoush (subscriber, #38940) [Link]
> so if the device doesn't have enough memory to run both apps at the same
> time, what would you want to happen?
1. I don't believe that 512M is not enough to run address book and plain text editor at the same time - which is exactly the combination causing data loss on the device lying on this table.
2. They must swap. And swapping must be implemented in such way that important things such as incoming call handling are still fast. Sorry but implementing this *is* possible, it is not a rocket science. I'm involved in fast boot projects at Montavista PS, where we are doing much more complex things (such as 200 ms from poweron to userspace running) with the same base (the linux kernel).
> the Android spec says that programs are supposed to checkpoint themselves
Value of specs that are not followed is questionable
> the same type of thing happens on apple devices
That just means that apple devices are even worse.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
and when you fill swap? remember that storage if very small, slow, and wears out with frequent writes. not at all good for swapping.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 6:08 UTC (Fri) by yoush (subscriber, #38940) [Link]
Today storage is already not that small, and tomorrow it will be even larger.
And it supports up to 10^6 writes, which, combined with properly implemented wear-leveling, eliminates this problem.
As for being slow - it just means that algorithm that chooses what to swap out must be more careful and never swap out what is needed for important use cases.
As I've written elsewhere in the thread, it is ok to become slow when device is being used beyond it's capabilities. What is not ok is random data or context loose - and this is exactly what happens today on Android devices - even under far-from-stress conditions such as running address book and text editor.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 20:35 UTC (Fri) by jimparis (subscriber, #38647) [Link]
The swap works great on the n900, just like on a laptop. If you open too many apps, or they use too much memory, more and more swap gets used, and the system slows down. And then it's a tradeoff that you the user can manage: is what I'm doing important enough that I'm OK with things being slow for the moment, or should I close some of the apps that I don't really need right now? There's enough swap that the speed penalty gets bad and I deal with it manually long before the space actually runs out -- I have never had an app die due to memory pressure.
It's the main reason I switched away from my G1: when switching from a web browser to SSH and back, you could never be sure whether the web browser would stay put. Unfortunately, since Maemo/Meego/Tizen is clearly an evolutionary dead end and it's not worth fixing bugs anymore, I've recently switched back to Android with all its failings. Hopefully the 1G of RAM in my new phone will make the lack of predictable multitasking less of an issue.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:40 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
You could be sure of that if the OOM killer didn't strike, or if you didn't get so bored of waiting for contended memory to become available that you rebooted your phone. But if you want that behaviour to be deterministic in a multitasking environment then you either need to special-case some applications or you need to assert that applications must support checkpointing. You seem to be arguing that application developers can simply assume that their resources are unlimited and not worry about what happens when they run into those restrictions.
Does this result in a bunch of infuriating edge cases on Android? Yes, and it does on iOS as well. Not everyone handles this well. Applications that you want to be doing stuff in the background may end up thrown out. But, perhaps more importantly, you don't have to manually kill a bunch of programs before you can start another, and background applications don't get killed without the opportunity to save their state.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 6:00 UTC (Fri) by yoush (subscriber, #38940) [Link]
I see nothing bad in special-casing application that are "primary" for the device. Just the opposite - I think this is proper way. Especially if it will be up to user to decide what "primary" means.
We are on free software. We could tune OOM killer, swapper algorithms and whatever, to prevent "important" things from being killed or slowed down.
And yes - less priority things will become slow, maybe very slow, if attempting to use device beyond it's capabilities. That's ok as long as user gets indication of device is being used beyond it's capabilities, and has a way to recover *without* *data* *loss*.
In Android ecosystem, as it exists today, this problem is not solved. Too many apps don't follow specs enough to avoid data or context loss. For me, this is indication of entire approach failure in Real World conditions - although it probably looked ok on paper.
And - I can't agree that behaviour where my data and/or context is lost at random points is "deterministic", sorry. And - again - I don't believe that running address book and plain text editor at the same time is a stress for 1Gz processor and 512M of ram.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 11:24 UTC (Fri) by Fowl (subscriber, #65667) [Link] Well I run on a similarly spec'd device (HTC HD2) and have no trouble with multitasking, I commonly switch between the web browser, a train timeable app, foursquare, navigation, text messaging, twittter, facebook, and gmail. Perhaps by using such "common" apps I avoid the poorly written ones. The only application I have trouble with is the one for my bank, which seems to actively resist multitasking, I presume as some sort of "security" "feature". I use a very close to "as lobbed across the wall into git", ie. "stock" distro/rom called NexusHD2-Gingerbread. Some OEMs do overload their devices. Would you like to mention your device, "rom" and applications?
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 18:37 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
"Well I run on a similarly spec'd device (HTC HD2) and have no trouble with multitasking,"
Perhaps you're just not picky enough with data loss in the sense of yoush's desire to have every piece of state saved (including gui widget contents).
This checkpoint/restore stuff is so PalmOS; it's surprising that a decade+ later, with 100x the hardware resources, it's still considered necessary/appropriate.
What have really changed? Posted Dec 16, 2011 19:23 UTC (Fri) by khim (subscriber, #9252) [Link] This checkpoint/restore stuff is so PalmOS; it's surprising that a decade+ later, with 100x the hardware resources, it's still considered necessary/appropriate. It's not surprising at all. Hardware may be 1000x more powerful (you mussed one order of magnitude), but system requirements grew 1000x, too. Think about it: Pilot 5000 had 512K of memory and 160x160x1bpp screen. Full system memory was large enough to keep contents of about 163 screens. "Latest and greatest" uber-powerful Galaxy Nexus has 1GB of memory and 1280*720*24bpp screen. Full system memory is large enough to keep about 388 screens. This means that, relatively speaking, hardware resources are about 2-3 times more powerful then they were back then. So... why exactly do you expect radically increased capabilities WRT multitasking? AFAIK N900 is extremely painful to use exactly because it tries to use "true multitasking" on the hardware which is just not powerful enough.
What have really changed? Posted Dec 16, 2011 19:43 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
"Full system memory [was 163 and now ] is large enough to keep about 388 screens."
That seems like a cherry-picked metric. Applications don't save state in such proportion to their window state.
Sure, it's not 100% fair comparison... Posted Dec 16, 2011 21:20 UTC (Fri) by khim (subscriber, #9252) [Link] That seems like a cherry-picked metric. Applications don't save state in such proportion to their window state. Sorry, but this exactly what they do. Of course it's not 100% apples-to-apples comparison, but it's pretty close to it. Where you see some savings you immediately see more "bloat" applied. For example where Palm used bitmap fonts while Android uses vector fonts so difference should be much smaller then 1000x, right? Nope: Palm used 8bit encoding with tiny number of glyphs while Android supports large subset of Unicode. Note that these fonts must be rasterized which needs memory for caching, etc. Amount of resources needed to produce 2D graphic correlates with the number pixels on your screen pretty damn well. Yes, there are different techniques involved which may push the balance one way or another but the raw amount of data on your screen is still very good starting point.
Sure, it's not 100% fair comparison... Posted Dec 16, 2011 21:43 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
I'm sorry, I don't see how the plus.google.com post substantiates that the *application context that needs to be saved/restored* during an app switch is somehow proportional to the graphics frame buffer size. Can you help me out a more sketched-out example?
Sorry, my bad... Posted Dec 17, 2011 9:21 UTC (Sat) by khim (subscriber, #9252) [Link] I've missed one logical step because I was sure your understand that your correct fact (applications don't save state in such proportion to their window state) damns your idea, not mine :) Sorry about that. Obviously applications don't save state in such proportion to their window state when they are doing checkpoint/restore stuff using application-specific code. Yet they do if they use generic code! Working set of typical application includes quite a few buffers which size is directly proportional to the size of screen. If you don't ask application to checkpoint/restore stuff using application-specific code then you need to save/restore these buffers, too. And since you can fit about about the same number of them in memory on PalmOS and on Android... the same principle applies.
Sorry, my bad... Posted Dec 17, 2011 10:55 UTC (Sat) by yoush (subscriber, #38940) [Link]
> If you don't ask application to checkpoint/restore stuff using
> application-specific code then you need to save/restore these buffers...
For last ~20 years, exposure events have been used to avoid framebuffer saving.
Sorry, my bad... Posted Dec 17, 2011 14:58 UTC (Sat) by pboddie (subscriber, #50784) [Link]
Indeed, framebuffer caching is an optimisation, not the first port of call for applications that don't feel like doing a redraw. Twenty years ago, it just wasn't possible to have all the applications caching their window contents in memory, although I do accept that caching rendered font bitmaps is very beneficial for performance even in memory-constrained systems: I remember increasing the font cache above the default 48K on my 1MB machine to get substantially faster text rendering.
PCs and phones are fundamentally different... Posted Dec 17, 2011 21:51 UTC (Sat) by khim (subscriber, #9252) [Link] Indeed, framebuffer caching is an optimisation, not the first port of call for applications that don't feel like doing a redraw. Sorry. But no. It was optimization on workstations with mouse. It's hard requirement on smartphone. Why? Touchscreen. Manipulations with touchscreen only feel "natural" if image on screen follows finger without jitter. For that you need to redraw image on screen in 16ms or less. The only way to do that in a lot of cases is to use shadow buffers. Especially if you don't know the exact specifications of the target phone platform and can not guarantee that you'll be able to draw everything in 16ms using just abstract representation of your application state. Now, you can flush all these buffers when your application goes to background and restore them when it returns - but that requires cooperation from application side and is awfully similar to that dreadful "checkpoint/restore stuff". Besides if application is going to background for a short time it may not be a good idea to throw all these buffers right away (battery life, you know), so in the end you'll come up with scheme quite similar to what iOS/Android are doing. You may say: but I don't want all that fancy touchscreen stuff! Give me good multitasking instead! Well, may be you don't need it, but handset makers surely do: fate of Blackberry/Symbian/etc says that most people do want that touchscreen stuff - and if you'll take in account this requirement then suddenly resources of modern phones are not "overwhelming" but "just barely enough"...
PCs and phones are fundamentally different... Posted Dec 18, 2011 1:24 UTC (Sun) by pboddie (subscriber, #50784) [Link] Sorry. But no. It was optimization on workstations with mouse. It's hard requirement on smartphone. In general it is an optimisation. Your applications all have to be able to render themselves, but a decision has been taken that they won't be asked to do so in various circumstances because they will appear too slow or won't look very nice. If you've filled up your memory with what are effectively screenshots because you've "started" 100 applications, you should expect some of them not to reappear instantly at 50 frames per second in some tiresome animation. Having them show up eventually is a lot better than having them show up immediately and then forgetting all their state.
PCs and phones are fundamentally different... Posted Dec 18, 2011 7:52 UTC (Sun) by yoush (subscriber, #38940) [Link]
I don't really understand why you people are talking about framebuffer content saving here. This is *not* what is happening in Android.
If application restores from [poorly-saved] "checkpoint", it definitely redraws from scratch. It can't be framebuffer restore, because last framebuffer state matched last application state, not the content of the poorly-saved checkpoint.
Have you tried looking on thread? Posted Dec 18, 2011 8:57 UTC (Sun) by khim (subscriber, #9252) [Link] I don't really understand why you people are talking about framebuffer content saving here. Have you tried to look on the context of the discussion? This is *not* what is happening in Android. Sure, but the question is: why this is not what is happening in Android. If application restores from [poorly-saved] "checkpoint", it definitely redraws from scratch. It can't be framebuffer restore, because last framebuffer state matched last application state, not the content of the poorly-saved checkpoint. Sure, but then running application state includes few shadow framebuffers which needs memory proportional to the size of raw data on your screen. And if you keep that in mind then suddenly your phone is not "orders of magnitude more powerful then old PalmOS devices" but "about 2-3 times more powerful then first PalmOS device". Most touchscreen shartphones today employ this technique not because their creators are stupid, but because it was the only way to create usable "magic tablet" using today's technology.
Have you tried looking on thread? Posted Dec 18, 2011 12:46 UTC (Sun) by fuhchee (subscriber, #40059) [Link]
"Sure, but then running application state includes few shadow framebuffers which needs memory proportional to the size of raw data on your screen."
Maybe the misunderstanding here is not differentiating between the memory requirements of running vs. stopped applications, and the associated state transitions.
It seems that if many apps (which ones?) use large pixmap caches during operation, *and* these are all retained in RAM while the apps are stopped, *then* perhaps overall RAM consumption can be said to be proportional to framebuffer sizes.
If many apps do not do not keep large pixmaps during run, or if they jettison them upon an application stop, then no.
Have you tried looking on thread? Posted Dec 18, 2011 14:45 UTC (Sun) by khim (subscriber, #9252) [Link] It seems that if many apps (which ones?) use large pixmap caches during operation Practically all applications do that. Even simple list of things need background pixmap or else you'll be unable to scroll it smoothly. *and* these are all retained in RAM while the apps are stopped Of course they are retained! What's the point of doing anything else? If you need to ask application restore them then you can as well ask application start from save point. If application developer can not handle save/restore events correctly then why do you think s/he'll be able to handle "drop shadow buffers"/"restore shadow buffers" events correctly? If many apps do not do not keep large pixmaps during run, or if they jettison them upon an application stop, then no. Sure. "No large pixmaps" is BlackBerry/Symbian model which provides abysmal touchscreen experience. And to rely on the voluntary cooperation between applications is just silly: both MacOS Classic and Windows 3.x did that and it was awful. At least with save/restore model badly written application can only make experience awful for user when s/he actively uses this application. "Let's all work together" model makes it impossible to understand what exact application makes your system unusable. All systems which tried that (Maemo, Symbian, Windows Mobile) were constant battlefield because of that.
Have you tried looking on thread? Posted Dec 19, 2011 12:36 UTC (Mon) by fuhchee (subscriber, #40059) [Link]
"Of course they are retained! What's the point of doing anything else? If you need to ask application restore them then you can as well ask application start from save point. ... If application developer can not handle save/restore events correctly then why do you think s/he'll be able to handle "drop shadow buffers"/"restore shadow buffers" events correctly?"
The apps must have the ability to recompute those pixmaps whenever, or they wouldn't have been drawn in the first place. Plus the pixmap state is not sufficient for application restore anyway, and would be in addition to whatever other state is saved/restored. The question is whether apps or the OS treat those pixmaps at a save/restore as a disposable cache, thus saving memory.
Recall that we were originally discussing whether ordinary unix concepts like multitasking, expose events, are really so inapplicable here. Stopped application state could be swapped by the OS instead of by the app. If pixmaps form such a core element of this platform, then specially handling them (disposing them also in the compositor/OS) seems workable. If not, I'd like to understand why.
Have you tried looking on thread? Posted Dec 19, 2011 12:45 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The main reason to want to special-case the pixmap storage is that you'd want to be able to redraw that while the application is still restoring state - an expose event isn't going to be processed until you've pulled in everything needed to regenerate the UI, and a second of black screen followed by a responsive app is likely to be more distracting than a second of UI that doesn't respond. However, there's absolutely no reason that that has to be kept in RAM - I've no idea how Android does it, but grubbing through the filesystem on an iOS device reveals a pile of snapshots of applications.
The reason to have checkpointing built into the applications rather than the OS is that the kernel has no real idea which bits of data can be reconstructed and which are user input. Swapping the entire application would probably be massively slower than just serialising a small subset and pulling that back in.
I think you are mixing issues... Posted Dec 19, 2011 14:51 UTC (Mon) by khim (subscriber, #9252) [Link] The apps must have the ability to recompute those pixmaps whenever, or they wouldn't have been drawn in the first place. Where this idea arrived from? Applications create shadow buffers for the express purpose of not doing recomputes later. Sure, OS and some toolkits may create cache buffers, too - but these are different. If mapping application converted vector map to pixmaps to make scrolling possible then the last thing it wants is to suddenly find out that OS decided to kill these pixmaps to save memory. If the whole application is killed and then restored then, of course, pixmaps will be recomputed, but otherwise they are kept in memory in the "ready to go" state... Plus the pixmap state is not sufficient for application restore anyway, and would be in addition to whatever other state is saved/restored. Sure. Pixmaps determine minimal size of application. Of course it may (and often does) contain other information in memory, too. But of course the applications for which pixmaps are just a noise in their memory consumption are even larger thus it makes even less sense to try to use "proper multitasking" with them. Recall that we were originally discussing whether ordinary unix concepts like multitasking, expose events, are really so inapplicable here. I always remember that, but it looks like you are forgetting sometimes. Ordinary unix approach is just to ignore expose events (window manager may change window borders, and application can usually ignore expose events completely). This is clearly inappropriate (as you yourself show) and everything else is just question of how much application should do to participate in checkpoint/restore dance.
This is, again, the case of "you don't exist"... Posted Dec 18, 2011 8:48 UTC (Sun) by khim (subscriber, #9252) [Link] If you've filled up your memory with what are effectively screenshots because you've "started" 100 applications, you should expect some of them not to reappear instantly at 50 frames per second in some tiresome animation. Nope. People don't understand this. Any OS which works like that will fail. Having them show up eventually is a lot better than having them show up immediately and then forgetting all their state. Well, it may be better for geeks like your and me, but it's much, much worse for Joe Average! People don't understand that application fill up the memory (heck, most need an explanation for what memory actually is first), if they understand then they forget all about it, etc. That's why set-top boxes with HDD remove (permanently remove at that!) old records, for example. People perceive smartphones not as electronic device, but as some kind of "magic tablet". They don't know and don't want to know how the whole thing works. That's why first iPhone was such a bomb: it was worse then most smartphones of the time (initially it had no support for apps!), but it was finally "magic tablet" which can be used without thinking about memory, tasks, etc. Sure, it had a lot of limitations (when you switched from one activity to another context was often lost, it had no copy-paste, etc), but it was finally usable by Joe Average, not just by eggheads!
This is, again, the case of "you don't exist"... Posted Dec 18, 2011 14:06 UTC (Sun) by pboddie (subscriber, #50784) [Link] Nope. People don't understand this. Any OS which works like that will fail. I know you can't resist contradicting everyone, but plenty of people who don't work in software development are perfectly capable of realising that they have, in their own words, "filled up" or "overloaded" their device. You can argue that they have had to develop such notions through experience with technology that did not attempt to hide its own limitations, but people are pretty quick to notice and adapt to the limitations of things they use. It is also good design for devices to communicate their limitations gracefully. (And before you respond with the patronising "you don't get it - you're an egghead" remarks or rhetorical questions about whether people should be forced to micromanage their device's resources, just bear in mind that I'm not advocating anything of the sort. Being able to disregard the mechanisms involved and to have a device juggle potentially excessive resource demands is a form of liberation for the user, but it becomes a form of frustration if the user demands more than the device can deliver without being warned about it in advance.) I don't really know why I'm having this discussion: I don't even have a smartphone, and the benefits of running multiple applications at a time on a phone would probably be marginal for me. But given that modern operating systems rely on multiple concurrently-running processes, I agree with the complainant that having the benefits already provided generally by the operating system (not something that can be said about those old Palm devices) stripped away in favour of an inferior solution providing fewer benefits specifically within a framework has led to a suboptimal experience for users and developers.
I beg to differ... Posted Dec 18, 2011 14:57 UTC (Sun) by khim (subscriber, #9252) [Link] But given that modern operating systems rely on multiple concurrently-running processes, I agree with the complainant that having the benefits already provided generally by the operating system (not something that can be said about those old Palm devices) stripped away in favour of an inferior solution providing fewer benefits specifically within a framework has led to a suboptimal experience for users and developers. Well, this was "obvious" for phone makers from the onset: BlackBerry, Symbian, Windows Phone - they all supported multitasking for more then a decade. But then someone decided to "strip these benefits" in the favor of "useless eyecandy". And people beat records repeatedly in a rush to buy these phones with "suboptimal experience for users and developers"... Don't you think that this is... kind of strage? "Suboptimal experience" leads to record sales, rave reviews in press, etc? IMO it just shows that people have different values and for most "true multitasking" is simply less valuable then "smooth hassle-less experience"...
I beg to differ... Posted Dec 19, 2011 22:08 UTC (Mon) by pboddie (subscriber, #50784) [Link]
You always beg to differ. However, even the original iPhone was a success for a few factors other than the eye candy, which it probably doesn't have that much of in comparison to the recent models. Take the serious treatment of Web browsing - a browser with a decent pedigree instead of the awful embedded browsers on most devices of the era - and the willingness to have both WLAN and GSM on the same device, plus the emphasis on Google services that I'm sure many people now wish to sweep under the carpet as if it never played a role in the success of that device.
Yes, sure. But how was Apple able to do that? Posted Dec 19, 2011 23:09 UTC (Mon) by khim (subscriber, #9252) [Link] Take the serious treatment of Web browsing - a browser with a decent pedigree instead of the awful embedded browsers on most devices of the era ...which Apple was able to offer because it knew browser can use all (or almost all) of the available memory since it'll be the only app running. and the willingness to have both WLAN and GSM on the same device Which was already old news at the time. iPaq 6315 in US and Nokia 9500 in the rest of the world offered the same capability three years earlier and in 2006 even midrange models like Samsung i730 and Nokia N80 had it. Sure, dual (GSM/WiFi) capability was important for iPhone but it was a means, not the goal. plus the emphasis on Google services that I'm sure many people now wish to sweep under the carpet as if it never played a role in the success of that device. Oh, sure, YouTube was pretty big attraction. But this just shows that you can not reach success by just blindly showing features in your phone. You need an attractive experience - and if you can not deliver it and multitasking at the same timeĀ then multitasking must go. You may reintroduce it later when platform will be more capable. Even so Apple was not quite ready to add full multitasking to iPhone 4: apparently it was still not powerful enough. They introduced checkpoint/restore system which is even more limited then Android's one. It's all about tradeoffs and if your system is not powerful enough to support both multitasking and smooth, pleasant, experience then most people will want pleasant experience.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 20:03 UTC (Fri) by yoush (subscriber, #38940) [Link]
> Would you like to mention your device, "rom" and applications?
SonyEricson sk17i
As for applications - I have several 10s installed. Especially bad in state saving is preinstalled browser, address book and mail client. As for others - Yandex maps (the most widely used russian maps app) looses state even if switching from it for a moment to read incoming SMS. Springpad looses dialog content even when turning from portrait to lanscape to type on hardware keyboard. There are many more but I don't remember right now.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 21:27 UTC (Fri) by khim (subscriber, #9252) [Link] Springpad looses dialog content even when turning from portrait to lanscape to type on hardware keyboard. If application loses state when you switch from portrait to landscape mode then it's definitely not a problem with Android task switching approach. Buggy applications can be created for any OS with any toolkit.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 22:07 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
actually, this is the same problem.
The android solution for the screen size changing is to have the application restart. This is a graceful restart as the application knows that it is happening and is given a chance to save it's state. The fact that it doesn't is a bug in the application, and reveals a place where the framework has sharp edges that make it easy for developers to mess up.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 17, 2011 10:52 UTC (Sat) by yoush (subscriber, #38940) [Link]
> and reveals a place where the framework has sharp edges that make it
> easy for developers to mess up
I'd rephrase that as - it's hard for developers not to mess up
2011: The Year of Linux Disappointments (Datamation) Posted Dec 18, 2011 1:57 UTC (Sun) by alankila (subscriber, #47141) [Link]
Yeah I agree, it seems like the views in the view tree do not have their states saved when activity is destroyed in between. Activities are not very often destroyed in normal usage conditions, but definitely when memory is low they will be. Maybe task killers would also very negatively impact usage experience.
Applications can relatively easily workaround the orientation change problem: they may use the 3.0+ fragments, which can be set to be retained across orientation changes, or they may use the configChanges manifest attribute to declare that they handle orientation changes of their own. Still, all this adds to lines of code that are not obviously necessary until you do end up with applications getting constantly killed.
It seems that ICS also has some developer options, such as "Don't keep activities", which destroys each activity as soon as user leaves it. It might help developers notice deficiencies in their state saving. Hopefully this problem gets better. At any event, radical changes to simplify developer experience are too often foiled because of backwards compatibility requirements.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 17, 2011 7:33 UTC (Sat) by salimma (subscriber, #34460) [Link]
Sadly Google's own built-in apps suffer from this as much as third-party apps. I've lost text in the SMS application as well as Google Voice -- and sometimes they miraculously get restored after a subsequent switch-to-different-app-and-back operation -- only after I've tediously retyped the lost message!
I like Android's multitasking model, myself, but there is an impedance mismatch between that model and programmer habit, it seems. I wonder if there's a good solution to this -- one starts running into Java language limitations, I suppose, since the easiest would be to use something like Scala mix-in to provide sane default behavior irrespective of a class' inheritance hierarchy
2011: The Year of Linux Disappointments (Datamation) Posted Dec 17, 2011 18:19 UTC (Sat) by rich0 (guest, #55509) [Link]
I'm sure that the windows 3.1 developer guidelines told developers to yield time, but that didn't make the lack of pre-emptive multitasking a feature.
The OS shouldn't rely on devs micomanaging so much. I shouldn't lose field input when I flip open my keyboard, and so on...
And I don't see that swap can't be done smartly. The program code can be re-read from disk, so all you need to swap is app data. Or be smarter about what you kill at the very least...
2011: The Year of Linux Disappointments (Datamation) Posted Dec 14, 2011 20:26 UTC (Wed) by sking (subscriber, #6062) [Link]
There is still some life in the OpenMoko Freerunner...
2011: The Year of Linux Disappointments (Datamation) Posted Dec 14, 2011 22:13 UTC (Wed) by alvieboy (subscriber, #51617) [Link]
Is it ?
I joined #gta02-core after failures open-sourcing the whole Neo Freerunner design. And the project is dead, primarily due to timing issues (iPhone was launched shorty before we started PCB design).
So, no, no way Freerunner is alive. And it won't kick. No way you can compete with Apple/Samsung/HTC HW manufacturing prices, nor with their software teams.
It's sad, but unfortunately true.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 1:02 UTC (Thu) by pabs (subscriber, #43278) [Link]
http://www.vanille-media.de/site/index.php/2011/12/13/it-...
There are plenty of gta02 users out there and the OpenMoko-originated community is still plugging away, porting its software to new devices.
Its true that you can't compete with the big proprietary guys on volume, users or anything except freedom. Bring on a phone running OsmocomBB on Debian on an OpenRISC or LM32 CPU!!!
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 20:43 UTC (Thu) by geuder (subscriber, #62854) [Link]
> No way you can compete with Apple/Samsung/HTC HW manufacturing prices,
Exactly. Not only volume manufacturing of the motherboard is an issue, but also mechanical and industrial design requires a lot of work. Make a smoothly opening slide and a mechanical keyboard, just as an example. At Nokia they have about 15 years experience and hundreds of mechanical engineers and huge environmental labs and plenty of test engineers. And still they do not always succeed as the N900 USB adapter misery shows. But any community design would be light years away from it.
So we would really need a nice mass device that has reasonably (re-)usable loaders and drivers (I don't even dream of completely open source)
I wonder why nobody has mentioned http://cordiatab.com/, yet another failure this year. (Or did I just miss it, this discussion gets a bit big and the original article wasn't a great reading exoerience either with all their floating, blinking and whatever ads on the page...)
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 0:45 UTC (Fri) by pixelpapst (guest, #55301) [Link] GTA04 seems to be pretty exciting ATM.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 6:24 UTC (Fri) by yoush (subscriber, #38940) [Link]
It is.
But inability to do that in a case close to n900's one, with hardware keyboard, makes this device much less attractive :(
2011: The Year of Linux Disappointments (Datamation) Posted Dec 14, 2011 20:36 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
You can buy N9's instead -- they will last you longer! (And are really, really wonderful. Although my N950 is even more wonderful, for me.)
More on topic, Bruce Willis is definitely right here.
If anything, he's underestimating how problematic 2011 will turn out to be, with the defection of Nokia and Intel and the disappearance of Sun.
Nokia was nurturing this whole ecosystem of smaller open source companies around Maemo and MeeGo, but now they have decided that instead of that being a success factor, the reason MeeGo failed was involving third party contractors, instead of doing everything in-house. I expect a lot of these companies to get into trouble in 2012. There's no way anyone is going to make money developing a virtual keyboard for MeeGo anymore.
Tizen is even more still-born than WebOS or MeeGo, if only because Samsung has always had the philosophy of doing everything in-house, sharing nothing, but also because Tizen is already making mistakes like assuming that Qt is just a widget toolkit, which can be replaced by something like EFL. And I'm seeing zero real investment in any area of Tizen.
OpenDocument was dealt a big blow when Oracle fired all OpenOffice people -- not to mention that losing all those developers for OpenOffice must be a hit -- no matter how upbeat the news about LibreOffice is presented. And yes, OpenDocument is important for the free desktop.
MeeGo's death means, basically, that the last chance to get real devices based on a open-source, Linux-based platform in the hands of paying consumers is gone. That chance we've blown -- in my opinion in no small measure thanks to infighting within people working on MeeGo. Just remember Arjen van de Ven's idiotic "remember, this is NOT a MeeGo device!" post on LWN when the N9 was finally announced.
And that means that I expect that organizing conferences like the Desktop Summit will become a lot more difficult, when there are no rich companies, like Intel and Nokia, that have a real interest in the Linux Desktop anymore.
Sponsorship for organizations like KDE e.V. and the Gnome Foundation will be more difficult. Less sponsorship means less sprints means less work done.
And finally, all the ear-splitting whining by hidebound fossils with chalk instead of red blood in their veins about all the wonderful new stuff free software's flagship projects like KDE, Gnome and Ubuntu have released this year makes the whole free software "community" feel like a horrible, soured, stagnant place to be, instead of a hotbed of innovation and just plain fun. Think of what that does for all our efforts to find new participants!
No, looking at the big picture, not a good year.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 14, 2011 21:21 UTC (Wed) by boog (subscriber, #30882) [Link]
Apologies for my own whining...
It is hard to avoid the conclusion that the whole desktop computing paradigm is shifting, with most casual users heading to mobile and online solutions, which, as you point out, are not open and have to a large extent reinvented the wheel rather than building on existing work. The huge economic crisis is certainly dampening the mood as well.
However, there is still going to be a nucleus of people that have to do real work with computers. I do expect free software to make slow progress in this group. The coming explosion of extraordinarily cheap and hackable computers (Raspberry Pi etc) may also help to open up a lot of hardware.
And as Bruce says: Debian is still plugging away.
Happy holidays...
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 2:10 UTC (Thu) by pboddie (subscriber, #50784) [Link] The coming explosion of extraordinarily cheap and hackable computers (Raspberry Pi etc) may also help to open up a lot of hardware. It remains to be seen what the consequences of Raspberry Pi specifically will be. The custodians of that project seem intent on silencing any discussion of openness: even though one might accept assertions that there is little practical benefit to be gained from knowing what the internal architecture of the proprietary video functionality is, there are serious questions about maintenance and sustainability raised by people like Alan Cox who deserve somewhat more than a brush-off and easily made assurances that binary blobs will be made available in a timely fashion for kernel updates. And from various oblique remarks from other communities one gets the impression that the exercise is some kind of loss-leader for Broadcom, right up until the point when various vested interests (do I have to name the corporation most likely to be affected?) intervene and attempt to subvert/direct the project to serve their own ends. That isn't to say that a lot of people won't buy Raspberry Pi as a very cheap gadget for doing stuff that they otherwise might be spending a fair amount more money on, which itself could be seen as a success for technology proliferation, but I have my doubts that the exercise will be sustainable. Naturally, other chipset vendors will pitch products at low prices, maybe even profitably, and we can only hope that some of them produce hardware that can be sustainably maintained indefinitely, not just for as long as the vendor deems necessary.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 5:04 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
for this to be a loss leader for broadcom they would need to be pricing this differently than they do for anything else.
while I don't like binary blob drivers, there are currently no fully open video drivers in the embedded space, so would you rather have the raspberry pi with binary blob drivers or no raspberry pi at all?
some people would rather have nothing rather than something with 'bad' drivers. I am not in that camp.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 13:03 UTC (Thu) by pboddie (subscriber, #50784) [Link] for this to be a loss leader for broadcom they would need to be pricing this differently than they do for anything else. At least in terms of the SoC pricing, they are apparently selling them below the usual price for the quantities involved. One of the obstacles for the open hardware movement is getting low quantities of components at reasonable prices. For example, the GTA04 device which replaces the Neo FreeRunner is expensive partly because they cannot commit to large volume production. while I don't like binary blob drivers, there are currently no fully open video drivers in the embedded space, so would you rather have the raspberry pi with binary blob drivers or no raspberry pi at all? I don't really have an opinion on whether I want the device at all. For a short window of time, my Intel desktop chipset was probably dependent on binary-only driver support, although I suppose that the driver converged once more with the published sources quite quickly, and one does what one needs to do to get one's hardware functional, but depending on binary drivers can be very inconvenient in my experience. We can only hope that open drivers eventually show up. Perhaps AMD's offerings and the embedded market might start to overlap a bit more.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 5:37 UTC (Thu) by gnu (subscriber, #65) [Link]
> The coming explosion of extraordinarily cheap and hackable computers
> (Raspberry Pi etc) may also help to open up a lot of hardware.
I am afraid, Raspberry Pi has a lot of proprietary hardware components as well (from Broadcom). I haven't seen any documentation of the main CPU on their website yet. I will be happy to be proved wrong. Without such information, I don't really buy the idea of "hackable computers".
One of the smallest and cheapest computer that runs GNU/Linux right now is the Beaglebone from TI. Sure, it also has some propreitary components like the 3D graphics. But most other parts are open, entire Technical Ref Manual is online.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 16:16 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
how do you define 'hackable computers'
if you define it as people being able to write new drivers for it, then the proprietary stuff is a problem.
however, if you look at a slightly wider picture than just the low-level drivers, the fact that everything else on the system has the source available and can be modified, and the machine is cheap enough for people to have their own and therefor not have to worry about breaking the family computer and interfering with other people, then this is very hackable.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 13:48 UTC (Fri) by nix (subscriber, #2304) [Link]
After all, consider the machines these are explicitly modelling themselves on, the Spectrums and C64s and Ataris and BBCs that launched the microcomputer revolution. These things had no publically visible schematics, the OS was closed and no-source-available, the language interpreter similarly, hell on the C64 almost all the hardware was undocumented. That didn't stop people: they picked it apart and wrote books about it and soon were doing amazing wizardly things with that mass of undocumented code.
My only worry is that the hardware even in a simple thing like the Raspberry Pi might be too complex for interested third parties to pick apart like that, or (worse yet) people who pick it apart might get hit with lawsuits. (Can you imagine what would have happened to the microcomputer revolution if Sinclair and Commodore and Acorn had had the same inclination to sue people for reverse engineering as some hardware companies have these days? There wouldn't have *been* a microcomputer revolution.)
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 17:47 UTC (Fri) by mpr22 (subscriber, #60784) [Link] It's worth noting that Commodore published as a general-availability item the Programmer's Reference Guide, which had (at least some) information about directly driving the SID and the VIC-II (including mentioning tricks like using the raster interrupt to get more than eight sprites at once), connector pinouts, and so forth. But yes, picking apart a modern graphics or sound chip would likely be a rather more... daunting endeavour than picking apart the VIC-II or the SID.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 20:01 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
while it didn't have a circuit diagram down to showing the individual caps on the motherboard, it did have quite detailed information on how the chips connected to each other and how to program them.
It didn't have the source for the OS, but it did have instructions for how to switch the ROM completely out of the address space and run whatever you wanted on the bare hardware.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 17, 2011 22:50 UTC (Sat) by nix (subscriber, #2304) [Link]
True. I'd forgotten that lovely contraption. But it wasn't long after that that people had cycle-accurate information about the SID chip, enough to fix the bugs in the book and annotate it extensively. Do that with a modern graphics card.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 17, 2011 15:35 UTC (Sat) by pboddie (subscriber, #50784) [Link]
The BBC Microcomputer and the Acorn Electron (and various derivatives) had their circuit diagrams published in their respective Advanced User Guide and in various datasheets. You didn't get the internal details of the ULA chips (although people are aiming to deconstruct them, just as has been done for the Spectrum fairly recently), but you got all the details of programming those chips via the memory locations corresponding to the externally exposed registers. You also got a fair amount of information about things like the system bus, interfaces, along with workarounds for various interfacing issues. I've seen circuit diagrams for various peripherals, including ones which may not have been sold to the public, and the only thing in doubt when considering the more formalised notion of sharing that we have today is whether these works were intended to be widely distributed and used. Certainly, some of these designs were adopted by third parties, products made from them were sold openly and widely, although I don't know what the licensing arrangements would have been, if there were any agreements in place at all.
It's true that the software was proprietary and Acorn did prevent someone publishing a book which contained a disassembly listing of their system software, and perhaps the largest regret is that the UK government didn't seek to mandate an open standard, even though that would have been very forward-looking at the time. These days, open source software and open standards are widely accepted and embraced, but it is the closed nature of hardware that often creates the biggest obstacles to having a completely open system.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 19:53 UTC (Fri) by boog (subscriber, #30882) [Link]
Clarifying/adding to my comment about hackable low-price computers. We have an expanding market of very cheap devices whose point is to be hacked, modified and reused in innovative ways. In this game, properly open systems will be at a huge advantage and I would expect them to win out (e.g. Arduino, Linux in embedded systems).
However, other posts are possibly correct that the Rasp. Pi itself will not be entirely open.
more Linux phone whining... Posted Dec 14, 2011 21:50 UTC (Wed) by geuder (subscriber, #62854) [Link]
> You can buy N9's instead -- they will last you longer!
I could, but I don't want to. I typed my comment above on my N900 on the bus, do you think I would have done that on an N9? Unfortunately some hardware properties can still not be done in software...
> Although my N950 is even more wonderful, for me.
I would buy one if I could. I thought about it when it was announced, but I decided to prefer a family life before hacking every night & weekend to qualify for one.
more Linux phone whining... Posted Dec 14, 2011 22:05 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
Yes, the n950 keyboard is in important reason for me to use that phone instead of the N9. But Harmattan MeeGo's virtual keyboard is really extremely good -- and I tend not to bother with the physical keyboard of the N950 even when using the terminal app a lot of the time!
more Linux phone whining... Posted Dec 15, 2011 17:38 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
The n9 keyboard is a fine soft keyboard, if any can be said to be, but it's no n900 hardware keyboard!
A lot of things in the n9 feel very "first release" and don't seem likely to get fixed. A related example: You normally don't have arrow keys on your keyboard and so there's no way to move the cursor without tapping, which means you're often left trying to stick your fat fingers in *just the right place* to delete a mis-typed character. At least the n900 had a stylus.
The n9 is a far more practical *phone* than the n900, but not nearly as nice a computer. From its "one big list of unsorted icons" launcher system, compared to four desktops of custom icons and a categorized menu, to the rather clunky way window management is handled, the n9 has a lot to disappoint an n900 fan.
At least it never takes me 20+ seconds to answer the ringing phone due to UI lag. That's something.
more Linux phone whining... Posted Dec 16, 2011 19:09 UTC (Fri) by mgedmin (subscriber, #34497) [Link]
4x the amount of RAM does that.
(Typed on my N9 with its wonderful software keyboard. The N950 with its hardware keyboard is lying in a drawer, forgotten. I know I'll get hate for this.)
more Linux phone whining... Posted Dec 16, 2011 20:05 UTC (Fri) by boudewijn (subscriber, #14185) [Link]
Not hate... But you might be able to sell your N950 for a considerable sum. When push comes to shove, these two devices really did deliver on their promise.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 16:45 UTC (Thu) by branden (subscriber, #7029) [Link] Bruce Willis?
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 18:51 UTC (Thu) by boog (subscriber, #30882) [Link]
Nathan Byfield ?
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 13:30 UTC (Fri) by sorpigal (subscriber, #36106) [Link] Slartibartfast?
2011: The Year of Linux Disappointments (Datamation) Posted Dec 17, 2011 22:43 UTC (Sat) by boog (subscriber, #30882) [Link]
"And finally, all the ear-splitting whining by hidebound fossils with chalk instead of red blood in their veins about all the wonderful new stuff free software's flagship projects like KDE, Gnome and Ubuntu have released this year"
I am a KDE user and I have complained a bit, so I do share some guilt here. But I don't think I'm a hidebound fossil and I could be convinced to keep an open mind on the innovations. However, as a user, the whole kde4 introduction has been disruptive. Not because my favourite non-standard way of doing things was changed but because quite basic work-essential components were genuinely degraded (examples: kaddressbook, printing). Things are a lot better now, but still not there yet.
I think a lot of the criticism that things like the semantic desktop are receiving reflect the associated regression in the usability of the rest of the suite (although the regression is not always caused by the innovation). If there were no disruption of their work, I don't think many people would be complaining.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 14, 2011 23:48 UTC (Wed) by drag (subscriber, #31333) [Link]
> Android might be based on the Linux kernel, but the end product is far from any FOSS spirit.
I am less concerned about the FOSS spirit and more concerned about FOSS code.
Android is one of the most successful open source operating systems of all time. It is the most widely used significant piece of open source software that more people come into direct day-to-day contact on their devices then any other software project like it before.
Within months of actual public release on devices it got more people using a OSS OS then entire decades worth of Linux on the desktop efforts.
It doesn't make sense to minimize it because people that are deploying it are not adherents to some sort of mythology of Unix or strict 'FOSS' ideology.
We don't want people releasing devices just because they think that GPL is the best thing since sliced bread. We don't want people that agree with us that it's just more moral to release and use open source software. We want people developing, distributing, and supporting open source/free software because it's simply _BETTER_ then any alternative. Once they learn why it's better then they will begin to value it more. The morality of it is advanced though profits, better software, and better devices.
There are problems with Android. But there are problems with everything. Success should not be minimized because it's not exactly what we wanted.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 13:21 UTC (Thu) by pboddie (subscriber, #50784) [Link] We don't want people releasing devices just because they think that GPL is the best thing since sliced bread. We don't want people that agree with us that it's just more moral to release and use open source software. We want people developing, distributing, and supporting open source/free software because it's simply _BETTER_ then any alternative. Once they learn why it's better then they will begin to value it more. The "use open source because it is technically better" argument has been a failure, not necessarily because open source software isn't technically better when compared to various proprietary solutions, but because people can quite easily identify a product that they think is technically best and then use that argument as a reason not to use open source software. That's how you end up with people using iPhones regarding Android as inferior (although I'm not sure I'd agree) and saying that they therefore don't see the point of open source. The argument mixes together two orthogonal things: the way something is made and shared, and the end product. The morality of it is advanced though profits, better software, and better devices. Certainly, people won't want to use things which might be more ideologically sound if there are nicer things that give them what they want right now, albeit with hidden costs that can be disregarded or overlooked, but the principal argument for open source and open solutions is one of sustainability. If you end up with a popular "open" system with lots of caveats about how difficult it is to customise, share, contribute to, influence or deploy, then it isn't such a great success for openness after all. I agree that getting people interested in something in one way and then letting them learn about the other aspects later can be beneficial, but the "morality of it" only occurs if people become aware of that second step and can take advantage of it themselves.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 15:31 UTC (Thu) by dgm (subscriber, #49227) [Link]
Better includes much more things than tech. People will use what's better for them, be it because it's more convenient, better looking, cheaper, open, or whatever. Different people do have different selection criteria.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 14:44 UTC (Thu) by clump (subscriber, #27801) [Link] Within months of actual public release on devices it got more people using a OSS OS then entire decades worth of Linux on the desktop efforts.This is misleading. The decades worth of Linux efforts you mention are the very reason Android has such a robust kernel to use. "Standing on the shoulders of giants", as it were.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 6:31 UTC (Thu) by rqosa (subscriber, #24136) [Link] > the end product is far from any FOSS spirit It seems like you're conflating the "Bazaar" development model with "FOSS". It doesn't matter much if Android isn't a Bazaar-style project as long as its code is FOSS-licensed, because then Bazaar-style projects based on Android code (e.g. CyanogenMod and Replicant) can (and will) arise.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 6:48 UTC (Thu) by geuder (subscriber, #62854) [Link]
>> the end product is far from any FOSS spirit
> It seems like you're conflating the "Bazaar" development model with "FOSS".
No, that was not my main point. My point was and is it does not match well with user's freedoms if your data is largely controlled by one corporation.
Disclaimer 1: I don't own an Android product, I just rely on press information that you need an Google account to use the phone.
Disclaimer 2: I have not tried to read the source code. Are really all parts that communicate with Google's servers open source?
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 9:47 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> Disclaimer 1: I don't own an Android product, I just rely on press information that you need an Google account to use the phone.
From what I have heard, no you don't. You can skip the account creation process, and you only lose use of the Google apps. This includes the market, but you can use alternative markets like for instance http://f-droid.org/ (which is an Android market exclusively for free software).
> Disclaimer 2: I have not tried to read the source code. Are really all parts that communicate with Google's servers open source?
No, they are more like closed-source pre-installed applications on top of Android. In fact, if you build Android yourself (from https://source.android.com/), you will be missing all these Google apps. From what I have heard, users of alternative Android firmware have to either backup them from their phone/tablet's original firmware, or get a copy of them from shady locations somewhere in the Internet.
Original manufacturers have to make sure the device matches Google's Android compatibility definitions, and then license these apps from Google (take a look at https://source.android.com/compatibility/index.html).
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 1:22 UTC (Fri) by rqosa (subscriber, #24136) [Link] >> It seems like you're conflating the "Bazaar" development model with "FOSS". > No, that was not my main point. My point was and is it does not match well with user's freedoms if your data is largely controlled by one corporation. As long as the code is FOSS-licensed, the upstream developer (Google) can't take away users' freedoms, including the freedom to not have their data controlled by Google — even if there are things in upstream Android that "phone home" (I haven't actually used Android yet, so I don't know firsthand, but see the poster above who says that only the Google apps that aren't part of Android itself do that), the user can avoid them by using a third-party Android distribution or by compiling their own one. (Of course, this does imply that non-locked-down hardware is necessary for users to exercise the freedoms guaranteed by the software's licence — just as it always has been. So we always must demand that non-Tivoized devices be available in the marketplace, and resist any attempts to Tivoize desktop/notebook/server hardware.)
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 2:43 UTC (Fri) by aryonoco (subscriber, #55563) [Link]
> Disclaimer 1: I don't own an Android product, I just rely on press information that you need an Google account to use the phone.
No you don't. The information you have relied on has been incorrect. It is more than possible, and usable, to use Android without a Google account. You will lose access to Market, but there are many Market alternatives out there.
> Disclaimer 2: I have not tried to read the source code. Are really all parts that communicate with Google's servers open source?
Everything (other than a few binary blobs) is open source. There are some proprietary Google applications which come bundled with most Android phones (like Market, Gmail, etc) but they are not part of the core platform.
If you buy a Nexus phone, you can unlock it and put your own Android ROM built from source on it. Other than some binary blobs used for drivers, everything else is open source.
I really don't get how Maemo was ever more "open" than Android. Sure Android doesn't follow a Bazaar development model, but for all intents and purposes, neither did Maemo/Meego.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 16, 2011 5:56 UTC (Fri) by jmalcolm (guest, #8876) [Link]
You do not get the code to many Google "apps" but the entire Android OS source code is available.
Android is most certainly Open Source. I can, for example, use only third-party (non-Google) distributions of Android if I like. For example, I could put Cyanogen on my Nook Color. I can also run Android on an x86 machine. I am free to modify the code and port it to whatever system I like and to adapt it to talk only to systems and/or corporations that I approve of. I could completely fork it and go my own way if I really wanted to. In fact, it looks to me like Amazon has done exactly that. All the freedom of Open Source is there.
However, Android is not developed in the bazaar fashion that many FLOSS types (myself included) prefer. That said, there is pretty good evidence that regular consumers will prefer an ecosystem where Google is a bit more opinionated about how Android evolves and a more cathedral-like in their approach to development.
I am very grateful for the gift that Android represents. I also consider what Google is doing as better than Open Core critical parts of the software stack are fully closed. If more companies developed software in the Google way, as opposed to fully closed, the world would be a better place.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 8:00 UTC (Thu) by lkundrak (subscriber, #43452) [Link]
Last time I checked, my software stack did not include spirit.
2011: The Year of Linux Disappointments (Datamation) Posted Dec 15, 2011 8:18 UTC (Thu) by viro (subscriber, #7872) [Link]
Conventional term is "my wetware stack" and as far as I know nobody has any idea how to check whether spirit is a part of it or not ;-)
|
|||||||||||||