Well, ignoring that your login tells it all, I find it funny that you would knock Linux for support.
I am not knocking Linux or BSD support. I am just saying that I have had situations where support from commercial vendors is really worth it, especially when you need the same level of support for old versions where upgrading is not an option.
In addition, the Linux/OSS world gives you the source code...
Yes, the Linux and BSD kernel and userland source is available for free. That is a huge bonus. However, most RTOS vendors will make their code avaialble for a fee (last time I looked into this, it was pretty big, though.
Linux and BSD are both fantastic systems, but IMHO, I do not think they belong in mission critical realtime applications. There are some companies like LynuxWorks that support embedded Linux, but given the choice I would almost always choose LynxOS over Embedded Linux, but most of the embedded systems I have work on require hard-realtime and I tend to choose very conservatively on embedded projects.
I have never needed a filesystem on an embedded product, and I don't think I have worked on a deployed system with more that 32 M. I think the biggest had 8M.
I would also be hesitant to deploy an RTOS without a proven track record and without good support. I have found kernel bugs before, and I have had to fly out tech support to help out with problems at customer sites. Most commercial vendors will also support old versions for a long time if needed.
There is a really big difference between embedded processors and mainstream CPUs.
The biggest is that power consumption is really important in the embedded world. Sometimes you can only get so much current to a board, or you can't run fans.
Typically, embedded processors can run without support chips. Many have built in memory controllers and I/O.
Another thing is the MMU. A lot of embedded processors have MMUs (I think most of the PPC ones do), but OS support for them is a bit lacking (or it was until recently). But at times, the MMU can get in the way
IMHO, I would never run linux in an embedded product, other than simple internet appliances or where realtime isn't required. Commerical RTOSs like VxWorks really are worth it for most embedded applications.
I have a degree in CMPEN. I took three semesters of calculus, one semester of differential equations, and one semester of linear algebra. Several CS classes could classify as math, such as discrete math and some of the more theoretical ones (automata, lamba calculus, etc). Some optional courses can include numerical programming and numerical analysis.
I did DSP and digital communications simulation for a long time. Without a very firm grasp of math, you are not an effective programmer in this field. Most people who don't really understand DSP and digicomm, both theory and implementation, can trace their problems down to the math.
One of the biggest problems in networking is handling a large bandwidth-delay product (that's the amount of data in flight at once). Since distance increases the delay it is relevant.
If anyone cares, a connection with a large bandwidth delay product is sometimes called a long fat pipe. A good networking book should discuss this. I think Steven's TCP/IP Illustrated, Volume 1 has a section on it(my copy is at work.)
I would be a bit wary of a codec that claims to be all things to all people, ie supporting broadcast-quality HDTV and internet-quality video
Video codecs typically have ``sweet-spots'' for resolution and bitrate. The MPEG specs work well for higher bitrate video, and we have several codecs that work well for lower bitrate video.
Also, MPEG video quality can vary from encoder to encoder. The specs only define the bitstream, and the encoder can do what it wants. This is why there is a huge difference between the quality that Media Cleaner produces versus a multi-chip hardware encoder found in a cable plant.
In my software engineering class, my teacher vehemently states that Requirements are the Enemy of Design.
Unfortunately, a lot of college professors are out of touch with reality. Software development is such a diverse area that you really can't generalize.
For example, I worked for a long time in embedded firmware and digital signal processing, both on mega- and micro-projects. You need to design to requirements for these. There can be creativity in how you impelment a design, but the bottom line is the spec. If you don't design to the spec, the satellite falls out of the sky.
Currently, I am working in multimedia, and we don't really use specs. We have high-level goals, but even these are fuzzy. Here, requirements are more of a hindrance, but we still have to draw the line in the sand for some things.
LaTeX and Gnuplot got me through college without having to pay for laser printing papers (the laser printers on the unix machines were free, but the ones on the PCs and Macs were a nickel a page.).
I used to develop code for digital set-top boxes, and I can tell you that this is not a trivial problem.
Because of the way MPEG-2 video works, there is an inherent delay in decoding (frame order in the bitstream isn't necesarily the display order because of the way P-frames and B-frames work.
Audio is slaved to the video through the use of timestamps, but the audio and video frame boundaries don't line up.
I'm not sure if the problem is really lip-sync delay, but building in enough buffering to account for video delay while not glitching audio.
Most people don't notice minor video problems, like repeating or dropping a frame, but they will hear lots of little audio glitches. Also, when a hardware audio decoder runs dry, you usually get a really bad artifact (it sound like stepping on a squealing mouse), and it takes 2 to 4 frames of audio to resync.
Some developers, especially ones doing video and multimedia, can never have too much RAM. I have 1G in my work machine, and I wish I had more at times. I believe one of my friends who does professional video editing has 2G in his machine.
I did some rough calculations a while ago, and consulted with some of my collegues (I used to do DSP and digicomm), and we came to the conclusion that it probably was true.
When you are on a plane the phone basically has line of sight to many cell towers. When you are on the ground you typically have line of sight to none. In fact, cell phones are designed to work without a line of sight component at the receiver (ie, Rayleigh model instead of Rician). LOS gives you a huge power advantage.
We suspect that even though the plane is travelling much faster than a car, than most towers have their AGC opened wide enough that with a LOS component, that Doppler could be handled.
I know what you mean. I have had my permanent email address since 1993 or so, and I am not going to change it. I imagine it was on one of the first email address CDs that were for sale. I get so much SPAM that I don't bother obscuring my email address for netnews, etc, since I doubt it would help at all.
Doesn't the Godel incompleteness theorem say they can't?
Yes and not. Can a program terminate (give yes or no) for an arbitrary statement? Nope. Can a program terminate for a set of possible statements. Yup.
There are practical consequences of this. (Disclaimer: Memory hazy, but I considered grad school on the subject) Higher order lamba calculus is (probably) undecidable. This basically means that we can't type certain forms of computer programs. If you limit the input to let-bound polymorphism, then there is a decidable type system (such as Hindley-Milner), and we get a plethora of powerful programming languages (ML, Haskell, etc).
Theorem provers have been around for a long time. A net search should turn up a ton of hits. The key is to implement a system that can be verified by hand, and then build on it.
As others have said, it isn't doesn't prove the truth, but it gives a lot of support to the employee's case. Further support would would gained if you record who else worked with you that shift, and also summaries of conversations with the manager (eg, "Manager asked me to work some extra hours next week to do inventory.").
I think it is because Microsoft equals money in more way than one.
Most *nix software is free. Most software for MS products isn't, and this includes top notch applications which are worth it, and stupid applications (ie, most shareware).
I think that people who advocate MS products, also think that they can make money on it in one way or another. They can write stupid shareware apps, or they can write another book for an already crowded market.
I balance geeking with gardening. When I start dreaming in code (I had an XSLT nightmare the other night...), I know I need to spend some more time with my plants.
Also, if it would ever stop raining, I would spend more time in the convertible
I'm glad to see that people think that desktops are the only computers that people use...
I come from the embedded world. I don't know any engineer who would put an x86 in anything. On the other hand, I have put PPC in a lot of places, and there has been a trenendous amount of work to make this a stable, robust platform.
Slashdot Mirror
Well, ignoring that your login tells it all, I find it funny that you would knock Linux for support.
I am not knocking Linux or BSD support. I am just saying that I have had situations where support from commercial vendors is really worth it, especially when you need the same level of support for old versions where upgrading is not an option.
In addition, the Linux/OSS world gives you the source code...
Yes, the Linux and BSD kernel and userland source is available for free. That is a huge bonus. However, most RTOS vendors will make their code avaialble for a fee (last time I looked into this, it was pretty big, though.
Linux and BSD are both fantastic systems, but IMHO, I do not think they belong in mission critical realtime applications. There are some companies like LynuxWorks that support embedded Linux, but given the choice I would almost always choose LynxOS over Embedded Linux, but most of the embedded systems I have work on require hard-realtime and I tend to choose very conservatively on embedded projects.
I have never needed a filesystem on an embedded product, and I don't think I have worked on a deployed system with more that 32 M. I think the biggest had 8M.
I would also be hesitant to deploy an RTOS without a proven track record and without good support. I have found kernel bugs before, and I have had to fly out tech support to help out with problems at customer sites. Most commercial vendors will also support old versions for a long time if needed.
There is a really big difference between embedded processors and mainstream CPUs.
The biggest is that power consumption is really important in the embedded world. Sometimes you can only get so much current to a board, or you can't run fans.
Typically, embedded processors can run without support chips. Many have built in memory controllers and I/O.
Another thing is the MMU. A lot of embedded processors have MMUs (I think most of the PPC ones do), but OS support for them is a bit lacking (or it was until recently). But at times, the MMU can get in the way
IMHO, I would never run linux in an embedded product, other than simple internet appliances or where realtime isn't required. Commerical RTOSs like VxWorks really are worth it for most embedded applications.
How about the doctor analyzing zippy?
I have a degree in CMPEN. I took three semesters of calculus, one semester of differential equations, and one semester of linear algebra. Several CS classes could classify as math, such as discrete math and some of the more theoretical ones (automata, lamba calculus, etc). Some optional courses can include numerical programming and numerical analysis.
I did DSP and digital communications simulation for a long time. Without a very firm grasp of math, you are not an effective programmer in this field. Most people who don't really understand DSP and digicomm, both theory and implementation, can trace their problems down to the math.
One of the biggest problems in networking is handling a large bandwidth-delay product (that's the amount of data in flight at once). Since distance increases the delay it is relevant.
If anyone cares, a connection with a large bandwidth delay product is sometimes called a long fat pipe. A good networking book should discuss this. I think Steven's TCP/IP Illustrated, Volume 1 has a section on it(my copy is at work.)
I would be a bit wary of a codec that claims to be all things to all people, ie supporting broadcast-quality HDTV and internet-quality video
Video codecs typically have ``sweet-spots'' for resolution and bitrate. The MPEG specs work well for higher bitrate video, and we have several codecs that work well for lower bitrate video.
Also, MPEG video quality can vary from encoder to encoder. The specs only define the bitstream, and the encoder can do what it wants. This is why there is a huge difference between the quality that Media Cleaner produces versus a multi-chip hardware encoder found in a cable plant.
In my software engineering class, my teacher vehemently states that Requirements are the Enemy of Design.
Unfortunately, a lot of college professors are out of touch with reality. Software development is such a diverse area that you really can't generalize.
For example, I worked for a long time in embedded firmware and digital signal processing, both on mega- and micro-projects. You need to design to requirements for these. There can be creativity in how you impelment a design, but the bottom line is the spec. If you don't design to the spec, the satellite falls out of the sky.
Currently, I am working in multimedia, and we don't really use specs. We have high-level goals, but even these are fuzzy. Here, requirements are more of a hindrance, but we still have to draw the line in the sand for some things.
Can anyone comment on this compared with Gnuplot?
LaTeX and Gnuplot got me through college without having to pay for laser printing papers (the laser printers on the unix machines were free, but the ones on the PCs and Macs were a nickel a page.).
I used to develop code for digital set-top boxes, and I can tell you that this is not a trivial problem.
Because of the way MPEG-2 video works, there is an inherent delay in decoding (frame order in the bitstream isn't necesarily the display order because of the way P-frames and B-frames work.
Audio is slaved to the video through the use of timestamps, but the audio and video frame boundaries don't line up.
I'm not sure if the problem is really lip-sync delay, but building in enough buffering to account for video delay while not glitching audio.
Most people don't notice minor video problems, like repeating or dropping a frame, but they will hear lots of little audio glitches. Also, when a hardware audio decoder runs dry, you usually get a really bad artifact (it sound like stepping on a squealing mouse), and it takes 2 to 4 frames of audio to resync.
Some developers, especially ones doing video and multimedia, can never have too much RAM. I have 1G in my work machine, and I wish I had more at times. I believe one of my friends who does professional video editing has 2G in his machine.
If anyone cares and has access to back issues, this appears to be the issue (Sep 1996) I was thinking about.
I did some rough calculations a while ago, and consulted with some of my collegues (I used to do DSP and digicomm), and we came to the conclusion that it probably was true.
When you are on a plane the phone basically has line of sight to many cell towers. When you are on the ground you typically have line of sight to none. In fact, cell phones are designed to work without a line of sight component at the receiver (ie, Rayleigh model instead of Rician). LOS gives you a huge power advantage.
We suspect that even though the plane is travelling much faster than a car, than most towers have their AGC opened wide enough that with a LOS component, that Doppler could be handled.
There was an article in IEEE Spectrum about this a few years ago. I would post the results, but (1) I forget what the article said, and (b) I am lazy.
I know what you mean. I have had my permanent email address since 1993 or so, and I am not going to change it. I imagine it was on one of the first email address CDs that were for sale. I get so much SPAM that I don't bother obscuring my email address for netnews, etc, since I doubt it would help at all.
C* actually is a language. It is the C-like parallel language used mainly on Connection Machines.
Doesn't the Godel incompleteness theorem say they can't?
Yes and not. Can a program terminate (give yes or no) for an arbitrary statement? Nope. Can a program terminate for a set of possible statements. Yup.
There are practical consequences of this. (Disclaimer: Memory hazy, but I considered grad school on the subject) Higher order lamba calculus is (probably) undecidable. This basically means that we can't type certain forms of computer programs. If you limit the input to let-bound polymorphism, then there is a decidable type system (such as Hindley-Milner), and we get a plethora of powerful programming languages (ML, Haskell, etc).
Theorem provers have been around for a long time. A net search should turn up a ton of hits. The key is to implement a system that can be verified by hand, and then build on it.
28.8? The fastest modem I had for my C64 was 300 baud.
As others have said, it isn't doesn't prove the truth, but it gives a lot of support to the employee's case. Further support would would gained if you record who else worked with you that shift, and also summaries of conversations with the manager (eg, "Manager asked me to work some extra hours next week to do inventory.").
Keep handwritten records in ink of your time in a journal along with your daily activities.
I think it is because Microsoft equals money in more way than one.
Most *nix software is free. Most software for MS products isn't, and this includes top notch applications which are worth it, and stupid applications (ie, most shareware).
I think that people who advocate MS products, also think that they can make money on it in one way or another. They can write stupid shareware apps, or they can write another book for an already crowded market.
I balance geeking with gardening. When I start dreaming in code (I had an XSLT nightmare the other night...), I know I need to spend some more time with my plants.
Also, if it would ever stop raining, I would spend more time in the convertible
I'm glad to see that people think that desktops are the only computers that people use...
I come from the embedded world. I don't know any engineer who would put an x86 in anything. On the other hand, I have put PPC in a lot of places, and there has been a trenendous amount of work to make this a stable, robust platform.
My databooks are MIA at the moment or I would give more details, but the PPC ISA has versions of MOVE that do the byte swapping automagically.