Back in prehistoric times, I ran UNIX on an 80286. One of the "features" of the 80286 was the use of segments to address memory. The maximum size of a segment was 64KB. Although this caused problems, it had a useful side effect. Due to the way that the C compiler allocated memory to segments in
the large memory model, many buffer overflows produced immediate segmentation faults instead of silenting corrupting other areas of memory. This was actually useful for testing programs that would run without obvious errors on systems with 32-bit linear address spaces. Tagged and segmented memory systems have fallen out of favor with the increasing popularity of systems written in C. If we are not going to replace C with something safer, such as Ada, maybe we should look at the use of more sophisticated memory models as a way of detecting errors.
nobody's figured out a way to quantify software quality...
See this paper on software metrics and reliability, and John Musa's work on software reliability engineering.
Software reliability can be measured and reliability goals can be set and met with current technology. Management has to make a specified level of reliability a requirement and support a software development and testing process that can meet that requirement.
Why do we need hierarchal directories and long filenames? Starting cylinder number and track count is so much more efficient. If you can't remember where your files are, you are obviously too stupid to use a computer.
I should be able to use a computer without knowing the details of inodes, free space bitmaps, disk partitioning, and the I/O channel configuration of the computer. It is the operating system's job to manage that stuff and hide it from the user. The user interface should present a suitable abstraction or abstractions that is not dependent on the implementation details of the computer's storage system.
Forget DVDs, I want an on-line video library that uses the SMPTE-292M video standard for uncompressed HDTV. That requires 1.485 gigabit/sec or 668 gigabyte/hour. If you want something comparable to 35mm or 70mm film, the data rates will be even higher.
Another example of good engineering is the P3, which is based on the Lockheed Electra L-188. The Lockheed Electra had several well publicized crashes when introduced into passenger service. Those problems were fixed and the Electra and its offspring have been flying for the last 40 years. I see P3s flying by my home on a regular basis. Both the U.S. Navy and the RAF have attempted to replace the P3 with more "modern" aircraft, without success. The U.S. Navy aircraft that was recently clipped by a Chinese fighter was a special version of the P3. It may be slow and ugly, but it keeps on going and going.
Regardless of who lobbied for the flawed deregulation scheme, it wasn't just the "greedy corporate overlords" who were hurt. It was also PG&E workers, small stockholders and pension funds. The State of California, and its citizens, deserve much of the blame for not taking corrective action in a timely manner and letting the utilities slide into bankruptcy.
After looking through some of the material on the company's web site, this product appears to be based on LT (Luby Transform) coding. Each encoded packet is the result of XORing a random selected set of segments from the original file. When sufficient packets have been received, they can be used to reconstruct the original file. Insert magic algorithm. The nice thing about this is that the transmitter can continually stream packets, and a receiver can start collecting packets at any point in time. When the receiver has collected sufficient packets, it can reconstruct the original file. Packet ordering is totally irrelevant. You just need enough packets to generate a unique solution. The math for the code has not been published yet, but this is supposed to be a successor to tornado codes, which have been described in the literature.
You still need some form of flow control or rate limiting, otherwise a large percentage of the UDP packets are going to get dropped. Plus, you have the problem of UDP streams stealing bandwidth from TCP streams on a limited bandwidth link.
The government has sovereign immunity, which means that the government cannot be sued without its consent. The consent may be in the form of legislation that allows certain types of lawsuits.
vi is the only remotely usable text editor that is guaranteed to be available on any Unix box. It's the lingua franca of Unix text editing.
That's funny, I didn't have vi on my PDP-11/23 based microprocessor development system that ran V7 UNIX. It just had ed and a vendor-supplied screen editor. I used that system up until a few years ago.
I can't see this replacing MPEG-2 in DVD players. DVD players are reaching wide market penetration in many countries. That means that there is a huge installed base that is not compatible with these new technologies. The producers and distributors are not going to want to deal with an incompatible media format that increases their production and inventory costs.
It probably wasn't the author's fault. I've had similar things happen to me when my draft documentation was edited by someone who didn't understand the technology. The documentation standard requires that all acronyms be expanded, even when it doesn't make sense.
OK, it's very fast. That's nice. How reliable and compatible is the system? Those are my top priorities, esp. for a server. How well does it run with some random version of Linux or *BSD?
I heard a story, many years ago, that a VAX mysteriously disappeared while being shipped on a train in West Germany. Supposedly it later reappeared in East Germany.
Fuel is cheap. It's the hardware that burns the fuel, and the people who support the launch, that cost the big bucks. If your launch vehicle can carry 20,000 pounds to LEO, you aren't saving much, if any, money if you put less than 20,000 pounds of payload on it.
It isn't that simple. Make sure that your bank will not automatically transfer funds between accounts in cases of insufficient funds in an account. This happened to me when the data entry operator, who puts the MICR stuff on the bottom of the check, misplaced the decimal point on a check that I wrote, increasing the amount by 10 times. My (former) bank honored the check and took the funds needed to cover the check out of another account. It took a while to get it straightened out.
At many companies, Word and Powerpoint attachments are the preferred media for corporate communications. It's a huge waste of bandwidth, but that is what the suits like to use. Putting the documents on a corporate file server doesn't work for those employees who are are off-site and don't have access to the corporate intranet.
Most of the spam that I receive is coming from China and South Korea. I don't think legislation will help much. I would rather see them BGP'd to/dev/null.
And a few years later the Motorola 68000 family (which DID have restartable instructions on memory faults) became the canonical processor for the "cheap unix box" explosion.
Motorola didn't support continuation/restart on the original 68000. That was added in the 68010. There was a kludge that some computers used, it involved running two 68000s in lock step, letting one CPU detect the fault and using the other CPU to recover.
Slashdot Mirror
1 megabyte (8,338,608 bits) != 8 megabit (8,000,000 bits)
If we really want to be precise in our use of language, we should use bits or octets, not bytes. A byte is not always 8-bits.
Back in prehistoric times, I ran UNIX on an 80286. One of the "features" of the 80286 was the use of segments to address memory. The maximum size of a segment was 64KB. Although this caused problems, it had a useful side effect. Due to the way that the C compiler allocated memory to segments in the large memory model, many buffer overflows produced immediate segmentation faults instead of silenting corrupting other areas of memory. This was actually useful for testing programs that would run without obvious errors on systems with 32-bit linear address spaces. Tagged and segmented memory systems have fallen out of favor with the increasing popularity of systems written in C. If we are not going to replace C with something safer, such as Ada, maybe we should look at the use of more sophisticated memory models as a way of detecting errors.
See this paper on software metrics and reliability, and John Musa's work on software reliability engineering.
Software reliability can be measured and reliability goals can be set and met with current technology. Management has to make a specified level of reliability a requirement and support a software development and testing process that can meet that requirement.
I should be able to use a computer without knowing the details of inodes, free space bitmaps, disk partitioning, and the I/O channel configuration of the computer. It is the operating system's job to manage that stuff and hide it from the user. The user interface should present a suitable abstraction or abstractions that is not dependent on the implementation details of the computer's storage system.
Forget DVDs, I want an on-line video library that uses the SMPTE-292M video standard for uncompressed HDTV. That requires 1.485 gigabit/sec or 668 gigabyte/hour. If you want something comparable to 35mm or 70mm film, the data rates will be even higher.
Another example of good engineering is the P3, which is based on the Lockheed Electra L-188. The Lockheed Electra had several well publicized crashes when introduced into passenger service. Those problems were fixed and the Electra and its offspring have been flying for the last 40 years. I see P3s flying by my home on a regular basis. Both the U.S. Navy and the RAF have attempted to replace the P3 with more "modern" aircraft, without success. The U.S. Navy aircraft that was recently clipped by a Chinese fighter was a special version of the P3. It may be slow and ugly, but it keeps on going and going.
Regardless of who lobbied for the flawed deregulation scheme, it wasn't just the "greedy corporate overlords" who were hurt. It was also PG&E workers, small stockholders and pension funds. The State of California, and its citizens, deserve much of the blame for not taking corrective action in a timely manner and letting the utilities slide into bankruptcy.
After looking through some of the material on the company's web site, this product appears to be based on LT (Luby Transform) coding. Each encoded packet is the result of XORing a random selected set of segments from the original file. When sufficient packets have been received, they can be used to reconstruct the original file. Insert magic algorithm. The nice thing about this is that the transmitter can continually stream packets, and a receiver can start collecting packets at any point in time. When the receiver has collected sufficient packets, it can reconstruct the original file. Packet ordering is totally irrelevant. You just need enough packets to generate a unique solution. The math for the code has not been published yet, but this is supposed to be a successor to tornado codes, which have been described in the literature.
You still need some form of flow control or rate limiting, otherwise a large percentage of the UDP packets are going to get dropped. Plus, you have the problem of UDP streams stealing bandwidth from TCP streams on a limited bandwidth link.
The government has sovereign immunity, which means that the government cannot be sued without its consent. The consent may be in the form of legislation that allows certain types of lawsuits.
That's funny, I didn't have vi on my PDP-11/23 based microprocessor development system that ran V7 UNIX. It just had ed and a vendor-supplied screen editor. I used that system up until a few years ago.
I can't see this replacing MPEG-2 in DVD players. DVD players are reaching wide market penetration in many countries. That means that there is a huge installed base that is not compatible with these new technologies. The producers and distributors are not going to want to deal with an incompatible media format that increases their production and inventory costs.
It probably wasn't the author's fault. I've had similar things happen to me when my draft documentation was edited by someone who didn't understand the technology. The documentation standard requires that all acronyms be expanded, even when it doesn't make sense.
OK, it's very fast. That's nice. How reliable and compatible is the system? Those are my top priorities, esp. for a server. How well does it run with some random version of Linux or *BSD?
So they drop the piracy charges and sic the BATF on you for unlicensed possession of destructive devices.
I heard a story, many years ago, that a VAX mysteriously disappeared while being shipped on a train in West Germany. Supposedly it later reappeared in East Germany.
Fuel is cheap. It's the hardware that burns the fuel, and the people who support the launch, that cost the big bucks. If your launch vehicle can carry 20,000 pounds to LEO, you aren't saving much, if any, money if you put less than 20,000 pounds of payload on it.
It isn't that simple. Make sure that your bank will not automatically transfer funds between accounts in cases of insufficient funds in an account. This happened to me when the data entry operator, who puts the MICR stuff on the bottom of the check, misplaced the decimal point on a check that I wrote, increasing the amount by 10 times. My (former) bank honored the check and took the funds needed to cover the check out of another account. It took a while to get it straightened out.
Has anyone looked at the possible effects this would have on local weather patterns?
At many companies, Word and Powerpoint attachments are the preferred media for corporate communications. It's a huge waste of bandwidth, but that is what the suits like to use. Putting the documents on a corporate file server doesn't work for those employees who are are off-site and don't have access to the corporate intranet.
I think you are off by a few orders of magnitude.
Most of the spam that I receive is coming from China and South Korea. I don't think legislation will help much. I would rather see them BGP'd to /dev/null.
Motorola didn't support continuation/restart on the original 68000. That was added in the 68010. There was a kludge that some computers used, it involved running two 68000s in lock step, letting one CPU detect the fault and using the other CPU to recover.
Trick question. It's an infinite loop.