also check the android mythbusters presentation by matt porter: http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=get&target=Mythbusters_Android.pdf
We can carp at Google all we like, but I saw Matt Porter give his myth-busters talk and it was not in any way anti-android. The point of his talk was to debunk the idea that android was perfect, not to say it had little or no worth. He pointedly said it was the work of a team with tight release schedules. The 'sticky-tape' in chrome will be the same.
We should be concentrating more on the disruptive and innovative nature of this OS, on Googles sales pitch and impressive channels. Lambasting them for a few mistakes in the rather dull internals is uber geek talk.
Anonymous: the correct to do this during development would be to enable HAL, and then work on porting Xorg to udev. They chose to hack their ways into a “solution” instead.
Mark: I certainly wouldn't trust my data to an OS that's put together so hackily. The way the problems are solved shows that they don't know what they're doing at the OS level, it reads like people's work-arounds on forums.
Hacking around upstream doesn't really make me feel that “Google will be a good upstream citizen” as it was put during the press conference.
Lennart: that's because they remove pulseaudio from their builds: http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromiumos.git;a=blob;f=src/scripts/customize_rootfs.sh#l164
Why the hate for xscreensaver? It's been working with far less drama than gnome screensaver for a very long time, and if you only want blank blanking.... Why not?
It's weird that you and mjg59 and others think this is a generic distro like bunty or fedora. It's not ;) embedded people make decisions like this *all the time* and hard code them.
Also you have a year to get commit access to chromium if you want to force hal into a system that doesn't need it ;)
xscreensaver is based on antiquated libraries, and they don't only use it for DPMS, they also use it for screen-locking. a gnome-screensaver with a custom greeter written in Clutter would have done them just fine (and they could ship a stripped-down version of the GTK+ dialogue in the meanwhile). They already use D-Bus, and glib.
As for the excuse that it's an embedded distro, the target is a netbook. It looks to me like a stripped-down distro, just like a number of spins and remixes for various distros.
See my answer to Mark about the HAL problem. They still have a Xorg depending on libhal. Really, what's the point of such hacks when you could have stripped down HAL, or started work on replacing HAL with udev in xorg...
Embedded people do this all the time because they're stuck in the mindset that they only have to release one product and will never have to port to different hardware. As a result we end up with hideous failures like basically every other Linux netbook distribution, where each new device needs a different set of mad hacks rather than using the (already existing!) generic interfaces that'd let it just work.
haddess said... "xscreensaver is based on antiquated libraries, and they don't only use it for DPMS, they also use it for screen-lockin"
those are exactly the things xscreensaver has been doing for *years* with some very stable libraries that everyone has. Writing a clutter thing to sit on top of gnome screensaver seems like an odd amount of work for one critical text entry box on an otherwise black screen.
haddess/matt: I don't disagree that the situation sucks, by any means. Perhaps some of it is a lack of knowledge among the embedded developers about the interfaces they can/should use. Google have a year to figure out that they're including a hal library they don't need, but if they don't want to use hal then all they're losing is a tiny chunk of diskspace, right? It works on the hardware they'll care about because they'll test that hardware. Perhaps you guys should get jobs at companies doing embedded linux projects and make sure they DTRT. Or maybe matt could stab the kernel arm people into making life at least slightly easy for the enablement folks with device trees or something else that would work better ;)
(also Matt, fwiw, I think we try to keep Ubuntu Netbook Edition as free of hacks as is possible so it runs on all the machines listed at https://wiki.ubuntu.com/HardwareSupport/Machines/Netbooks but that's i386 stuff. I bet the kernel will force the ARM situation to be far less friendly).
I think this just once more shows our general problem. With the fast pace of changing technologies, no one really knows anymore what is the current technology of the art. E.g. what stays and what is deprecated.
Therefore the developer has three possibilities.
Do a thorough research come up with the preferred solution (maybe with the need to port some things...) but taking a vast amount of time which makes his boss angry since he wasted valuable time.
Do a quick research and maybe chose a technology which is already abandoned. This makes his boss only marginally happier since it still took too long. And the community will point their fingers at you if it happened you chose some abandoned technology.
Or just hack a little bit and make his boss happy since he has visible results in a few hours. The community will still point at him, but who cares since he just got a salary increase due to his efficiency.
Ok, these examples are a little bit black and white. But I hope to show my point. What's the point in doing the right thing if it is a) very hard and b) does not give you an adequate reward.
So I think the only thing the community could do is to make it easier to choose the right technology. E.g. by creating a centralized documentation of what is deprecated and what not. And making it faster to use the preferred technologies than any of the old stuff. E.g. by creating more sample code which can be reused.
11 comments:
also check the android mythbusters presentation by matt porter: http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=get&target=Mythbusters_Android.pdf
if you read the justification of a static xorg.conf, it actually makes sense during development.
We can carp at Google all we like, but I saw Matt Porter give his myth-busters talk and it was not in any way anti-android. The point of his talk was to debunk the idea that android was perfect, not to say it had little or no worth. He pointedly said it was the work of a team with tight release schedules. The 'sticky-tape' in chrome will be the same.
We should be concentrating more on the disruptive and innovative nature of this OS, on Googles sales pitch and impressive channels. Lambasting them for a few mistakes in the rather dull internals is uber geek talk.
Anonymous: the correct to do this during development would be to enable HAL, and then work on porting Xorg to udev. They chose to hack their ways into a “solution” instead.
Mark: I certainly wouldn't trust my data to an OS that's put together so hackily. The way the problems are solved shows that they don't know what they're doing at the OS level, it reads like people's work-arounds on forums.
Hacking around upstream doesn't really make me feel that “Google will be a good upstream citizen” as it was put during the press conference.
I also like how they are hardcoding the mixer element names in their acpi event scripts...
Lennart: that's because they remove pulseaudio from their builds:
http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromiumos.git;a=blob;f=src/scripts/customize_rootfs.sh#l164
Why the hate for xscreensaver? It's been working with far less drama than gnome screensaver for a very long time, and if you only want blank blanking.... Why not?
It's weird that you and mjg59 and others think this is a generic distro like bunty or fedora. It's not ;)
embedded people make decisions like this *all the time* and hard code them.
Also you have a year to get commit access to chromium if you want to force hal into a system that doesn't need it ;)
Chris:
xscreensaver is based on antiquated libraries, and they don't only use it for DPMS, they also use it for screen-locking. a gnome-screensaver with a custom greeter written in Clutter would have done them just fine (and they could ship a stripped-down version of the GTK+ dialogue in the meanwhile). They already use D-Bus, and glib.
As for the excuse that it's an embedded distro, the target is a netbook. It looks to me like a stripped-down distro, just like a number of spins and remixes for various distros.
See my answer to Mark about the HAL problem. They still have a Xorg depending on libhal. Really, what's the point of such hacks when you could have stripped down HAL, or started work on replacing HAL with udev in xorg...
Chris:
Embedded people do this all the time because they're stuck in the mindset that they only have to release one product and will never have to port to different hardware. As a result we end up with hideous failures like basically every other Linux netbook distribution, where each new device needs a different set of mad hacks rather than using the (already existing!) generic interfaces that'd let it just work.
haddess said...
"xscreensaver is based on antiquated libraries, and they don't only use it for DPMS, they also use it for screen-lockin"
those are exactly the things xscreensaver has been doing for *years* with some very stable libraries that everyone has. Writing a clutter thing to sit on top of gnome screensaver seems like an odd amount of work for one critical text entry box on an otherwise black screen.
haddess/matt: I don't disagree that the situation sucks, by any means. Perhaps some of it is a lack of knowledge among the embedded developers about the interfaces they can/should use. Google have a year to figure out that they're including a hal library they don't need, but if they don't want to use hal then all they're losing is a tiny chunk of diskspace, right? It works on the hardware they'll care about because they'll test that hardware.
Perhaps you guys should get jobs at companies doing embedded linux projects and make sure they DTRT. Or maybe matt could stab the kernel arm people into making life at least slightly easy for the enablement folks with device trees or something else that would work better ;)
(also Matt, fwiw, I think we try to keep Ubuntu Netbook Edition as free of hacks as is possible so it runs on all the machines listed at https://wiki.ubuntu.com/HardwareSupport/Machines/Netbooks but that's i386 stuff. I bet the kernel will force the ARM situation to be far less friendly).
I think this just once more shows our general problem. With the fast pace of changing technologies, no one really knows anymore what is the current technology of the art. E.g. what stays and what is deprecated.
Therefore the developer has three possibilities.
Do a thorough research come up with the preferred solution (maybe with the need to port some things...) but taking a vast amount of time which makes his boss angry since he wasted valuable time.
Do a quick research and maybe chose a technology which is already abandoned.
This makes his boss only marginally happier since it still took too long. And the community will point their fingers at you if it happened you chose some abandoned technology.
Or just hack a little bit and make his boss happy since he has visible results in a few hours. The community will still point at him, but who cares since he just got a salary increase due to his efficiency.
Ok, these examples are a little bit black and white. But I hope to show my point. What's the point in doing the right thing if it is a) very hard and b) does not give you an adequate reward.
So I think the only thing the community could do is to make it easier to choose the right technology. E.g. by creating a centralized documentation of what is deprecated and what not. And making it faster to use the preferred technologies than any of the old stuff. E.g. by creating more sample code which can be reused.
Post a Comment