As for guaranteed response times from just Linux, I am extremely dubious. Yes, you can be fast.
But you can't be fast, and handle an arbitrary load, and provide guaranteed respone time.
As for robotics, let me warn you that my MS work was in Manufacturing Engineering (BS Mech Eng), was in robotics... Anyways, if one is running a robot, and is driving the
robot to do path following in Cartesian space, then one must be doing the mapping from Cartesian space to joint space (i.e inverse kinematics) at the servo rate. Further, for proper trajectory generation one needs to check for nasty things like joint inversion, signularities, etc, and must also take into account constraints such as maximum joint positions, maximum joint speeds, etc. Oh, and you need to watch for asyncronous events that may cause you to modify the trajectory in mid move... Did I mention the cameras, being used for real time image analysis, and ridgid body transformations of target fiducials? I used to write code to do all this stuff. The holy grail of machine control would be to have a little microcontroller doing all that work.
[Disclaimer: I work for Lineo, and I wish we hadn't caved in...]
Lower latency is a fine and useful thing for a number of things. But don't make the mistake of confusing low latency with hard realtime.
If I am driving a robot's servo controller using software to close the PID loop, I have to send now positions exactly at the servo rate, or the robot will "jerk", a potentially dangerous situation. If I am using the MontaVista low-latency patch, I still have no guarantee that I will be able to send out position updates at the servo rate. If Linux decides to swap out Netscape to disk, or someone hits eth0 with a ping flood, my robot will end up hitting the side of the workcell, and people might be hurt or killed.
If I am playing Quake, and Linux decided to swap Netscape out to disk, or someone hits eth0 with a ping flood, my frame rate my go down a little bit. With the low latency latches, it might go down a little less.
The point is, low latency does not provide any sort of a guarantee on response time. This is why we have things like RTLinux and RTAI -- to provide guaranteed reponse times for timing critical event handling.
I live in Salt Lake, and everything you have said here is a pile of horseshit. When workers are rude on the phone, they get fired same as everywhere else. When people embezzle they go to jail, whether they are a bishop or a bum. People guzzle Coke all day long in Salt Lake same as everywhere else (I know I do). I let my kids play with other peoples kids not based on their religion, but based on whether those people are losers or not.
Why don't you take your bigotry somewhere else? It seems you can't make fun of poeople for skin color so now you have to mock people for where they live or what church they go to? Get a life. I'll grant you that the Utah liquor laws are stupid. Do you know of any state without any stupid laws? So get over it, get involved, and change the laws you don't like. But making up such ridiculous tripe is a waste of your and my time.
The uClinux source lives on http://cvs.uclinux.org... Of course Red Hat won't tell you that, since Lineo runs uclinux.org and employs nearly all the uClinux developers.
Umm. When did Red Hat take posession of Clinux?
If you visit http://www.uclinux.org/ it says "This Open Source Project Sponsored By Lineo". If you look on the uClinux
developers page it is filled with employees of Lineo. How Red Hat has the balls to claim it as "Red Hat's Clinux" is completely beyond me.
I have done a lot of work on rebuilding uClibc (the Clinux C library) the last 6 months or so to make it cross platform. Have I received even 1 stinking patch from our friends at Red Hat? I think not.
Joe deBlaquiere at Red Hat (who posts frequently on the mailing list and recently put together a nice howto on porting uClinux) is the only redhat person I have ever seen on the mailing list. Does writing a howto make it Red Hat's? I think not.
I often see people claiming (without any proof) that Linux changes too often for embedded, or that the software is too fragmented. Who cares if something is not the latest version if it still does the job it was designed to do? Linux 2.0.x kernels still run just fine...
These days, most embedded Linux systems use a copy of the kernel, glibc 2.0.7 (or libc5 or uClibc), busybox, plus a copy of whatever applications they need. You will find that more and more, more embedded Linux systems are surprisingly similar at their core.
> it takes awhile to boot (30 minutes),
Actually, it takes only 3 seconds. It takes 30 minutes to open the box, read the directions, and plug it on. It boots entirely our of flash.
Sorry to burst your bubble. It takes 30 min to open the box and get it set up. Once set up, it takes only 3 seconds to boot, since it boots entirely out of flash. Another nice thing is that it is fully execute in place, so memory usage is reduced even further.
It takes 3 seconds to actually boot. It takes 30 minutes to take it out of the box and turn it on.
Re:Mobile Linux and Other Debian-based distros
on
Ask 'Ian' From Debian
·
· Score: 1
Debian is the basis for a lot more then you might think. A lot of software is derived from Debian in non-obvious ways. For example, have you installed potato? The boot floppies use BusyBox, which is being developed these days on Lineo's dime. Bruce is running a company these days, and so no longer had the time to develop it. So the guy who is doing BusyBox these days (me) is a long time Debian developer _and_ a Lineo employee. I was also the team lead for developing Embedix 1.0. Trust me on this, Embedix has some very strong Debian roots. You just don't see that type of thing in marketing brochures. I expect the same is true of almost every other Linux company. Debian is good, so people use it.
Yes, it is possible and legal. The open source stuff can be obtained (as you mentioned) from the developer info page. The software as an aggregate has additional licensing restrictions because the software as an aggregate is not all Open Source.
Just suppose that Microsoft included GNU grep as part of Windoze 2001 and provided the source code via their website. They can still distribute Windoze 2001 under their standard EULA. The GPL only applies to GNU grep in that case -- not the whole OS.
BTW, before you get too anxious, in addition to the closed source stuff, Lineo provides a lot of Open Source software to the community -- for example BusyBox, TinyLogin, uCLinux, PopTop, ThinLinux, and Lineo is a major contributor to RTAI (quoting from the developer web page). Just because Lineo's business model is not exactly like RedHat's doesn't make Lineo bad (if it was, I wouldn't work there).
While taking a class entitled "Artificial Intelligence" in grad school we all began calling the class by the more acurate term "Superficial Intelligence".
If microsoft included a copy of GNU grep on the Windoze 2000 CD and posted the source code (or links to the source code) on their web site, but distributed the aggregate under their standard non-free EULA, this does not violate the GPL at all.
The situation with Lineo is exactly the same. You can grab source code to the Open Source components, copy the binaries and do whatever you want with them. Some items in the Embedix distribution are not Open Source, and so you may not copy the aggregate, just like you couldn't copy the theoretical version of Win 2000 mentioned above. Suppose that Red Hat included a copy of MetroX. You couldn't copy the aggregate and share with all your friends. You could only copy the Open Source parts.
Furthermore, Lineo has a solid committment to the Open Source community. Ever visit http://busybox.lineo.com/ or http://tinylogin.lineo.com/? The main reason these exist in their current form and are available to the community is because Lineo has paid me to work on them and release them. Keep in mind that these are the fundamental building blocks of Embedix. Want to build your own embedded Linux distro, grab these and you are mostly there. Why would Lineo pay me to release these? Because it is realised that Open Source works. It works and is the Right Thing(tm) to do.
I was further thinking... The MS statement (and we all know how MS-speak is as carefully planned as when Bill Clinton talks about sex) was (from the news.cnet.com article)
"a one-time charge against earnings for the quarter ending March 31".
I wonder how many other "one-time charges for the quarter ended foo" are going to be charged? I bet the settlement is much larger than MS wants the world to think it is. I bet they just took it in the shorts.:)
Still not speaking for Lineo since I don't know anything.
Sure there are ties. We are both owned by Ray Noorda (of Novell fame). We put a link on our page to them. They put a link on their page to us. We are supposed to have a "co-branding" relationship.
All that is beside the point. Trust me on this. When it comes to the Caldera v. Microsoft lawsuit, Caldera Systems won't be getting a dime. The lawsuit was between Caldera, Inc. and Microsoft. Caldera, Inc. won (so to speak) and Caldera, Inc, not Caldera Systems, gets the money. C.S. is its own, totally independent company with no relationship to the lawsuit.
Caldera, Inc. (Holding Company, owner of DR-DOS -- CEO Bryan Sparks) is the parent company of Lineo, Inc. (Embedded Linux, exclusive licensee of DR-DOS -- CEO Bryan Sparks). Caldera, Inc. used to be the parent company of Caldera Systems, Inc. (CEO Ransom Love), but Caldera Systems purchased its way out from under Caldera. This lawsuit has absolutely nothing to do with Caldera Systems. Wanna check? See http://www.lineo.com/ for the press release. Next, check out http://www.calderasystems.com/ and you will see nothing. Nada. Zip.
Furthermore, the math that folks have been doing (i.e. 3 cents per share * # shares microsoft) is flawed. Nobody really knows how much MS is actually paying, and nobody is going to tell either. I don't know, but I feel very confident that the total amount is much more than the alledged 150 million. Of course I don't know, since nobody around here will talk numbers (per the agreement with MS).
I am an employee of Lineo, but I'm not speaking for them (as if they would trust me).
Slashdot Mirror
As for robotics, let me warn you that my MS work was in Manufacturing Engineering (BS Mech Eng), was in robotics... Anyways, if one is running a robot, and is driving the robot to do path following in Cartesian space, then one must be doing the mapping from Cartesian space to joint space (i.e inverse kinematics) at the servo rate. Further, for proper trajectory generation one needs to check for nasty things like joint inversion, signularities, etc, and must also take into account constraints such as maximum joint positions, maximum joint speeds, etc. Oh, and you need to watch for asyncronous events that may cause you to modify the trajectory in mid move... Did I mention the cameras, being used for real time image analysis, and ridgid body transformations of target fiducials? I used to write code to do all this stuff. The holy grail of machine control would be to have a little microcontroller doing all that work.
Lower latency is a fine and useful thing for a number of things. But don't make the mistake of confusing low latency with hard realtime.
If I am driving a robot's servo controller using software to close the PID loop, I have to send now positions exactly at the servo rate, or the robot will "jerk", a potentially dangerous situation. If I am using the MontaVista low-latency patch, I still have no guarantee that I will be able to send out position updates at the servo rate. If Linux decides to swap out Netscape to disk, or someone hits eth0 with a ping flood, my robot will end up hitting the side of the workcell, and people might be hurt or killed.
If I am playing Quake, and Linux decided to swap Netscape out to disk, or someone hits eth0 with a ping flood, my frame rate my go down a little bit. With the low latency latches, it might go down a little less.
The point is, low latency does not provide any sort of a guarantee on response time. This is why we have things like RTLinux and RTAI -- to provide guaranteed reponse times for timing critical event handling.
Cool. Looks like another sucess story for BusyBox too. BusyBox is going to take over the world. Muhahahahahaha!
Why don't you take your bigotry somewhere else? It seems you can't make fun of poeople for skin color so now you have to mock people for where they live or what church they go to? Get a life. I'll grant you that the Utah liquor laws are stupid. Do you know of any state without any stupid laws? So get over it, get involved, and change the laws you don't like. But making up such ridiculous tripe is a waste of your and my time.
I don't think I mis-read it
andersen@winder:~$ w3m -dump http://www.redhat.com/about/2000/press_rymic.html | grep "Red Hat's.*Clinux"
The uClinux source lives on http://cvs.uclinux.org... Of course Red Hat won't tell you that, since Lineo runs uclinux.org and employs nearly all the uClinux developers.
I have done a lot of work on rebuilding uClibc (the Clinux C library) the last 6 months or so to make it cross platform. Have I received even 1 stinking patch from our friends at Red Hat? I think not.
Joe deBlaquiere at Red Hat (who posts frequently on the mailing list and recently put together a nice howto on porting uClinux) is the only redhat person I have ever seen on the mailing list. Does writing a howto make it Red Hat's? I think not.
These days, most embedded Linux systems use a copy of the kernel, glibc 2.0.7 (or libc5 or uClibc), busybox, plus a copy of whatever applications they need. You will find that more and more, more embedded Linux systems are surprisingly similar at their core.
> it takes awhile to boot (30 minutes), Actually, it takes only 3 seconds. It takes 30 minutes to open the box, read the directions, and plug it on. It boots entirely our of flash.
It takes only 3 seconds to boot. It takes 30 minutes to unpack the box and plug it in.
Nope. Only 3 seconds. The stated time was how long it takes to unpack the box and get it plugged in.
Sorry to burst your bubble. It takes 30 min to open the box and get it set up. Once set up, it takes only 3 seconds to boot, since it boots entirely out of flash. Another nice thing is that it is fully execute in place, so memory usage is reduced even further.
The stated 30 min boot time was the time it takes to open the box and plug things in. Once it is all set up it takes only 3 seconds to boot.
It takes 30 minutes to take it out of the box and get it set up. Once you turn it on, it takes 3 seconds to boot (since it boots entirely from flash).
It takes 3 seconds to actually boot. It takes 30 minutes to take it out of the box and turn it on.
Just suppose that Microsoft included GNU grep as part of Windoze 2001 and provided the source code via their website. They can still distribute Windoze 2001 under their standard EULA. The GPL only applies to GNU grep in that case -- not the whole OS.
BTW, before you get too anxious, in addition to the closed source stuff, Lineo provides a lot of Open Source software to the community -- for example BusyBox, TinyLogin, uCLinux, PopTop, ThinLinux, and Lineo is a major contributor to RTAI (quoting from the developer web page). Just because Lineo's business model is not exactly like RedHat's doesn't make Lineo bad (if it was, I wouldn't work there).
While taking a class entitled "Artificial Intelligence" in grad school we all began calling the class by the more acurate term "Superficial Intelligence".
For windows, grab Tera Term Pro (which is free), then grab and apply the SSH patch. Like magic you can now ssh from your windows boxes.
The situation with Lineo is exactly the same. You can grab source code to the Open Source components, copy the binaries and do whatever you want with them. Some items in the Embedix distribution are not Open Source, and so you may not copy the aggregate, just like you couldn't copy the theoretical version of Win 2000 mentioned above. Suppose that Red Hat included a copy of MetroX. You couldn't copy the aggregate and share with all your friends. You could only copy the Open Source parts.
Furthermore, Lineo has a solid committment to the Open Source community. Ever visit http://busybox.lineo.com/ or http://tinylogin.lineo.com/? The main reason these exist in their current form and are available to the community is because Lineo has paid me to work on them and release them. Keep in mind that these are the fundamental building blocks of Embedix. Want to build your own embedded Linux distro, grab these and you are mostly there. Why would Lineo pay me to release these? Because it is realised that Open Source works. It works and is the Right Thing(tm) to do.
Still not speaking for Lineo since I don't know anything.
All that is beside the point. Trust me on this. When it comes to the Caldera v. Microsoft lawsuit, Caldera Systems won't be getting a dime. The lawsuit was between Caldera, Inc. and Microsoft. Caldera, Inc. won (so to speak) and Caldera, Inc, not Caldera Systems, gets the money. C.S. is its own, totally independent company with no relationship to the lawsuit.
Still not speaking for Lineo.
Furthermore, the math that folks have been doing (i.e. 3 cents per share * # shares microsoft) is flawed. Nobody really knows how much MS is actually paying, and nobody is going to tell either. I don't know, but I feel very confident that the total amount is much more than the alledged 150 million. Of course I don't know, since nobody around here will talk numbers (per the agreement with MS).
I am an employee of Lineo, but I'm not speaking for them (as if they would trust me).
The article states that jpeg images use the fourier transform. They don't. Jpeg images use the discrete cosine transform (DCT).
Don't forget Lineo's embrowser. It runs on Linux' fbcon, and is very small (embrowser + a Lineo's embeddix Linux dist fits in 5 megs uncompressed).
Works pretty well for embedded systems (though it isn't open source).