I'm glad someone's thinking this way. It's what I've said all along. We, as a community, need to evaluate our goals and not just assume that what we want to do is capture the desktop market.
My motives for using Linux are purely selfish. It meets *my* needs better than any other OS so I use it. Frankly I don't care if my mother can use it or not. I would like to see it gain enough support so that a good selection of apps were available for it so that I'd have even less excuse to boot Windows on my machine. But that's it. I don't see that I really have anything to gain from Linux actually achieving 'world domination', and maybe would stand to lose something. What I want to see is Linux continue to have the characteristics that attracted me to it in the first place: stability and configurability. (And it's just plain fun!)
[somebody please moderate this up so that everybody will see it.]
Whats to stop Microsoft from creating their OWN Linux distribution?
Nothing really, except themselves. There is nothing to stop anyone, including you and I from creating a distro. Perhaps they don't see a return on their investment; perhaps they feel it would undermine Windows; perhaps they realize that the Linux community is pretty anti-M$ (to say the least) and wouldn't buy it. Still it wouldn't surprise me all that much to see them do exactly that, espcially given their policy of "embrace and extend".
Take a look at d.net's new FAQ-o-matic that allows registered users to add a FAQ answer.
Hopefully there's somebody watching over these answers to make sure they're correct, but I think this is a pretty good idea. Maybe the LDP could look at doing something like this.
I just also want to add my two pennies and say thanks to everyone who has contributed to the LDP. It's not perfect, but it has saved my ass many times. Hopefully, one day I'll be clueful enough to add my own contribution. Documentation is a dirty, rotten, thankless job, but without it the best code in the world is useless.
Hmmm, hard to tell if you're trolling or just ignorant. If the former, may I suggest that next time you include some verbage to make your intentions more clear to the moderators so that they can moderate you off the face of the Earth. I recommend mentioning Natalie Portman, earlobes and petrification, and that should clear things up nicely.
If, however, it is the latter, I highly suggest you do a bit of research such as finding some of the other stories on this subject and maybe actually chase a link or two to get a grasp of the issues involved. If you do that you will learn (if you pay close attention) that the DeCSS algorithm is for playing DVDs, not copying them.
I dunno, Jamie, I like Exhibit B much better. I'd like it even more if it used a cooler theme like Aqua or Absolute_E.
As for head-bashing, I agree that Motif & gtk are both wacky to program for, but what graphical API isn't? Have you ever heard anybody say that they *love* this toolkit or that one? Mostly it's just a matter of coping as best you can. I guess the Qt folks are pretty fond of theirs cause it's OO, but I haven't heard of too many that people are just nuts about.
EG: I think what Proteus was saying was that if you develop a software product (in this case the Linux kernel) and GPL it, the GPL license doesn't extend outside of that piece of software. I think he is correct in that that's what the GPL is trying to say, but I'm not sure it actually says it in the case of embedded products. (Due to the funky wording about distributing it as a single work etc.)
btw, thanks for looking into the BSD & eCos licenses. I'm curious how Cygnus gets away with licensing eCos that way since it's based on Linux. Seems like the viral nature of the GPL would prevent that.
I was considering opening an "Ask Slashdot" thread to get more folks involved in this discussion. Do you think that would be worthwile?
My understanding is that it would not fall under the GPL. I think this is how binary-only device drivers can exist. But I could be wrong, IANAL either.
I don't presume to speak for Stallman on this issue (or any issue for that matter), but I'm fairly certain that the spirit of the GPL is to allow proprietary code to co-exist with GPL'd code where appropriate. The more I think about this the more I think that the GPL needs to be modified to make it more explicit. To not do so only hurts Linux in the embedded arena. Which incidentally, I think is an area where Linux stands to make some of the biggest gains against other OS's.
How should we go about contacting Stallman to see if he is in agreement with this and hopefully get either a clarification or modification to the document?
On a different note, as I understand it, the BSD license doesn't suffer from this problem due to its 'non-viral' nature. Is this correct? Are there any BSD-based embedded solutions out there? If so, is source available?
Hard-embedded and soft-embedded, hmmm.....I like it. Kinda goes with hard real-time and soft real-time.
Still kind of a grey area where certain devices are concerned. The criterium I used to use was if you could develop code natively on it, then it wasn't embedded. Now in theory with Pocket C you can write code on a Palm Pilot, compile it (interpret actually I think) on the Palm Pilot and run it on the Palm Pilot. To me this makes it unambiguously not embedded. But what about the Web Pad thingies? Where do they fit in? Can you run more than one application on it? If so, I'd say it's not embedded too, but if the only thing it will do is run Mozilla, I could make a case for classifying it as embedded. (Just with a more complex UI than most embedded stuff)
Calculators? You can write code on them (the programmable ones anyway) and you can run more than one app if there is sufficient storage space. So I dunno about that one.
But the other half was the size of the OS. It meant bigger memory requirements, which meant higher cost. I agree about WinCE being a hog, but take a look at uClinux. It is a modified 2.0.38 kernel with virtual memory stripped out. It fits in 2MB EPROMs with lots of room left over for your apps. The difference is that WinCE is a big monolithic program (just like desktop windows), whereas Linux (or any Unix) is modular. You only include the pieces you need.
...you'd end up with something that wasn't particularly compatible with mainstream Linux...
You wouldn't have to add it to the kernel, you could implement something like this as another program that runs on the (more or less) standard Linux kernel. Sorta like an X replacement. It could even be the PalmOS API if you wanted it to be.
But do you really need multitasking on something like a palm-pilot? Probably not, but there are lots of embedded applications that would benefit from multitasking.
Users? Sure I can see some applications for multiple users in embedded devices. At the very least, it would be useful to have a normal user account and a root account (for debugging, system maintenance, etc.).
A file-system, even? Absolutely! A RAMdisk, for example. Or the ability to mount an NFS volume.
If not, then why Linux? Well, here are a few reasons. With Linux you get a stable kernel, with a good scheduler and very good networking. You get the source code. You can develop (and debug) nearly all of your application on your desktop (also running Linux, of course) and only port to the target when you're done. And you get portability. Pretty good reasons, imo.
This whole issue got me thinking, so I went back to the GPL to see what it sez... here are the terms for modifying the code: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
So far, so good. Now here's the troublesome part:
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Now I would argue that my traffic controller software can be "considered [an] independent and separate work" and therefore should not fall under the GPL. But the last sentence seems to imply the opposite since it is distributed as part of a whole (Linux and my app are burned into the same PROMs). But if you look carefully you see that it only applies if it is a "work based on the program". The question is if a program is compiled and linked and loaded in the same set of PROMs as GPL'd code, is it considered a "work based on the program" or a "separate work"? I would argue the latter, but it's not entirely clear.
Clearly, if my app is non-embedded and I distribute it separately in binary-only form (Netscape, eg), I'm not bound by the GPL. I'm sure FSF never considered embedded code specifically but I really don't think they intended embedded s/w to be treated any differently than non-embedded just because it is distributed differently.
What I would like to see is for the license to be modified so that it explicitly deals with the case of embedded code. RMS, are you out there? What was your intention?
Let me preface this by saying that I've been an embedded developer for about 9 years.
Traditionally, the term "embedded" denoted a system with minimal (or no) UI. Code for such a system could not be developed natively so development was done on a host and 'installed' on the target via an emulator, debug port, PROMs, etc. Typical examples are heating/cooling systems, flight control systems and microwave ovens. In my case, they are traffic controllers and other associated equipment.
Things like Web Pads and Palm Pilots seem to blur the distinction between embedded and non-embedded systems. While code is still developed on a host (for the most part), many of these devices have quite sophisticated UI's (even GUI's). What do you think? Should they still be considered embedded or should there be some new term to describe them? Maybe I'm just old-fashioned, but I have a hard time thinking of anything with a GUI as embedded.
Do the developers simply have to observe a "chinese-wall" model for developing, keeping the OS in one set of directories and the "app" in the other, and linking/stitching them together only as the last step before ROMming?
Yes, this is my understanding, but IANAL. If somebody out there knows otherwise, I'd sure appreciate it if you'd let me know. I develop s/w for traffic control equipment and plan to use some form of real-time Linux (eCos, RTLinux, eg.) for my next product. My PHB would be very upset to know that we had to release the sources to our apps. Clearly we are required to make available any changes we make to the kernel (or any other GPL'd code), but as I understand it, we don't have to release anything that we write that lives in user space.
Re:YETI@Home hits the nail on the head
on
YETI@Home
·
· Score: 2
The difference is that the Windows version has all the eye candy (perty color plots and graphs), whereas the Linux version doesn't. If you really want to use Windows, I believe there is a text-only version at the SETI@Home site. I agree that the Windows version is not very nice and on my Windows systems I use it in screensaver-only mode. On Linux, I run it all the time and I never know it's there (except for all the memory it uses). It *is* a memory hog; not sure if it's worse than Netscape, but it's definitely in the same league.
I don't see the two competing too much; they address somewhat different applications. Mobile Linux appears to be for laptops, web pads, and the like, while Lineo is for truly embedded systems with little or no user interface such as cell phones, heating & cooling systems, etc. (or in my case traffic controllers and telescope mounts)
However, Lineo *does* face competition from RTLinux, uClinux and eCos. And they've been around a little longer than Lineo. But certainly this is good news for us embedded developers. Having more options is always better and Lineo seems at first glance to be an attractive one. I'll be giving it a closer look for sure.
At its closest approach it is about.1 AU from Earth, which is quite a bit more than the mean Earth-Moon distance of 3.8e5 km. Additionally, it never would pass *between* the Earth and Moon since at the closest approach it is almost directly below the Earth's south pole.
True, but it misses the point. The point is that we don't want to let the failure of a 'Linux product' tarnish the reputation of Linux itself, or the open-source community as a whole.
Certainly anyone is free to install (or not) any distro they please, but is it in our best interest to stand aside like Kirk obeying the Prime Directive? I prefer to help them avoid the mistake in the first place and thereby win a friend, than to give them the 'freedom' to fuck up and gain an enemy. This is supposed to be a *community* after all, right?
...are not likely to download a huge CDrom image and burn a Linux CD. For the most part you're probably right, but I know a guy who was about to do just that. (And in fact I did it myself when I installed my first Linux distro.) He is a longtime Win user who is otherwise pretty computer-savvy and was interested in learning about Linux. I quickly burned him a copy of RH6.1 to try out. If he likes that, maybe I'll give him Debian too.
...ANY of them will be thousands of times better than LO appears to be... Indeed!!
...the list of problems is amusing... I, for one, am not all that amused. How many new potential Linux users will install this (or try to) and fail miserably, then conclude that Linux is crap. How many of them will tell their friends about their misfortune? Will Big Bad Bill point to this and say "See, we told ya! It's hard to install and buggy. Come back to us and we'll hold your hand and make it all better."
We know that LinuxOne != Linux, but newbies may try to equate the two. This could end up alienating many converts to the light side. We are now between a rock and a hard place: we want LinuxOne to bite turf, but we don't want Linux itself to crash and burn with it.
In our advocacy of Linux, let's be sure to point people to some of the many fine distros that are available and steer folks away from LinuxOne.
Try this link. Where it says "Select Product Categories" at the top, pop open the combo box and select "Hubble Space Telescope". I'm sure there are others; if you e-mail me, I can probably track down some more for you.
I couldn't agree more. If this is the future of music, I'm gonna be more than cranky. I'm not saying there is no place for mp3. It's fine for playing music on your laptop (for example), but for serious audio, the quality just isn't there. Plus, as you say, when you buy a CD you get more than the bits on the disc; you also get the lyrics, liner notes, etc. that (to me at least) contribute to the whole musical experience.
Deep Space 1's main drive failed in it's initial power-up, and it took almost a week of intense work, shaking of the probe, and everything else they could think of to reactivate it. But reactivate it they did and it accomplished the vast majority of the mission. The only thing they missed was the photos of the asteroid (or comet - I forget) as it flew by - this because of a stuck camera I think. Remember this stuff is rocket science. Things go wrong. It is a testament to the ingenuity of NASA & JPL that most missions succeed despite failures of hardware - though not as many as you seem to believe.
Yes, P10/11, and V1/2 did accomplish -some- of their missions spectacularly. However, most of the equiptment was shut down (through lack of power), the data rate was reduced (which may have resulted in higher lossage) and much of what they could be accomplishing right now (had they the means) will be lost to us for decades to come, or longer. Drugs are bad. Most of the equipment was not shut down, these probes accomplished over 90% of what they started out to do and even some things they didn't initially plan on (the 'grand tour' of Uranus & Neptune, eg.)
The solar winds are being blamed for pushing Skylab out of orbit, causing it to crash & burn rather spectacularly in the Earth's atmosphere. If the cause is correct, then this was easily avoidable on NASA's part, and a major blunder. Blamed by whom? You have your facts all screwed up - read Tau Zero's post, he got it right.
I would also like to see references for your contentions about the lightning causing the booster to fire and the Viking probe.
Deep Space 1 used an experimental drive that had failed every single test ever done on Earth But still worked in space. Also remember it was experimental.
Pioneers 10 & 11 and Voyagers 1 and 2 all suffered hardware failures - main antenna and/or solar panels But still accomplished their missions fairly spectacularly.
NASA was convinced that deep-frozen rubber rings would work just fine when super-heated to a few thousand degrees centigrade, suddenly (duh!), killing 6 astronauts and a civilian Yep, that was a pretty bad boo-boo.
NASA knew about solar winds, and even devised spaceships to travel by them, but neglected to take them into account when positioning Skylab What do solar winds have to do with Skylab's orbit?
This is a perfect example of metaphor shear, which Neal Stephenson talks about in his essay, In the Beginning...Was the Command Line. The problem is that to make computers easier to use for the common (l)user, analogies are drawn to everyday real world items and concepts. Good idea, but the analogies always break down at some point leaving the user frustrated. This is the tradeoff that always gets made: force the user to learn a new paradigm (Unix) or reuse (imperfectly) an existing one (Mac/Windows).
I was disappointed to find out that a couple of my favorites are in fact urban legend. The JATO rocket story is unconfirmed and the story of the two guys at the Metallica concert has been assigned "Urban Legend" status. Rats.
I guess I should be uplifted (instead of bummed) that these are fiction, not fact. But I continue to believe that people are stoopid enought to do that - it's just that this time fiction got there first.
Slashdot Mirror
I'm glad someone's thinking this way. It's what I've said all along. We, as a community, need to evaluate our goals and not just assume that what we want to do is capture the desktop market.
My motives for using Linux are purely selfish. It meets *my* needs better than any other OS so I use it. Frankly I don't care if my mother can use it or not. I would like to see it gain enough support so that a good selection of apps were available for it so that I'd have even less excuse to boot Windows on my machine. But that's it. I don't see that I really have anything to gain from Linux actually achieving 'world domination', and maybe would stand to lose something. What I want to see is Linux continue to have the characteristics that attracted me to it in the first place: stability and configurability. (And it's just plain fun!)
[somebody please moderate this up so that everybody will see it.]
Whats to stop Microsoft from creating their OWN Linux distribution?
Nothing really, except themselves. There is nothing to stop anyone, including you and I from creating a distro. Perhaps they don't see a return on their investment; perhaps they feel it would undermine Windows; perhaps they realize that the Linux community is pretty anti-M$ (to say the least) and wouldn't buy it. Still it wouldn't surprise me all that much to see them do exactly that, espcially given their policy of "embrace and extend".
Take a look at d.net's new FAQ-o-matic that allows registered users to add a FAQ answer.
Hopefully there's somebody watching over these answers to make sure they're correct, but I think this is a pretty good idea. Maybe the LDP could look at doing something like this.
I just also want to add my two pennies and say thanks to everyone who has contributed to the LDP. It's not perfect, but it has saved my ass many times. Hopefully, one day I'll be clueful enough to add my own contribution. Documentation is a dirty, rotten, thankless job, but without it the best code in the world is useless.
Hmmm, hard to tell if you're trolling or just ignorant. If the former, may I suggest that next time you include some verbage to make your intentions more clear to the moderators so that they can moderate you off the face of the Earth. I recommend mentioning Natalie Portman, earlobes and petrification, and that should clear things up nicely.
If, however, it is the latter, I highly suggest you do a bit of research such as finding some of the other stories on this subject and maybe actually chase a link or two to get a grasp of the issues involved. If you do that you will learn (if you pay close attention) that the DeCSS algorithm is for playing DVDs, not copying them.
You're welcome.
I dunno, Jamie, I like Exhibit B much better. I'd like it even more if it used a cooler theme like Aqua or Absolute_E.
As for head-bashing, I agree that Motif & gtk are both wacky to program for, but what graphical API isn't? Have you ever heard anybody say that they *love* this toolkit or that one? Mostly it's just a matter of coping as best you can. I guess the Qt folks are pretty fond of theirs cause it's OO, but I haven't heard of too many that people are just nuts about.
EG: I think what Proteus was saying was that if you develop a software product (in this case the Linux kernel) and GPL it, the GPL license doesn't extend outside of that piece of software. I think he is correct in that that's what the GPL is trying to say, but I'm not sure it actually says it in the case of embedded products. (Due to the funky wording about distributing it as a single work etc.)
btw, thanks for looking into the BSD & eCos licenses. I'm curious how Cygnus gets away with licensing eCos that way since it's based on Linux. Seems like the viral nature of the GPL would prevent that.
I was considering opening an "Ask Slashdot" thread to get more folks involved in this discussion. Do you think that would be worthwile?
My understanding is that it would not fall under the GPL. I think this is how binary-only device drivers can exist. But I could be wrong, IANAL either.
I don't presume to speak for Stallman on this issue (or any issue for that matter), but I'm fairly certain that the spirit of the GPL is to allow proprietary code to co-exist with GPL'd code where appropriate. The more I think about this the more I think that the GPL needs to be modified to make it more explicit. To not do so only hurts Linux in the embedded arena. Which incidentally, I think is an area where Linux stands to make some of the biggest gains against other OS's.
How should we go about contacting Stallman to see if he is in agreement with this and hopefully get either a clarification or modification to the document?
On a different note, as I understand it, the BSD license doesn't suffer from this problem due to its 'non-viral' nature. Is this correct? Are there any BSD-based embedded solutions out there? If so, is source available?
Hard-embedded and soft-embedded, hmmm.....I like it. Kinda goes with hard real-time and soft real-time.
Still kind of a grey area where certain devices are concerned. The criterium I used to use was if you could develop code natively on it, then it wasn't embedded. Now in theory with Pocket C you can write code on a Palm Pilot, compile it (interpret actually I think) on the Palm Pilot and run it on the Palm Pilot. To me this makes it unambiguously not embedded. But what about the Web Pad thingies? Where do they fit in? Can you run more than one application on it? If so, I'd say it's not embedded too, but if the only thing it will do is run Mozilla, I could make a case for classifying it as embedded. (Just with a more complex UI than most embedded stuff)
Calculators? You can write code on them (the programmable ones anyway) and you can run more than one app if there is sufficient storage space. So I dunno about that one.
But the other half was the size of the OS. It meant bigger memory requirements, which meant higher cost.
...you'd end up with something that wasn't particularly compatible with mainstream Linux...
I agree about WinCE being a hog, but take a look at uClinux. It is a modified 2.0.38 kernel with virtual memory stripped out. It fits in 2MB EPROMs with lots of room left over for your apps. The difference is that WinCE is a big monolithic program (just like desktop windows), whereas Linux (or any Unix) is modular. You only include the pieces you need.
You wouldn't have to add it to the kernel, you could implement something like this as another program that runs on the (more or less) standard Linux kernel. Sorta like an X replacement. It could even be the PalmOS API if you wanted it to be.
But do you really need multitasking on something like a palm-pilot?
Probably not, but there are lots of embedded applications that would benefit from multitasking.
Users?
Sure I can see some applications for multiple users in embedded devices. At the very least, it would be useful to have a normal user account and a root account (for debugging, system maintenance, etc.).
A file-system, even?
Absolutely! A RAMdisk, for example. Or the ability to mount an NFS volume.
If not, then why Linux?
Well, here are a few reasons. With Linux you get a stable kernel, with a good scheduler and very good networking. You get the source code. You can develop (and debug) nearly all of your application on your desktop (also running Linux, of course) and only port to the target when you're done. And you get portability. Pretty good reasons, imo.
This whole issue got me thinking, so I went back to the GPL to see what it sez... here are the terms for modifying the code:
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such
modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
So far, so good. Now here's the troublesome part:
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be
reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you
distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Now I would argue that my traffic controller software can be "considered [an] independent and separate work" and therefore should not fall under the GPL. But the last sentence seems to imply the opposite since it is distributed as part of a whole (Linux and my app are burned into the same PROMs). But if you look carefully you see that it only applies if it is a "work based on the program". The question is if a program is compiled and linked and loaded in the same set of PROMs as GPL'd code, is it considered a "work based on the program" or a "separate work"? I would argue the latter, but it's not entirely clear.
Clearly, if my app is non-embedded and I distribute it separately in binary-only form (Netscape, eg), I'm not bound by the GPL. I'm sure FSF never considered embedded code specifically but I really don't think they intended embedded s/w to be treated any differently than non-embedded just because it is distributed differently.
What I would like to see is for the license to be modified so that it explicitly deals with the case of embedded code. RMS, are you out there? What was your intention?
Let me preface this by saying that I've been an embedded developer for about 9 years.
Traditionally, the term "embedded" denoted a system with minimal (or no) UI. Code for such a system could not be developed natively so development was done on a host and 'installed' on the target via an emulator, debug port, PROMs, etc. Typical examples are heating/cooling systems, flight control systems and microwave ovens. In my case, they are traffic controllers and other associated equipment.
Things like Web Pads and Palm Pilots seem to blur the distinction between embedded and non-embedded systems. While code is still developed on a host (for the most part), many of these devices have quite sophisticated UI's (even GUI's). What do you think? Should they still be considered embedded or should there be some new term to describe them? Maybe I'm just old-fashioned, but I have a hard time thinking of anything with a GUI as embedded.
Do the developers simply have to observe a "chinese-wall" model for developing, keeping the OS in one set of directories and the "app" in the other, and linking/stitching them together only as the last step before ROMming?
Yes, this is my understanding, but IANAL. If somebody out there knows otherwise, I'd sure appreciate it if you'd let me know. I develop s/w for traffic control equipment and plan to use some form of real-time Linux (eCos, RTLinux, eg.) for my next product. My PHB would be very upset to know that we had to release the sources to our apps. Clearly we are required to make available any changes we make to the kernel (or any other GPL'd code), but as I understand it, we don't have to release anything that we write that lives in user space.
The difference is that the Windows version has all the eye candy (perty color plots and graphs), whereas the Linux version doesn't. If you really want to use Windows, I believe there is a text-only version at the SETI@Home site. I agree that the Windows version is not very nice and on my Windows systems I use it in screensaver-only mode. On Linux, I run it all the time and I never know it's there (except for all the memory it uses). It *is* a memory hog; not sure if it's worse than Netscape, but it's definitely in the same league.
I don't see the two competing too much; they address somewhat different applications. Mobile Linux appears to be for laptops, web pads, and the like, while Lineo is for truly embedded systems with little or no user interface such as cell phones, heating & cooling systems, etc. (or in my case traffic controllers and telescope mounts)
However, Lineo *does* face competition from RTLinux, uClinux and eCos. And they've been around a little longer than Lineo. But certainly this is good news for us embedded developers. Having more options is always better and Lineo seems at first glance to be an attractive one. I'll be giving it a closer look for sure.
At its closest approach it is about .1 AU from Earth, which is quite a bit more than the mean Earth-Moon distance of 3.8e5 km. Additionally, it never would pass *between* the Earth and Moon since at the closest approach it is almost directly below the Earth's south pole.
Intersting thought, though.
True, but it misses the point. The point is that we don't want to let the failure of a 'Linux product' tarnish the reputation of Linux itself, or the open-source community as a whole.
Certainly anyone is free to install (or not) any distro they please, but is it in our best interest to stand aside like Kirk obeying the Prime Directive? I prefer to help them avoid the mistake in the first place and thereby win a friend, than to give them the 'freedom' to fuck up and gain an enemy. This is supposed to be a *community* after all, right?
...are not likely to download a huge CDrom image and burn a Linux CD.
...ANY of them will be thousands of times better than LO appears to be...
For the most part you're probably right, but I know a guy who was about to do just that. (And in fact I did it myself when I installed my first Linux distro.) He is a longtime Win user who is otherwise pretty computer-savvy and was interested in learning about Linux. I quickly burned him a copy of RH6.1 to try out. If he likes that, maybe I'll give him Debian too.
Indeed!!
...the list of problems is amusing...
I, for one, am not all that amused. How many new potential Linux users will install this (or try to) and fail miserably, then conclude that Linux is crap. How many of them will tell their friends about their misfortune? Will Big Bad Bill point to this and say "See, we told ya! It's hard to install and buggy. Come back to us and we'll hold your hand and make it all better."
We know that LinuxOne != Linux, but newbies may try to equate the two. This could end up alienating many converts to the light side. We are now between a rock and a hard place: we want LinuxOne to bite turf, but we don't want Linux itself to crash and burn with it.
In our advocacy of Linux, let's be sure to point people to some of the many fine distros that are available and steer folks away from LinuxOne.
Try this link. Where it says "Select Product Categories" at the top, pop open the combo box and select "Hubble Space Telescope". I'm sure there are others; if you e-mail me, I can probably track down some more for you.
I couldn't agree more. If this is the future of music, I'm gonna be more than cranky. I'm not saying there is no place for mp3. It's fine for playing music on your laptop (for example), but for serious audio, the quality just isn't there. Plus, as you say, when you buy a CD you get more than the bits on the disc; you also get the lyrics, liner notes, etc. that (to me at least) contribute to the whole musical experience.
Deep Space 1's main drive failed in it's initial power-up, and it took almost a week of intense work, shaking of the probe, and everything else they could think of to reactivate it.
But reactivate it they did and it accomplished the vast majority of the mission. The only thing they missed was the photos of the asteroid (or comet - I forget) as it flew by - this because of a stuck camera I think. Remember this stuff is rocket science. Things go wrong. It is a testament to the ingenuity of NASA & JPL that most missions succeed despite failures of hardware - though not as many as you seem to believe.
Yes, P10/11, and V1/2 did accomplish -some- of their missions spectacularly. However, most of the equiptment was shut down (through lack of power), the data rate was reduced (which may have resulted in higher lossage) and much of what they could be accomplishing right now (had they the means) will be lost to us for decades to come, or longer.
Drugs are bad. Most of the equipment was not shut down, these probes accomplished over 90% of what they started out to do and even some things they didn't initially plan on (the 'grand tour' of Uranus & Neptune, eg.)
The solar winds are being blamed for pushing Skylab out of orbit, causing it to crash & burn rather spectacularly in the Earth's atmosphere. If the cause is correct, then this was easily avoidable on NASA's part, and a major blunder.
Blamed by whom? You have your facts all screwed up - read Tau Zero's post, he got it right.
I would also like to see references for your contentions about the lightning causing the booster to fire and the Viking probe.
Deep Space 1 used an experimental drive that had failed every single test ever done on Earth
But still worked in space. Also remember it was experimental.
Pioneers 10 & 11 and Voyagers 1 and 2 all suffered hardware failures - main antenna and/or solar panels
But still accomplished their missions fairly spectacularly.
NASA was convinced that deep-frozen rubber rings would work just fine when super-heated to a few thousand degrees centigrade, suddenly (duh!), killing 6 astronauts and a civilian
Yep, that was a pretty bad boo-boo.
NASA knew about solar winds, and even devised spaceships to travel by them, but neglected to take them into account when positioning Skylab
What do solar winds have to do with Skylab's orbit?
This is a perfect example of metaphor shear, which Neal Stephenson talks about in his essay, In the Beginning...Was the Command Line. The problem is that to make computers easier to use for the common (l)user, analogies are drawn to everyday real world items and concepts. Good idea, but the analogies always break down at some point leaving the user frustrated. This is the tradeoff that always gets made: force the user to learn a new paradigm (Unix) or reuse (imperfectly) an existing one (Mac/Windows).
I was disappointed to find out that a couple of my favorites are in fact urban legend. The JATO rocket story is unconfirmed and the story of the two guys at the Metallica concert has been assigned "Urban Legend" status. Rats.
I guess I should be uplifted (instead of bummed) that these are fiction, not fact. But I continue to believe that people are stoopid enought to do that - it's just that this time fiction got there first.