Tom Henderson got a lot of flak over the pkarc affair, much of it undeserved. In those days I was involved porting the.ARC format to another OS. The sources of SEA arc were available for non commericial use and they were what made porting arc effectively possible.
Porting arc was very important for anyone running something other than MSDOS; almost all bbs downloads came as.arc files. If you couldn't decompress those files you were locked out of that world.
Luckily SEA's source code was well organized and well documented. This meant it was easily ported to other environments. It also made it relatively easy to reimplement some of the key (de)compression routines in other programs. Well documented source code helps a lot when trying to understand a compression algorithm.
It would also have been easy to create a version of SEA arc with some of the compression code replaced by faster routines. The compression routines were a relatively small part of the code. Also, while there were several compression algorithms in arc only one of them (LZW compression) was actually used 99% of the time. The others were historical and mainly there so you could still read old.arc files. LZW compression was only a very small part of arc.
Making that algorithm faster wasn't too difficult either. It was written in C, and in those days hand tuned assembler beat code generated by microcomputer compilers by a factor 5 to 10. Also, arc processed it's data byte for byte; switching to a block based strategy for passing data through various stages typically would gain you another factor of 5 to 10.
SEA's suspicion that pkarc might be reusing large parts of arc's source were widely dismissed as nonsense because pkarc was so much faster. But knowing the source code, and given the very similar interface of the two programs it wasn't all that unlikely.
Pkware also added a new compression method that worked better than SEA's LZW compression. This must have been a major blow for SEA commercially - suddenly the latest ARC couldn't read the latest.arc files anymore! Pkware accidentally had invented the 'embrace and extent' strategy that would be made famous by MS many years later.
The new compression method also made porting much more problematic. Pkarc's source was not available. The format was not documented in it's documentation; if it was available it was not widely known. In the it turned out that pkarc's new algorithm was a minor variation the arc LZW format. (It used 13 rather than 12 bit tokens, and the run length encoding preprocessing was removed.)
The final result was that pkarc took the.arc format from sort of open source to closed source, made it much more MS-DOS specific and doing so helped make the BBS world much more IBM PC centric. It also served as a dire warning against small companies ever releasing any important source under any kind of licence.
But PKWare learned it's lesson and went on to produce a steady stream of faster and better compression algorithms. SEA failed to do what it should have done in the first place: solve arc's terrible performance problems. Unisys started behaving like a bunch of jerks.
As an aside: Around that time free code was usually put in public domain. An endless stream of commercial ripoffs of PD programs with one or two sexy features improved or added was what caused RMS to invent this GPL thing.
"We have received information that at the above address there have been offers to provide instructions on defeating DVD encryption so that illegal copies of DVDs can be made."
This is an incredibly stupid assertion. As one of the DVD sites points out, you don't need to decrypt a DVD to make a copy of it. The only reason no one does is that writable DVDs are more expensive than those with movies on them. But all you need to do is making a bit by bit copy.
They can hardly claim it circumvents access controls either - you can by a DVD player at pretty much any street corner that can show you the contents on the DVD. The only claim they can make is that it circumvents the 'region controls' (DVDs can be made to be playable only in the US, or only in Europe etc.) but that is easily circumvented by importing a foreign DVD player - a task several orders simpler than implementing the decryption algorithm from a description.
There are only a few places in the solar system that are habitable without major terraforming: the moon, mars, the asteroids and some of the moons of the outer planets. Yes, you'd need a protected environment and wear a spacesuit every time you go out, but you can live that way and there are resources to be utilized.
For the other planets: Mercury is so close to the sun that it fills most of the sky, a major bummer if you try to live on surface. Venus is a hot oven full of high pressure poisonous gasses. No landers on it survived very long, despite extreemly rugged construction. Earth is already taken. The outer planets are gas giants, except for Pluto which is too far away and *really* cold. Some of the moons might be inhabitable, but traveltimes are impractically long.
Which leaves us the moon, mars and the asteroid belt.
By space standards, Mars is actually quite attractive. It's day is close enough to 24 hours that we'd able to adapt. There is an atmosphere, although an extreemly thin one and mostly CO2. But you can get oxygen out of CO2, compress in to get 3psi pressure and fill a 60s style bubble with it. If you can get a good source of water you have most of the resources to support life in those bubbles. If you have water you can also make methane and oxygen out of water and CO2, which can be used as rocket fuel. Given low gravity and a thin atmosphere getting back into space is relatively easy. Mars is cold, but if you stay in the warmer places it isn't too bad, and the thin atmosphere doesn't cool you down to much - in fact for designers of mars suits getting rid of body heat is a major issue.
The main problem is radiation - no magnetic field like earth to protect anyone on the surface. You'd have to spend most time indoors with a thick roof above your head if you're going to live there permanently.
But living on Mars is definately doable with todays technology, and their are most likely enough resources available to be independent from earth after a while.
It's probably worthwhile too. As somebody put it: the dinosaurs died out because they didn't have a space program.
It's really a shame HTML has become some much of a page layout language.
If there would just be a good standard set of those link attributes, to indicate things like 'next', 'up', 'home' etc. then you could put key bindings to them in a browser.
All those HTML message boards (like/. for instance) would work much better if you could just wack keys for 'next message', 'skip thread', 'move up'. No more hunting around with the mouse for all those links and buttons.
I did some reading on the KDE mailing lists, and from what I gather the problem is not so much the efficiency of the calls, but their limitations.
You can't use pointers across a network. All arguments are passed by value. That those values could be passed as fast as a shared library implementation isn't important. Sometimes you just need pointers.
The straw that broke the camel's back for KDE seems to be the plugins for KImageShop. Those plugins would be processing bitmaps - potentially several megabytes of data. For a shared library you just pass a pointer. For something like CORBA you have to:
a) serialize the bitmap to well defined external representation. b) transmit that to the plugin c) unserialize it to a bitmap object again. d) do the real processing e) serialize again d) transmit again f) unserialize again.
This is silly. Nobody is going to run an image processing plugin over the network.
CORBA has a place. When you do want to work across processors / OSes / toolkits / networks / programming languages you *have* to do these steps some way or another, and having something like CORBA is a huge improvement over the ad hoc solution du jour.
You also have to deal with communications failures, the other end going ga ga, latency problems, bandwith problems, how do I find the other end on this big internet thingy anyway, security etc.
If your application is distributed you inherently have these problems, and it's great to have a mechanism to help you solve them.
Why does no one remember that MS actually moved the whole industry many years back? The IBM PC was the answer of the established computing world to home computers, and it managed to combine the worst of both worlds.
Like Linus, I once owned a Sinclair QL. Same vintage as the original IBM PC. Yes, it was cheapskate hardware - uncle Clive would never use a 245 if you could just ploink 8 resistors in the data lines. But it had a decent operating system.
It wasn't the perfect OS, but it was at least done by people who understood the basics of OS design, and applied them. It had did multi processing, had decent device drivers, and was relatively simple to code for even in assembler. Other home computers from that era had decent OSes too - the amiga guys are still lyric about theirs:-)
Home computers were moving from 8 bit / 64K into 16 bit systems, and evolving. Unix was more then 10 years old by then, and the same way that all 16 processors except the 8086 were basically 32 bit processors cut down to what was technically possible the operating systems were mature if cut down to what hardware of the day could handle.
Except for MS-DOS. It was a badly done clone of CP/M. It couldn't do process management. It couldn't do memory allocation. Its device drivers were fundamentally flawed, so everyone bypassed them. It couldn't do serial ports beyond 2400 baud, due to MS-DOS being too stupid. It couldn't handle alternate file systems. It pretty much couldn't do anything except imitate CP/M.
PC hardware was done by someone masturbating over an intel catalog. It had interrupt controllers and DMA controllers, terribly expensive dream parts in those days. MS-DOS defeated their purpose by blocking on every I/O call.
After some years, paying the rent meant programming for MS-DOS. It made everyone who'd ever seen a decent OS puke. Everything was complicated, involved directly accessing hardware, and trying to figure out which of 12 'standards' was currently in use on the machine.
It was no surprise that everything crashed, was difficult to install, and couldn't coexist with anything else.
That lowly QL could have grown quite nicely as more powerful hardware became available - because its OS was a simple and decent abstraction layer. Not so MS-DOS. Remember how many years between the 386 and MS-DOS-alter-ego-windows doing 32 bit most of the time. How many years to virtual memory? How many years and how many horrors before decent networking was possible?
Oh, did you notice that Bill Gates managed to loose BASIC along the way. Home computers of the day always had a simple programming environment available - there was no big gap between users and programmers in those days. It was considered normal that users did a little programming of their own. People didn't do $2000 courses to 'learn' programming - if you had a computer and a bit of talent it was unavoidable to pick it up along the way. We got batch files in return.
COMPUTERS ARE NOT COMPLICATED. It doesn't require magic to get everything to work right. Standards do not have to change every two years. You don't need wizards to protect you from the evil complexity of it all. Simple programming is, in fact, simple.
MS-DOS and Windows made things complicated and frustrating. I'm serious when I say Bill Gates deserves to be tortured to death for pushing MS-DOS down our throats. It caused misery to millions.
Yeah, $75 in electricity. And several billion in development, building and testing.
That's why this mag lev stuff is never used. It's much cheaper to make your rocket a bit bigger than to blow another few billions on a maglev launch assist system.
No, in first approximation he's right. Ignoring the atmosphere, the ideal trajectory would be nearly horizontal. Drag losses, heating and structural loads make that impossible. For the same reason jet liners fly miles high.
Real launch trajectories do turn away somewhat from the vertical from early on, but the first part of the trip is getting some altitude until you're high enough for make some real speed.
I agree that Star Wars is a childrens movie, but saying that the Ewoks and Jar Jar are not too annoying is like saying Microsoft uses fair licensing practices. I am sure all children above the age of 7 agree. Perhaps in the next movie he can have Barney make a cameo? Maybe even have the Teletubbies show up as Jedi Knights
One of the biggest sins a childrens author can commit is thinking he can cut corners because his audience is 'just children'. I can't believe Lucas is taking that defence.
I kind of liked Jar Jar. He wasn't nearly as bad as all the other characters taking all those cliches and plotholes seriously.
64 Gb through 'advanced windowing extension api'?
on
Microsoft Janus
·
· Score: 1
Did anyone notice the following gem in the article:
> Aside from advanced load balancing and clustering > support, the Microsoft Data Center Server kernel will > expand memory support from 4 Gbytes up to 64 > Gbytes by supporting Intel's Physical Address > Extensions (PAEs). In addition, Microsoft's new > Advanced Windowing Extensions APIs will let > software developers take advantage of Intel's PAE and > create applications that can access up to 64 Gbytes of > memory.
Now were does that remind me off? Oh yes, extended memory. Let's hope that they make alternative API, so that we can also have expanded memory! And let's make compilers that can do multiple memory models, depending on whether your code or your data is larger than 4GB! Let's throw in a segmented architecture to make this nostalgia fest complete.
But no worries, I'm sure there's still a nice 64K limit in there somewhere...
(Yes, I suffered under MS-DOS... so they can't do 64 bit and now try to pass it off as some 'Advanced API')
I wonder about this too. While I don't know the exact form in which spam is put out it must be possible to detect it's transmission patterns, both at the transmitting and at the receiving end.
All those ads for spam software I get spammed with promise gigantic amounts of messages per hour. Merely monitoring the transmission line should be able to detect what's going on. Yes, you wouldn't be able to setup a giant mailing list without talking to your ISP first. (That would be the least of your problems in running a giant mailing list.)
Of course there would be 'spam-friendly ISPs', but if the rest of the net collectively cut off access to/from those ISPs...
Then X should detect when the client terminates, and free any resources allocated on behalf of the client. If resources are shared among clients, proper reference counting should take care of that.
Applications are allowed to be buggy. Services like X should, like the kernel, be able to deal with buggy apps because if they don't they'll never be stable themselves.
If there are fundamental problems why X can't clean up after an application that simply means it's protocols are fundamentally broken and should be fixed.
GUI toolkits etc. should in a similar way correct for errors made by an application running on top of it. Although applications should behave properly the reality is that it is often pretty hard to make a complex appliation behave properly under all circumstances, and making sure things get fixed when a broken application exits does wonders for stability.
You have no right to demand perfection from your clients unless you're the soup nazi.
There is a great difference between anonymity and forging. They want to ban forging routing information. A message labeled 'this message has gone through the xyz.org anomynizer' is not forged - it's perfectly correct and true. xyz.com has taken over the responsibility for the content, if there is a problem with the message they will deal with it. If necessary, they will 'forward' the responsibility to the true originator.
Forging tries to put the responsibility with someone else who hasn't got anything to do with it, or tries to avoid any responsibility. This is bad. Very bad. Free speech without any responsibility for what is said is meaningless and usually just serves crooks, hate mongers and such. The whole idea behind free speech is to be able to say what you want without having to hide who you are.
As an example, I remember the Internet 'before AOL'. Before AOL, most people on the net could be traced to real persons because most access was through companies, schools etc. If you had a problem with someone, you complained to their admin and (s)he either axed the account or told you to fuck off. Chronic abusers generally lost their account quickly and got pissed on in real life too.
Sure there were problems. Occasionally.
Then AOL came. They brough hoared of clueless idiots, so bad that having.aol in your address meant you weren't taken serious by anyone. And behold; AOL didn't care about anything but growing bigger! They snail-mail spammed anyone owning a computer with at least two AOL floppies a month. And big they were. They didn't care about anything but growing. AOL users changed their screen names more often than their underware. There was no point in having their account janked because they already had a new one lined up in advance. AOL never gave out real identifying info of any kind of their users. They were truly anonymous.
Before AOL, you could route you mail through servers that removed all identifying information, and there were used e.g. by people posting in the alt.sex hierarchy. But these servers took responsibility for what they did and would come down like a ton of bricks on anyone trying to abuse them.
Many attempts were made decency freaks to shut down those 'lewd' newsgroups. With extreemly little success. Until AOL came around, and gave people true anonimity with no responsibility.
Suddenly there were pest all over the place, picking fights, trolling, spamming, or just making a nuisance of themselves. Mostly loosers that got a power kick out of harrassing other people who couldn't do anything back.
All the newsgroups no one had been able to shut down died within a year of spamming and drive by flames.
> 1. They claim that best hardware for Linux was chosen.
What they mean is that they we willing to replace a RAID interface for which Linux has no decent drivers with one from another manufacturer that has.
As others have pointed out, why not give each side a budget and let them chose the hardware for the task? There are other architectures than i386. There are other ways to use multiple processors than just SMP. There are other ways to get fast I/O other than 4 ethernet adapters in a single machine.
> 2. This configuration isn't 'exotic'. AFAIK It is _typical_ for big network server or web server ( not the one you use in your garage )
NO! It is typical of the configuration you absolutely want to avoid for a big server. It uses outdated processor architecture and a desktop oriented system architecture souped up to the max. It's expensive because everthing is special and bleeding edge, and there is no upgrade path because everything is maxed out already.
If you want a big server you either want to cluster a set of more modest servers (taking advantage of the low price and easy availablity of such systems) or get something from Sun, Dec, Sgi, or IBM that was designed from the start for much higher performance levels.
Just calling something 'enterprise class' doesn't make it a sensible choice.
> 3. NT IS faster than Linux, even on single-processor machines -> TCP/IP stack problem isn't the only one.
Still running 4 ethernet cards no doubt, still hugh quantities of memory, and still completely saturated with a huge number of short I/O requests. Yes, NT has a number of specific enhancements to handle this kind of load, most likely because NetWare kept beating the crap out it in high load file server benchmarks.
Choose somewhat different test parameters and Linux will be faster. The point is that subset of realistic configurations where Linux is faster is getting bigger and bigger. Proclaiming NT to be faster whereas in fact this is true only for a increasingly small subset of configurations running specific tasks is not exactly 'the whole truth'.
4. Mindcraft tests were biased.
They specifically selected a realm were NT was faster, then proudly announced they had found NT to be faster, and pocketed the Microsoft money. That's not bias, it's deceit.
The real thing that makes NT faster is that the entire benchmark (Hardware, type of testing being done etc.) was chosen to match NT's strengths and Linux weaknesses. On purpose.
NT is not faster than Linux. It is faster on this particular exotic HW configuration running fairly ridiculous benchmarks. But note that in all the PC Week headlines these details are dropped, and "NT is faster".
Nor is Mindcraft aquitted of all crimes, no matter what Bruce will try to claim. They were paid by MS, rigged the test in their favor, and presented it as if it were an independent test. That is lying, once you've done that as a testlab you lose all credibility.
Microsoft will just keep inventing benchmarks that happen to make NT look better. Nothing can be done about it, other than observing that those benchmarks will become less realistic every month.
That would make IPIX an excellent target for a trademark infringment lawsuit. Same business area (virtual reality software), very similar names. Pity SGI probably won't sink that low. OTOH, you're supposed to defend your trademarks or risk losing them...
That would be cool - to have such a defence fund. Especially when it's run by a bunch of uncompromising RMS style free software fanatics; they'd attack each and every of this companies patents. Bye bye IPO.
Seriously, companies like IPIX prefer to go after the little fish, victims that simply don't have the money and time to defend themselves properly in court. Sometimes it's just to strengthen their case for when they have to go up against bigger fish.
A defence fund has more advantages than just pooling money. It means you can get a house attorney speciallized in this type of case. You can also setup a PR machine that can quickly get the word out that IPIX is a bunch of shitheads, that their licencing agreement is very restrictive, and that their are free alternatives to their software.
These journalist write for a living, they have deadlines and can spend only a limited amount of time on articles. So around the time they've done installing Linux it is time to start writing... and they run for their windows box.
No matter how good the installation program, installing an OS is a fairly technical process that is likely to have at least a few problems, especially on the insane mess that PC hardware is. You just have to know how the computer works and be able to look up some technical details. It might be doable, but it will never be enjoyable.
Can't RedHat or somesuch give these journalists a box on loan where Linux is already installed, a savvy desktop active with a few good apps ready to use? Preset browser bookmarks to good Linux sites, preload nice themes. Just make a videotape showing how to get around and to show off some stuff. Then they can write on using Linux rather than on installing it.
Because they spend most of their time installing it journalist keep suffering from the impression that Linux (and the BSDs) are something very technical. If everything came installed it would be 'just like windows'. They might actually have time left to try to use it for real.
Slashdot Mirror
Tom Henderson got a lot of flak over the pkarc affair, much of it undeserved. In those days I was involved porting the .ARC format to another OS. The sources of SEA arc were available for non commericial use and they were what made porting arc effectively possible.
.arc files. If you couldn't decompress those files you were locked out of that world.
.arc files. LZW compression was only a very small part of arc.
.arc files anymore! Pkware accidentally had invented the 'embrace and extent' strategy that would be made famous by MS many years later.
.arc format from sort of open source to closed source, made it much more MS-DOS specific and doing so helped make the BBS world much more IBM PC centric. It also served as a dire warning against small companies ever releasing any important source under any kind of licence.
Porting arc was very important for anyone running something other than MSDOS; almost all bbs downloads came as
Luckily SEA's source code was well organized and well documented. This meant it was easily ported to other environments. It also made it relatively easy to reimplement some of the key (de)compression routines in other programs. Well documented source code helps a lot when trying to understand a compression algorithm.
It would also have been easy to create a version of SEA arc with some of the compression code replaced by faster routines. The compression routines were a relatively small part of the code. Also, while there were several compression algorithms in arc only one of them (LZW compression) was actually used 99% of the time. The others were historical and mainly there so you could still read old
Making that algorithm faster wasn't too difficult either. It was written in C, and in those days hand tuned assembler beat code generated by microcomputer compilers by a factor 5 to 10. Also, arc processed it's data byte for byte; switching to a block based strategy for passing data through various stages typically would gain you another factor of 5 to 10.
SEA's suspicion that pkarc might be reusing large parts of arc's source were widely dismissed as nonsense because pkarc was so much faster. But knowing the source code, and given the very similar interface of the two programs it wasn't all that unlikely.
Pkware also added a new compression method that worked better than SEA's LZW compression. This must have been a major blow for SEA commercially - suddenly the latest ARC couldn't read the latest
The new compression method also made porting much more problematic. Pkarc's source was not available. The format was not documented in it's documentation; if it was available it was not widely known. In the it turned out that pkarc's new algorithm was a minor variation the arc LZW format. (It used 13 rather than 12 bit tokens, and the run length encoding preprocessing was removed.)
The final result was that pkarc took the
But PKWare learned it's lesson and went on to produce a steady stream of faster and better compression algorithms. SEA failed to do what it should have done in the first place: solve arc's terrible performance problems. Unisys started behaving like a bunch of jerks.
As an aside:
Around that time free code was usually put in public domain. An endless stream of commercial ripoffs of PD programs with one or two sexy features improved or added was what caused RMS to invent this GPL thing.
This is an incredibly stupid assertion. As one of the DVD sites points out, you don't need to decrypt a DVD to make a copy of it. The only reason no one does is that writable DVDs are more expensive than those with movies on them. But all you need to do is making a bit by bit copy.
They can hardly claim it circumvents access controls either - you can by a DVD player at pretty much any street corner that can show you the contents on the DVD. The only claim they can make is that it circumvents the 'region controls' (DVDs can be made to be playable only in the US, or only in Europe etc.) but that is easily circumvented by importing a foreign DVD player - a task several orders simpler than implementing the decryption algorithm from a description.
There are only a few places in the solar system that are habitable without major terraforming: the moon, mars, the asteroids and some of the moons of the outer planets. Yes, you'd need a protected environment and wear a spacesuit every time you go out, but you can live that way and there are resources to be utilized.
For the other planets:
Mercury is so close to the sun that it fills most of the sky, a major bummer if you try to live on surface.
Venus is a hot oven full of high pressure poisonous gasses. No landers on it survived very long, despite extreemly rugged construction.
Earth is already taken.
The outer planets are gas giants, except for Pluto which is too far away and *really* cold. Some of the moons might be inhabitable, but traveltimes are impractically long.
Which leaves us the moon, mars and the asteroid belt.
By space standards, Mars is actually quite attractive. It's day is close enough to 24 hours that we'd able to adapt. There is an atmosphere, although an extreemly thin one and mostly CO2. But you can get oxygen out of CO2, compress in to get 3psi pressure and fill a 60s style bubble with it. If you can get a good source of water you have most of the resources to support life in those bubbles. If you have water you can also make methane and oxygen out of water and CO2, which can be used as rocket fuel. Given low gravity and a thin atmosphere getting back into space is relatively easy. Mars is cold, but if you stay in the warmer places it isn't too bad, and the thin atmosphere doesn't cool you down to much - in fact for designers of mars suits getting rid of body heat is a major issue.
The main problem is radiation - no magnetic field like earth to protect anyone on the surface. You'd have to spend most time indoors with a thick roof above your head if you're going to live there permanently.
But living on Mars is definately doable with todays technology, and their are most likely enough resources available to be independent from earth after a while.
It's probably worthwhile too. As somebody put it: the dinosaurs died out because they didn't have a space program.
It's really a shame HTML has become some much of a page layout language.
/. for instance) would work much better if you could just wack keys for 'next message', 'skip thread', 'move up'. No more hunting around with the mouse for all those links and buttons.
If there would just be a good standard set of those link attributes, to indicate things like 'next', 'up', 'home' etc. then you could put key bindings to them in a browser.
All those HTML message boards (like
I did some reading on the KDE mailing lists, and from what I gather the problem is not so much the efficiency of the calls, but their limitations.
You can't use pointers across a network. All arguments are passed by value. That those values could be passed as fast as a shared library implementation isn't important. Sometimes you just need pointers.
The straw that broke the camel's back for KDE seems to be the plugins for KImageShop. Those plugins would be processing bitmaps - potentially several megabytes of data. For a shared library you just pass a pointer. For something like CORBA you have to:
a) serialize the bitmap to well defined external representation.
b) transmit that to the plugin
c) unserialize it to a bitmap object again.
d) do the real processing
e) serialize again
d) transmit again
f) unserialize again.
This is silly. Nobody is going to run an image processing plugin over the network.
CORBA has a place. When you do want to work across processors / OSes / toolkits / networks / programming languages you *have* to do these steps some way or another, and having something like CORBA is a huge improvement over the ad hoc solution du jour.
You also have to deal with communications failures, the other end going ga ga, latency problems, bandwith problems, how do I find the other end on this big internet thingy anyway, security etc.
If your application is distributed you inherently have these problems, and it's great to have a mechanism to help you solve them.
If you just want a stinking plugin, it's a pain.
Why does no one remember that MS actually moved the whole industry many years back? The IBM PC was the answer of the established computing world to home computers, and it managed to combine the worst of both worlds.
:-)
Like Linus, I once owned a Sinclair QL. Same vintage as the original IBM PC. Yes, it was cheapskate hardware - uncle Clive would never use a 245 if you could just ploink 8 resistors in the data lines. But it had a decent operating system.
It wasn't the perfect OS, but it was at least done by people who understood the basics of OS design, and applied them. It had did multi processing, had decent device drivers, and was relatively simple to code for even in assembler. Other home computers from that era had decent OSes too - the amiga guys are still lyric about theirs
Home computers were moving from 8 bit / 64K into 16 bit systems, and evolving. Unix was more then 10 years old by then, and the same way that all 16 processors except the 8086 were basically 32 bit processors cut down to what was technically possible the operating systems were mature if cut down to what hardware of the day could handle.
Except for MS-DOS. It was a badly done clone of CP/M. It couldn't do process management. It couldn't do memory allocation. Its device drivers were fundamentally flawed, so everyone bypassed them. It couldn't do serial ports beyond 2400 baud, due to MS-DOS being too stupid. It couldn't handle alternate file systems. It pretty much couldn't do anything except imitate CP/M.
PC hardware was done by someone masturbating over an intel catalog. It had interrupt controllers and DMA controllers, terribly expensive dream parts in those days. MS-DOS defeated their purpose by blocking on every I/O call.
After some years, paying the rent meant programming for MS-DOS. It made everyone who'd ever seen a decent OS puke. Everything was complicated, involved directly accessing hardware, and trying to figure out which of 12 'standards' was currently in use on the machine.
It was no surprise that everything crashed, was difficult to install, and couldn't coexist with anything else.
That lowly QL could have grown quite nicely as more powerful hardware became available - because its OS was a simple and decent abstraction layer. Not so MS-DOS. Remember how many years between the 386 and MS-DOS-alter-ego-windows doing 32 bit most of the time. How many years to virtual memory? How many years and how many horrors before decent networking was possible?
Oh, did you notice that Bill Gates managed to loose BASIC along the way. Home computers of the day always had a simple programming environment available - there was no big gap between users and programmers in those days. It was considered normal that users did a little programming of their own. People didn't do $2000 courses to 'learn' programming - if you had a computer and a bit of talent it was unavoidable to pick it up along the way. We got batch files in return.
COMPUTERS ARE NOT COMPLICATED. It doesn't require magic to get everything to work right. Standards do not have to change every two years. You don't need wizards to protect you from the evil complexity of it all. Simple programming is, in fact, simple.
MS-DOS and Windows made things complicated and frustrating. I'm serious when I say Bill Gates deserves to be tortured to death for pushing MS-DOS down our throats. It caused misery to millions.
Yeah, $75 in electricity. And several billion in development, building and testing.
That's why this mag lev stuff is never used. It's much cheaper to make your rocket a bit bigger than to blow another few billions on a maglev launch assist system.
No, in first approximation he's right. Ignoring the atmosphere, the ideal trajectory would be nearly horizontal. Drag losses, heating and structural loads make that impossible. For the same reason jet liners fly miles high.
Real launch trajectories do turn away somewhat from the vertical from early on, but the first part of the trip is getting some altitude until you're high enough for make some real speed.
One of the biggest sins a childrens author can commit is thinking he can cut corners because his audience is 'just children'. I can't believe Lucas is taking that defence.
I kind of liked Jar Jar. He wasn't nearly as bad as all the other characters taking all those cliches and plotholes seriously.
Did anyone notice the following gem in the article:
... so they can't do 64 bit and now try to pass it off as some 'Advanced API')
> Aside from advanced load balancing and clustering
> support, the Microsoft Data Center Server kernel will
> expand memory support from 4 Gbytes up to 64
> Gbytes by supporting Intel's Physical Address
> Extensions (PAEs). In addition, Microsoft's new
> Advanced Windowing Extensions APIs will let
> software developers take advantage of Intel's PAE and
> create applications that can access up to 64 Gbytes of
> memory.
Now were does that remind me off? Oh yes, extended memory. Let's hope that they make alternative API, so that we can also have expanded memory! And let's make compilers that can do multiple memory models, depending on whether your code or your data is larger than 4GB! Let's throw in a segmented architecture to make this nostalgia fest complete.
But no worries, I'm sure there's still a nice 64K limit in there somewhere...
(Yes, I suffered under MS-DOS
I wonder about this too. While I don't know the exact form in which spam is put out it must be possible to detect it's transmission patterns, both at the transmitting and at the receiving end.
All those ads for spam software I get spammed with promise gigantic amounts of messages per hour. Merely monitoring the transmission line should be able to detect what's going on. Yes, you wouldn't be able to setup a giant mailing list without talking to your ISP first. (That would be the least of your problems in running a giant mailing list.)
Of course there would be 'spam-friendly ISPs', but if the rest of the net collectively cut off access to/from those ISPs...
Why aren't there 'spam-wall' packages around?
Then X should detect when the client terminates, and free any resources allocated on behalf of the client. If resources are shared among clients, proper reference counting should take care of that.
Applications are allowed to be buggy. Services like X should, like the kernel, be able to deal with buggy apps because if they don't they'll never be stable themselves.
If there are fundamental problems why X can't clean up after an application that simply means it's protocols are fundamentally broken and should be fixed.
GUI toolkits etc. should in a similar way correct for errors made by an application running on top of it. Although applications should behave properly the reality is that it is often pretty hard to make a complex appliation behave properly under all circumstances, and making sure things get fixed when a broken application exits does wonders for stability.
You have no right to demand perfection from your clients unless you're the soup nazi.
There is a great difference between anonymity and forging. They want to ban forging routing information. A message labeled 'this message has gone through the xyz.org anomynizer' is not forged - it's perfectly correct and true. xyz.com has taken over the responsibility for the content, if there is a problem with the message they will deal with it. If necessary, they will 'forward' the responsibility to the true originator.
.aol in your address meant you weren't taken serious by anyone. And behold; AOL didn't care about anything but growing bigger! They snail-mail spammed anyone owning a computer with at least two AOL floppies a month. And big they were. They didn't care about anything but growing. AOL users changed their screen names more often than their underware. There was no point in having their account janked because they already had a new one lined up in advance. AOL never gave out real identifying info of any kind of their users. They were truly anonymous.
Forging tries to put the responsibility with someone else who hasn't got anything to do with it, or tries to avoid any responsibility. This is bad. Very bad. Free speech without any responsibility for what is said is meaningless and usually just serves crooks, hate mongers and such. The whole idea behind free speech is to be able to say what you want without having to hide who you are.
As an example, I remember the Internet 'before AOL'. Before AOL, most people on the net could be traced to real persons because most access was through companies, schools etc. If you had a problem with someone, you complained to their admin and (s)he either axed the account or told you to fuck off. Chronic abusers generally lost their account quickly and got pissed on in real life too.
Sure there were problems. Occasionally.
Then AOL came. They brough hoared of clueless idiots, so bad that having
Before AOL, you could route you mail through servers that removed all identifying information, and there were used e.g. by people posting in the alt.sex hierarchy. But these servers took responsibility for what they did and would come down like a ton of bricks on anyone trying to abuse them.
Many attempts were made decency freaks to shut down those 'lewd' newsgroups. With extreemly little success. Until AOL came around, and gave people true anonimity with no responsibility.
Suddenly there were pest all over the place, picking fights, trolling, spamming, or just making a nuisance of themselves. Mostly loosers that got a power kick out of harrassing other people who couldn't do anything back.
All the newsgroups no one had been able to shut down died within a year of spamming and drive by flames.
> 1. They claim that best hardware for Linux was chosen.
What they mean is that they we willing to replace a RAID interface for which Linux has no decent drivers with one from another manufacturer that has.
As others have pointed out, why not give each side a budget and let them chose the hardware for the task? There are other architectures than i386. There are other ways to use multiple processors than just SMP. There are other ways to get fast I/O other than 4 ethernet adapters in a single machine.
> 2. This configuration isn't 'exotic'. AFAIK It is _typical_ for big network server or web server ( not the one you use in your garage )
NO! It is typical of the configuration you absolutely want to avoid for a big server. It uses outdated processor architecture and a desktop oriented system architecture souped up to the max. It's expensive because everthing is special and bleeding edge, and there is no upgrade path because everything is maxed out already.
If you want a big server you either want to cluster a set of more modest servers (taking advantage of the low price and easy availablity of such systems) or get something from Sun, Dec, Sgi, or IBM that was designed from the start for much higher performance levels.
Just calling something 'enterprise class' doesn't make it a sensible choice.
> 3. NT IS faster than Linux, even on single-processor machines -> TCP/IP stack problem isn't the only one.
Still running 4 ethernet cards no doubt, still hugh quantities of memory, and still completely saturated with a huge number of short I/O requests. Yes, NT has a number of specific enhancements to handle this kind of load, most likely because NetWare kept beating the crap out it in high load file server benchmarks.
Choose somewhat different test parameters and Linux will be faster. The point is that subset of realistic configurations where Linux is faster is getting bigger and bigger. Proclaiming NT to be faster whereas in fact this is true only for a increasingly small subset of configurations running specific tasks is not exactly 'the whole truth'.
4. Mindcraft tests were biased.
They specifically selected a realm were NT was faster, then proudly announced they had found NT to be faster, and pocketed the Microsoft money. That's not bias, it's deceit.
The real thing that makes NT faster is that the entire benchmark (Hardware, type of testing being done etc.) was chosen to match NT's strengths and Linux weaknesses. On purpose.
NT is not faster than Linux. It is faster on this particular exotic HW configuration running fairly ridiculous benchmarks. But note that in all the PC Week headlines these details are dropped, and "NT is faster".
Nor is Mindcraft aquitted of all crimes, no matter what Bruce will try to claim. They were paid by MS, rigged the test in their favor, and presented it as if it were an independent test. That is lying, once you've done that as a testlab you lose all credibility.
Microsoft will just keep inventing benchmarks that happen to make NT look better. Nothing can be done about it, other than observing that those benchmarks will become less realistic every month.
That would make IPIX an excellent target for a trademark infringment lawsuit. Same business area (virtual reality software), very similar names. Pity SGI probably won't sink that low. OTOH, you're supposed to defend your trademarks or risk losing them...
That would be cool - to have such a defence fund. Especially when it's run by a bunch of uncompromising RMS style free software fanatics; they'd attack each and every of this companies patents. Bye bye IPO.
Seriously, companies like IPIX prefer to go after the little fish, victims that simply don't have the money and time to defend themselves properly in court. Sometimes it's just to strengthen their case for when they have to go up against bigger fish.
A defence fund has more advantages than just pooling money. It means you can get a house attorney speciallized in this type of case. You can also setup a PR machine that can quickly get the word out that IPIX is a bunch of shitheads, that their licencing agreement is very restrictive, and that their are free alternatives to their software.
These journalist write for a living, they have deadlines and can spend only a limited amount of time on articles. So around the time they've done installing Linux it is time to start writing ... and they run for their windows box.
No matter how good the installation program, installing an OS is a fairly technical process that is likely to have at least a few problems, especially on the insane mess that PC hardware is. You just have to know how the computer works and be able to look up some technical details. It might be doable, but it will never be enjoyable.
Can't RedHat or somesuch give these journalists a box on loan where Linux is already installed, a savvy desktop active with a few good apps ready to use? Preset browser bookmarks to good Linux sites, preload nice themes. Just make a videotape showing how to get around and to show off some stuff. Then they can write on using Linux rather than on installing it.
Because they spend most of their time installing it journalist keep suffering from the impression that Linux (and the BSDs) are something very technical. If everything came installed it would be 'just like windows'. They might actually have time left to try to use it for real.