I like OpenOffice and I think that's definitely the right way to do it. But I think the primary motivation and the wording of the bill should reflect the intent, not the technology. (I admit, however, to not reading the real bill so I could be mistaken).
The point is that we want a truly open standard that multiple companies, organizations, and of course free software folk can gain access to and write software for... worded in such a way as to prevent the standard from having lots of unsupportable bloat (ie. Microsoft's model). ODF happens to be a very good choice right now because of its wide-spread use and the fact that OpenOffice is a fairly mature reference implementation. But at the political level, the argument shouldn't be about the underlying technology.
If you're concerned about the adoption of alternative Desktop's, whether it's Linux-based (or more accurately has a large Linux population) is irrelavent. In fact, it seems relatively simple for GNOME apps to run on Windows. I imagine someone's got (or is working on) porting the entire GNOME environment for Windows as well.
The question really is why do OSS Desktops currently suck? Why does GNOME insist on taking away features or cloning the bad features of Windows that Windows doesn't even use anymore. I haven't used KDE in a while, but I felt KDE lacked a bit of coherency in the apps.
In addition, why are all the desktop OS's playing catchup, and still using outdated models of "icons" as bitmap images? Why couldn't an "icon" be composed of 3D rendered animation with sound effects, and an understanding of user/desktop/system events? eg. an icon that "schwings" whenever the app is loaded (whether it was loaded via the icon or some other way). That's just an example of course. But the closest desktop I know of to do anything like that is OS X.
The GNOME and KDE people have been copying and working towards the Windows model. The original X and Unix designs were great because of their customization and features and the network-centric design. To this day, I'm not sure GNOME particularly likes it if you have two desktops running off the same network share. (It works, but I'm not sure it works as well as it should.) I can't speak for KDE, not having used it in a while.
The obvious problem with having lots of customizable features is that it overwhelms the user. The solution was not to remove all the features (a la GNOME). The solution was to create customizable "profiles". So that users can simply say whether they are a "novice" or "developer" or whatever. This allows beginners to "just use" the system. And advanced users to tweak to their hearts content. A very scalable system.
Who develops these profiles? Well, the author of the software certainly could. But I imagine what would have happend is that each distribution has in mind various groups of people they target. So the distribution makers would take the job of deciding what sets of features their audience prefers.
Don't underestimate the power of this in a network environment either. Any company, school, etc. will likely want a certain set of default profiles for their audience. Being able to customize this to their own environment is exactly what makes Windows such a pain to administer. Unix makes this easier with text based config files. But having a profile infrastructure would make it a no-brainer.
Unfortunately, it seems like the Linux desktops haven't had any focus in this direction, choosing instead to emulate the single-user mentality of Windows. The last version of GNOME I really liked was 1.0. Since then I've cared less whether I was in Linux or Windows because they're both irritating in the same ways now.
Complaints aside, I'm quite pleased with the way these projects have developed (or fostered development) of things like DBUS and the way we handle auto drive mounting, etc. The GNOME font rendering engine is also quite nice, if a bit slow.
Actually that's not true. If you're planning on supporting Windows 95/98/2000/XP, you still need to test across each one. This is especially true if you're planning on supporting both the 95/98 and 2000/XP eras as they're radically different systems.
I have no problems with people wanting to use the SDK in other distributions. But we have to pick and choose which ones we want to test with and "gaurantee" will work. Also, SDK may have been a poor choice of words, as it includes a build environment (toolchain, scripts, etc.) to make it easier for developers working with our kit. This will include many different tools that might depend on various system utilities, scripts, and libraries. Version incompatabilities, and differences in even the location of binaries could cause problems. So in effect, the distribution really does matter.
It's cool that you built your own toolchain and such. From what I've gathered, though, most people in the embedded space don't like to do that, as they want/need to get on with their actual project. I don't mean that in any disparaging way, I've gone through a lot of trouble getting our toolchain compiled in a nice way for our kit, so I know how much work is needed to do that.
Our SDK does have binaries for GCC. But we also have a number of build tools that make up the environment. Some of these may depend on other things on the system, eg. python, libxml and the like. So while I'll happily include tarballs for people not using our recommended distribution(s), we still do need to pick something and test with it.
On the other hand, consider a note such as: "Here at XYZ corp, we have standardized on Fedora Core 6, with several older Fedora linux machines still in use. While we have no reason to believe our environment won't work on any reasonable linux, and while we will try to assist you, please understand that we may not be able to replicate your problems if you are not using Fedora."
This is in fact the sort of support I'd vote for as well. What I actually meant with the question, though, was what distribution(s) should we test our build environments in. I'm personally using Fedora Core 5, but what're others in this field using?
When I speak of "support" for a distribution I'm talking more about testing to ensure the SDK works out of the box. I have no intention of forcing our SDK to be tied to any given distribution. And I agree it'd be great if it worked on all distros. But the fact is, it's unreasonable for most companies to test across many distros and versions of distros like that, especially ones that actual developers in our market don't use. Hence my initial question... (which ones do people use?)
Also, when I talk about the SDK, I'm not speaking mearly of tarballs of C compilers and libraries. There's a number of convenience scripts and tools we've added to give you a nice easy to use development environment. This of course relies on a number of system tools and libraries being available. Some of them standard, some not.
I can of course add these tools as part of the SDK. But going that route quickly ends up in making your own distribution. At this point it makes sense to just take a distribution and use that.
This has been a big issue for me ever since GNOME's goal became removing all useful features, and in fact, cloning the particularly bad features of Windows (okay, maybe I'm a little bitter; that's another story anyway).
What's always been great to me for the Unix world is having lots of choices and lots of customization. What I didn't like was being forced to go through the configuration process if I didn't want to. So of course, having "reasonable" defaults makes sense. Back in the early days of Linux and especially before Linux, there was lots of software and each generation became more configurable. And of course there was usually a separation between user configurations and system configurations. This made it possible for system administrators to determine the "reasonable defaults" for the organization, while also allowing users to make changes if they so desired.
Then Linux came on the scene and the landscape changed a little. We didn't necessarily have system administrators tied to networks of Unix systems. Instead we had lots of individuals who may not have had much experience with system adminitration, and may not have cared to serve that role. But, with Linux came Linux distributions. And the makers of these distributions offered various "reasonable defaults" catered to different audiences. From novice to advanced, they just had to pick their distribution.
Of course advanced users were still always allowed to tailor their choices. But what made all of this possible was the fact that the original software developers had in mind, keep the software flexible and don't assume the user will use the software the way you intended. If all the software was made in GNOME's or Windows' "one-size-fits all" strategy, then none of these distributions would be possible and you end up going after the least common denominator.
How does this all relate to the real world? Well, how many choices for soap do you have when you go to the supermarket? Does anyone get particularly confused about that? If you've lived in a democratic/capitalist society all your life, then the answer is probably no. You probably just get used to a particular brand, and start equating that brand with the type of quality/cost/etc. that you like. If you really did care about the ingredients of the soap and exactly want to know that you're getting the best cleaning power per ounce, of course you can figure that out. And if that were a big enough market, a company would probably start a brand that focuses on people like you. Or even if it wasn't a big enough market... maybe there's just a market for people interested a "distribution list" of sorts, showing what the best value for your money for a wide range of products (think Consumer Reports). Sound familiar? Redhat/Debian/Ubuntu/etc. are just that sort of distribution list... they just happen to be able to give away their final decisions in the form of usable products.
However, if you grew up in a communist society with little or no choices, then suddenly get exposed to this new world, of course you're going to feel a little overwelmed. There's a culture shock there that takes time to get used to. In fact, you may even feel like you don't want to make choices anymore, even if you end up with a worse solution than you could have otherwise had. But in that case, just choose the one with the prettier box or the lowest price tag.
Personally, I think more choices is better. But of course maybe I like choose my tradeoffs more than others.
We've gone through many raid controllers (DPT SCSI, ICP Vortex, Arco IDE, 3Ware Escalade). And _every_ single time we've had any problems it was due to the raid controller. Another problem with hardware raid controllers is that they like to format the card their own special way. So if you don't have the same card and firmware, you may not be able to retreive your data if the card dies. (I haven't tested this for a number of hardware RAID 1 solutions, though. It's definitely true for RAID5). However, any ext2/3 partition on a linux software raid can be taken out of the raid set (or whatever system it was in), and be placed in another linux system and can be used as a just a regular partition with all data intact.
On a similar subject, we've also had real bad luck with linux data integrity in general when handling large files (>500MB). I've seen this problem on both low-end IDE drives as well as high end (5 year warranty) hot-swap SCSI drives. I've mailed the IDE driver author on this (when I thought it was an IDE-only problem), but received no comment. I suppose I should post it to the kernel list.
In any case, for anyone interested, I submitted a test program "writetest" to the Linux Test Project for anyone interested. Just give it a really large block size (a 1GB file is generally large enough) and repeat about 10 times. I wouldn't mind hearing from people on what they see on various mb/chipset combos. Some controllers/motherboards have problems, others don't.
I've been meaning to collect more statistics and such between the different versions and using different video drivers (eg. NVidia vs. open-source). However, my preliminary tests show that rendering text in a gnome-terminal under Fedora Core 2 is a little over 2x slower than an equivalent Redhat 7.3 machine running Ximian Desktop 2. And about 14x slower than xterm with jump scroll turned on.
What this equates to is a slowdown of any process that's spitting out text, including compiling the kernel (2.6 is an exception since they reduced the amount of screen clutter).
Note that minimizing a window doesn't help either. Everything takes pretty much the same amount of time. The old 'xterm' is a little more intelligent about minimizes, though.
I'd like to see a good book on writing backends to gcc so that you don't also have to write your own VM compiler. I have the Using and Porting GCC book, and admittedly I've yet to really sit down and go through it thoroughly, but it doesn't seem to make it plainly obvious to me just how you make gcc aware of what opcodes your system needs.
I recently started using the Galeon browser, and I really like it's ability to open new urls into a tabbed window and have the ability to move tabs (fairly) easily between windows. This feature has been slowly growing over the years in a few specialized apps (eg. powershell and screen).
It occurred to me that this would be an awesome feature for a window manager. While I personally use screen in an xterm all the time, it doesn't allow you to virtualize windowed apps. And it would reduce the unnecessary duplication of effort in each individual app.
I've often thought that all daemons/services running on a system should run in their own chroot'd environment when available (not just ftp). Everything from mail to pop to echo.
Also, every service app (preferabbly all apps period) should be distributed with a list of what system calls it's allowed to perform and what files/directories it's allowed to read/write from/to. Likewise, all distributions should be based off of NSA's SecureLinux to take advantage of this list.
On a semi-related note, I'd even like to see a system where the entire chrooted environment is encrypted. Only services allowed to access these directories are given the secretkeys/tokens (maybe something kerberos-like) that allow them to read/write to these diretories. This would allow for systems where even the system administrator may not be trusted by users (to the extent that the sysadmin didn't modify the kernel, anyway).... for example if the secret key for a user's home directory is their password... then only the user, when he logs in, will be able to decode his files.
All this of course isn't a replacement for good programming practices. But I think it's a good failsafe, in case the usual measures don't stop the bad programs.
I've thought about this problem many times. And this is what I've come up with. There is a difference between broadcast mediums and private mediums (which I define as point-to-point, from one person to another). Television, radio, etc. are all broadcast mediums, a single source to many people. Email, phone, etc. are all point-to-point... you can send the same message to a bunch of people, but you have to do it individually.
Mailing lists, then, could be considered a broadcast medium, depending on the list.
So, given this distinction, I think it's fairly clear that unsolicited marketing is not acceptable in a point-to-point system. Yes, you can use the "opt-out" method that people described already, and that's already in place. But the problem here is that you simply can't account for all the people that will call you. And they will. They always do. Even the guy who said he contacted the DMA group said he still gets at least 1 call every year.
Freedom of speech is important. But it doesn't give you the right to convey this speech any way you want. You can't convey your speech through a blowhorn in someone's ear. You can't follow some guy around all day until he gives in to your views. So the issue of "freedom of speech" isn't as much of an issue as the "method of speech".
Slashdot Mirror
I like OpenOffice and I think that's definitely the right way to do it. But I think the primary motivation and the wording of the bill should reflect the intent, not the technology. (I admit, however, to not reading the real bill so I could be mistaken).
The point is that we want a truly open standard that multiple companies, organizations, and of course free software folk can gain access to and write software for... worded in such a way as to prevent the standard from having lots of unsupportable bloat (ie. Microsoft's model). ODF happens to be a very good choice right now because of its wide-spread use and the fact that OpenOffice is a fairly mature reference implementation. But at the political level, the argument shouldn't be about the underlying technology.
If you're concerned about the adoption of alternative Desktop's, whether it's Linux-based (or more accurately has a large Linux population) is irrelavent. In fact, it seems relatively simple for GNOME apps to run on Windows. I imagine someone's got (or is working on) porting the entire GNOME environment for Windows as well.
The question really is why do OSS Desktops currently suck? Why does GNOME insist on taking away features or cloning the bad features of Windows that Windows doesn't even use anymore. I haven't used KDE in a while, but I felt KDE lacked a bit of coherency in the apps.
In addition, why are all the desktop OS's playing catchup, and still using outdated models of "icons" as bitmap images? Why couldn't an "icon" be composed of 3D rendered animation with sound effects, and an understanding of user/desktop/system events? eg. an icon that "schwings" whenever the app is loaded (whether it was loaded via the icon or some other way). That's just an example of course. But the closest desktop I know of to do anything like that is OS X.
The GNOME and KDE people have been copying and working towards the Windows model. The original X and Unix designs were great because of their customization and features and the network-centric design. To this day, I'm not sure GNOME particularly likes it if you have two desktops running off the same network share. (It works, but I'm not sure it works as well as it should.) I can't speak for KDE, not having used it in a while.
The obvious problem with having lots of customizable features is that it overwhelms the user. The solution was not to remove all the features (a la GNOME). The solution was to create customizable "profiles". So that users can simply say whether they are a "novice" or "developer" or whatever. This allows beginners to "just use" the system. And advanced users to tweak to their hearts content. A very scalable system.
Who develops these profiles? Well, the author of the software certainly could. But I imagine what would have happend is that each distribution has in mind various groups of people they target. So the distribution makers would take the job of deciding what sets of features their audience prefers.
Don't underestimate the power of this in a network environment either. Any company, school, etc. will likely want a certain set of default profiles for their audience. Being able to customize this to their own environment is exactly what makes Windows such a pain to administer. Unix makes this easier with text based config files. But having a profile infrastructure would make it a no-brainer.
Unfortunately, it seems like the Linux desktops haven't had any focus in this direction, choosing instead to emulate the single-user mentality of Windows. The last version of GNOME I really liked was 1.0. Since then I've cared less whether I was in Linux or Windows because they're both irritating in the same ways now.
Complaints aside, I'm quite pleased with the way these projects have developed (or fostered development) of things like DBUS and the way we handle auto drive mounting, etc. The GNOME font rendering engine is also quite nice, if a bit slow.
Actually that's not true. If you're planning on supporting Windows 95/98/2000/XP, you still need to test across each one. This is especially true if you're planning on supporting both the 95/98 and 2000/XP eras as they're radically different systems.
That's a fine idea, but if you had to pick one distribution to be your host platform, what would it be for this "perfect embedded linux distro"?
I have no problems with people wanting to use the SDK in other distributions. But we have to pick and choose which ones we want to test with and "gaurantee" will work. Also, SDK may have been a poor choice of words, as it includes a build environment (toolchain, scripts, etc.) to make it easier for developers working with our kit. This will include many different tools that might depend on various system utilities, scripts, and libraries. Version incompatabilities, and differences in even the location of binaries could cause problems. So in effect, the distribution really does matter.
It's cool that you built your own toolchain and such. From what I've gathered, though, most people in the embedded space don't like to do that, as they want/need to get on with their actual project. I don't mean that in any disparaging way, I've gone through a lot of trouble getting our toolchain compiled in a nice way for our kit, so I know how much work is needed to do that.
Our SDK does have binaries for GCC. But we also have a number of build tools that make up the environment. Some of these may depend on other things on the system, eg. python, libxml and the like. So while I'll happily include tarballs for people not using our recommended distribution(s), we still do need to pick something and test with it.
On the other hand, consider a note such as: "Here at XYZ corp, we have standardized on Fedora Core 6, with several older Fedora linux machines still in use. While we have no reason to believe our environment won't work on any reasonable linux, and while we will try to assist you, please understand that we may not be able to replicate your problems if you are not using Fedora."
This is in fact the sort of support I'd vote for as well. What I actually meant with the question, though, was what distribution(s) should we test our build environments in. I'm personally using Fedora Core 5, but what're others in this field using?
Guess I should have added more info in my original post.
The question actually was asking what Host distribution we should support, not what Embedded targets to compile for.
When I speak of "support" for a distribution I'm talking more about testing to ensure the SDK works out of the box. I have no intention of forcing our SDK to be tied to any given distribution. And I agree it'd be great if it worked on all distros. But the fact is, it's unreasonable for most companies to test across many distros and versions of distros like that, especially ones that actual developers in our market don't use. Hence my initial question... (which ones do people use?)
Also, when I talk about the SDK, I'm not speaking mearly of tarballs of C compilers and libraries. There's a number of convenience scripts and tools we've added to give you a nice easy to use development environment. This of course relies on a number of system tools and libraries being available. Some of them standard, some not.
I can of course add these tools as part of the SDK. But going that route quickly ends up in making your own distribution. At this point it makes sense to just take a distribution and use that.
This has been a big issue for me ever since GNOME's goal became removing all useful features, and in fact, cloning the particularly bad features of Windows (okay, maybe I'm a little bitter; that's another story anyway).
What's always been great to me for the Unix world is having lots of choices and lots of customization. What I didn't like was being forced to go through the configuration process if I didn't want to. So of course, having "reasonable" defaults makes sense. Back in the early days of Linux and especially before Linux, there was lots of software and each generation became more configurable. And of course there was usually a separation between user configurations and system configurations. This made it possible for system administrators to determine the "reasonable defaults" for the organization, while also allowing users to make changes if they so desired.
Then Linux came on the scene and the landscape changed a little. We didn't necessarily have system administrators tied to networks of Unix systems. Instead we had lots of individuals who may not have had much experience with system adminitration, and may not have cared to serve that role. But, with Linux came Linux distributions. And the makers of these distributions offered various "reasonable defaults" catered to different audiences. From novice to advanced, they just had to pick their distribution.
Of course advanced users were still always allowed to tailor their choices. But what made all of this possible was the fact that the original software developers had in mind, keep the software flexible and don't assume the user will use the software the way you intended. If all the software was made in GNOME's or Windows' "one-size-fits all" strategy, then none of these distributions would be possible and you end up going after the least common denominator.
How does this all relate to the real world? Well, how many choices for soap do you have when you go to the supermarket? Does anyone get particularly confused about that? If you've lived in a democratic/capitalist society all your life, then the answer is probably no. You probably just get used to a particular brand, and start equating that brand with the type of quality/cost/etc. that you like. If you really did care about the ingredients of the soap and exactly want to know that you're getting the best cleaning power per ounce, of course you can figure that out. And if that were a big enough market, a company would probably start a brand that focuses on people like you. Or even if it wasn't a big enough market... maybe there's just a market for people interested a "distribution list" of sorts, showing what the best value for your money for a wide range of products (think Consumer Reports). Sound familiar? Redhat/Debian/Ubuntu/etc. are just that sort of distribution list... they just happen to be able to give away their final decisions in the form of usable products.
However, if you grew up in a communist society with little or no choices, then suddenly get exposed to this new world, of course you're going to feel a little overwelmed. There's a culture shock there that takes time to get used to. In fact, you may even feel like you don't want to make choices anymore, even if you end up with a worse solution than you could have otherwise had. But in that case, just choose the one with the prettier box or the lowest price tag.
Personally, I think more choices is better. But of course maybe I like choose my tradeoffs more than others.
Anything equal to or greater than the size of Marvin's brain.
On a similar subject, we've also had real bad luck with linux data integrity in general when handling large files (>500MB). I've seen this problem on both low-end IDE drives as well as high end (5 year warranty) hot-swap SCSI drives. I've mailed the IDE driver author on this (when I thought it was an IDE-only problem), but received no comment. I suppose I should post it to the kernel list.
In any case, for anyone interested, I submitted a test program "writetest" to the Linux Test Project for anyone interested. Just give it a really large block size (a 1GB file is generally large enough) and repeat about 10 times. I wouldn't mind hearing from people on what they see on various mb/chipset combos. Some controllers/motherboards have problems, others don't.
I've been meaning to collect more statistics and such between the different versions and using different video drivers (eg. NVidia vs. open-source). However, my preliminary tests show that rendering text in a gnome-terminal under Fedora Core 2 is a little over 2x slower than an equivalent Redhat 7.3 machine running Ximian Desktop 2. And about 14x slower than xterm with jump scroll turned on.
What this equates to is a slowdown of any process that's spitting out text, including compiling the kernel (2.6 is an exception since they reduced the amount of screen clutter).
Note that minimizing a window doesn't help either. Everything takes pretty much the same amount of time. The old 'xterm' is a little more intelligent about minimizes, though.
The end of the universe happens on January 19, 2038 anyway. We've known this for years.
I'd like to see a good book on writing backends to gcc so that you don't also have to write your own VM compiler. I have the Using and Porting GCC book, and admittedly I've yet to really sit down and go through it thoroughly, but it doesn't seem to make it plainly obvious to me just how you make gcc aware of what opcodes your system needs.
I disagree: http://ccsh.sourceforge.net/
I recently started using the Galeon browser, and I really like it's ability to open new urls into a tabbed window and have the ability to move tabs (fairly) easily between windows. This feature has been slowly growing over the years in a few specialized apps (eg. powershell and screen).
It occurred to me that this would be an awesome feature for a window manager. While I personally use screen in an xterm all the time, it doesn't allow you to virtualize windowed apps. And it would reduce the unnecessary duplication of effort in each individual app.
I've often thought that all daemons/services running on a system should run in their own chroot'd environment when available (not just ftp). Everything from mail to pop to echo.
Also, every service app (preferabbly all apps period) should be distributed with a list of what system calls it's allowed to perform and what files/directories it's allowed to read/write from/to. Likewise, all distributions should be based off of NSA's SecureLinux to take advantage of this list.
On a semi-related note, I'd even like to see a system where the entire chrooted environment is encrypted. Only services allowed to access these directories are given the secretkeys/tokens (maybe something kerberos-like) that allow them to read/write to these diretories. This would allow for systems where even the system administrator may not be trusted by users (to the extent that the sysadmin didn't modify the kernel, anyway).... for example if the secret key for a user's home directory is their password... then only the user, when he logs in, will be able to decode his files.
All this of course isn't a replacement for good programming practices. But I think it's a good failsafe, in case the usual measures don't stop the bad programs.
Mailing lists, then, could be considered a broadcast medium, depending on the list.
So, given this distinction, I think it's fairly clear that unsolicited marketing is not acceptable in a point-to-point system. Yes, you can use the "opt-out" method that people described already, and that's already in place. But the problem here is that you simply can't account for all the people that will call you. And they will. They always do. Even the guy who said he contacted the DMA group said he still gets at least 1 call every year.
Freedom of speech is important. But it doesn't give you the right to convey this speech any way you want. You can't convey your speech through a blowhorn in someone's ear. You can't follow some guy around all day until he gives in to your views. So the issue of "freedom of speech" isn't as much of an issue as the "method of speech".
It used to be at ftp.x.org, I think. About 6 years ago. I don't know what happened to it.