Often times when someone writes something useful, other programmers want to use it as a building block in larger applications. The problem is that the interpreted languages make this kind of system building almost impossible. While your WonderWidget might work well for parsing a single file or two, the performance differences really begin to show up when it gets called for every file in a directory, or is scaled up to handle large files. An order of magnitude difference is trivial when used in an end-user application and the elapsed time is only a second or two. But that difference becomes really significant when working with large amounts of data.
I know people downplay the performance disadvantages of interpreted languages, but this is still a very real problem for businesses. A small corporate system has a thousand modules; the larger ones have upwards of 30,000. A single millisecond difference in execution speed makes a full second difference in user response time. While one second isn't likely to be noticed by a consumer-grade web user, online help desks can't wait 30 seconds for a page to load.
I guess I should qualify this further. I know of projects using interpreted languages that have failed - the application did work - albeit, it took 30 seconds (best time) to 5 minutes to respond to a single keystroke. It was later abandoned because despite buying faster hardware, the programmers couldn't get better than a 20 second response time. An average improvement of just 15 milliseconds per module would have saved the project!
Custom kernel building was not performed since most customers would
not be willing or able to perform or support such a customized environment.
While this may be true of Microsoft's customers, it is definitely not true of IBM's. For many years, IBM distributed software in source form, which was then compiled and optimized by the systems programmer for the particular machine installation.
Of course, I didn't expect a study funded by Microsoft to be objective, but I can't help but think that this study is going to do them more harm than good. Any mainframe programmer reading this is going to laugh at the naivete shown - no custom compiles? On a mainframe?! What were these folks smoking?
"WinTel Server 10 Times Less Expensive to Operate Than Linux Mainframe"
So why would anyone still run mainframes?
Oh, that's right - downtime on a WinTel server is still 100 times more expensive than Linux Mainframes.
Where I sit, the average cost of staff is around $45/hour. With 100 people in our organization dependent on mainframe access, when our mainframe goes down, it costs us $4500 per hour.
If we were using WinTel servers for our datacenter, even a single hour of downtime would double the TCO. Even 5 minutes of lost productivity would cost us $375 - and double the cost of Windows. The weekend the Blaster worm hit, for instance, cost a certain well-known local insurance company $50,000. And that was just over the weekend. Total cleanup is expected to cost more than a million dollars!
We can't afford viruses. We can't afford mandatory updates. We can't accept arbitrary updates which change the EULA. Even a single hour of downtime per year is one too many.
Microsoft just doesn't get it. Hardware and Software licensing costs, and even staffing, are far from Total Cost of Ownership. System downtime is the single largest factor in the "real" TCO - something that Microsoft conveniently forgets.
Yeah, I think the real problem is that slashdot concentrates on specific security problems rather than design problems. Quite frankly, I only read the headlines when I hear of Yet Another Microsoft Security Hole. It's not news - it's the expected result of poor design. And quite frankly, if a lot of slashdotters _weren't_ running Windows, it wouldn't be an issue.
Is this just more proof that Linux was built by amateurs? Or wait - I know - that Linux can't be trusted because the source code is open.
Now, for those who think I'm serious, think about it for a moment. Slashdot hypes up every single MS vulnerability as "proof" that MS systems are inherently insecure. And I wouldn't disagree that MS systems are insecure. But discovering a single (or a few) vulnerability doesn't make an OS insecure.
What it comes down to is vigilance and design. The numerous security holes in MS products are a result of bad design, not merely a mistake or two. And this is the big difference between this vulnerability - a mere isolated mistake - and Microsoft's complete lack of engineering which ensures that their software _will_ have security holes.
Part of me is wondering if this is necessarily a bad thing. Why not sell CD's containing bogus addresses to "poison the well" of spammers as it were? The ideal situation would be one in which 1.) every address was invalid, and 2.) the spammers paid for every bounce via bandwidth charges.
To be honest, this might be the most effective way of reducing spam. Simply register a large number of TLD's with the same IP address, make up bogus email addresses using said TLD's, and sell it on CD. Use the money from the sales to support the hardware and infrastructure costs. As an added bonus, one could sell several "levels" of lists - one CD would have a bunch of email addresses, another would have a mix of valid and invalid addresses, and for a premium, a spammer could buy a list of guaranteed valid addresses. Of course, just because the address is valid doesn't mean a human has to read it - a script could be used to set up and clean "valid" email accounts on the sacrificial server.
It would work out well for everyone, except the businesses who hire spammers. Spammers would be able to rake in cash by charging by the mailing. The email addresses would be legitimate, but nobody would actually have to read the spam. And those of us who hate spam wouldn't have to deal with it as much.
I don't know... Something about taking money from a spammer just warms my heart, even if it is a rip off...
Granted, even with electronic methods, _perfect_ lossless copying is still impossible. Parity bits will only detect a single bit inversion; inverting two bits will not alter the parity at all. Likewise, the Hamming code makes the transmission of errors improbable, but not impossible.
Even with the stemmata, there exists only a very limited number of potential manuscripts. Furthermore, in regard to the Bible, there is a great deal of consistency - among the few thousand known manuscripts, none of the differences are so great that they would affect any official doctrinal position or tenet of the faith.
In the ancient world, scripture played the same role that the Constitution plays in modern America. It was the standard by which society was ruled. It was not simply literature for personal inspiration or entertainment. Because of its public and legal role, the accurate copying of the scriptures was of paramount importance. One suggesting the Bible differs substantially from the original might as well make the same claim regarding the Constitution - after all, it's been more than 200 years! (Now before pointing out that we still have the original, ask yourself how many textbook publishers actually go to the national archives and transcribe from the original. Chances are, the closest they get is a grainy photograph of the original.)
Mis-transcribing a children's story or parable is a much different matter than mis-transcribing "the Law", as it was known. The disparity of copying quality between the Bible and other ancient manuscripts should come as no surprise to those who understand the role that the scriptures played in the ancient world. To change scripture in the ancient world would be the equivalent of a textbook publisher publishing a "revised" version of the Constitution today. One who did so would expect to retain neither their reputation nor their profession.
I do believe that there are "codes" in the Bible, but the reason is different than what the fanatics describe. My belief is that the Bible codes exist for only one reason: to ensure accuracy. Consider the following:
The cat in the hat caught a rat and that was the end of that.
Notice the rhyming. Now translated into spanish (courtesy babelfish):
El gato en el sombrero cogio una rata y ese era el final de eso.
Now translated back into english:
The cat in the hat took a rat and that one was the end of that.
Okay, so notice in the original that the rhyming words appeared in positions 1, 4, 7, 9, and 14 (zero based). In the retranslation, the rhyming words appear in positions 1, 4, 7, 9 and 15. This disparity alone is enough to determine that the retranslation is not accurate.
Supposing that one writes in such a manner that there is a definitive pattern to their sentences and word choices, it is easy to determine the accuracy of a text after having gone through many translations. For a book such as the Bible, this was of paramount importance. I believe the original purpose of the "Bible codes" was to ensure that the meaning of scripture was not lost as it was passed from one generation to the next.
Consider for example, the poem. If a poem is incorrectly copied, it no longer rhymes, or the meter is disrupted. This simple mechanism not only ensures easy memorization, but provides a security against unintended alteration. In much the same manner, the "Bible codes" have provided scholars a way of discerning the accuracy of a copy of scripture. In fact, some of scripture is indeed poetic, further reinforcing the confidence in the original scriptures.
I find it somewhat interesting that lossless copying was available long before digital electronics were invented.
Yeh huell? Methinkses int et so easy ferfun fule...
And then there are the folks who can wix up mords, mometimes in sid-sentence, on fle thy. (Yes, I'm just as fluent when speaking as well. With dome sifficulty, I man wix up three cords as well.)
I don't know if it was a side effect of all the programming I've done, or just some latent dyslexia, but I'm able to mix up words and invent new ones with relative ease. Perhaps the challenge of having to remember umpteen different passwords, and change them every month did it. Consider:
Transflagradation - being flamed by someone who's mistaken you for someone else; commonly caused by someone accidentally replying to the wrong thread...
Insidoctrinate - convincing someone else to believe something absurd based on logical arguments....
Well, that's an even better idea - provided one has the time.
Even a small consulting business is much more than forty hours a week. For those who want to make money, though, it is very profitable. I could double my salary if I did consulting.
You're worth more than they're willing to pay for the position. You'll stick around just long enough to find a better paying job, or get promoted.
They know that you know how much you're worth - the guy just barely qualified doesn't. This is bad for them from salary negotiation standpoint.
You may be more qualified than your boss. No boss wants to hire someone he believes will get promoted before him.
The company doesn't want to pay any more than they have to for the position. Granted, you're worth more, but they might not need high quality work.
Which is why I apply for jobs I'm just barely qualified to do. But then I hear:
We want someone with experience.
What makes you believe you could handle a <insert intimidating buzzword-laden computer system here>?
How much did you make at your last job? Oh? What makes you think you deserve a step up?
Etc...
Frankly, it doesn't matter. An HR employee who doesn't like you, or even their job, for that matter, is going to make sure you don't get the job. They've got a list of excuses for every possible scenario:
You're overqualified.
You're underqualified.
You don't have enough experience.
You have more experience than we need - we're looking for people to train...
Your last salary was too high - we can't afford you.
Your last salary was too low - you must not do very good work.
Your salary request was too low - you must not be very confident of your abilities.
Your salary request was too high - you're just a greedy b********.
You don't have experience with version X. We don't care about your experience with version Y.
We need someone who knows the system already. (Even if it was custom built!)
We want someone who is more well-rounded.
You've done COBOL, eh? Well, you must not be very good at Java, then... (replace COBOL and Java with any dissimilar technologies, and repeat).
We don't want people with legacy experience - we're an Object Oriented shop.
And the list goes on....
There's no silver bullet to getting hired. Just put down what you're good at and submit your resume.
The CD-RW has not replaced the floppy. You cannot edit the files on a CD-RW the same way you would edit files on a floppy or zip disk. You either erase and reburn the entire disk, or you copy the files to a temp directory and reburn once you're finished. And since reburn takes about 5-10 minutes, I really doubt students will save and backup their work at regular intervals.
Yes, a CD-RW does hold more. But they don't solve the fundamental problem of being able to edit one's work from any computer.
Until something better comes along, I'm using Zip disks. The larger ones will hold 750MB, and they are almost as fast as a hard drive. Plus, I can edit and save files in place, without going through some special software.
Now you might say that zip drives are relatively rare, and you'd be right. But just try to read your CD-RW in a WindowsNT system, or try to edit it in an older machine without a burner.
It's the same compatibility problem: floppies worked because, despite their disadvantages, they were the one media that every PC could read and write. Now it looks as if it's going to be a while before there's a de facto standard for a read-write-update media.
And no, CD-R/RW aren't better than floppies for data storage. In fact, they're worse, because much more is lost when they fail. I've had CD-R's go bad after six months of storage in a closet. Contrast this with Zip disks that have lasted several years.
I used to think the same thing about getting rid of floppies, until I bought a machine without one.
Even though it's slow, and small, a floppy is the one common denominator among almost every PC in use today - except mine.
Floppies Just Work(tm).
I don't have to configure networking. I don't have to ask them to burn me a CD (some don't even have burners). I don't need ten different networking configurations for every possible OS version out there. I don't have to wait for a CD to finish burning(5 minutes...) when I want to send them a 10kB text document. I don't have to worry if they don't have UFS drivers for their OS *cough* NT *cough*. I don't need to worry about whether or not they've got USB drivers (or heck, even a USB port!).
Yeah, I don't like the floppy, but it's much more inconvenient living without it - especially if you've got to transfer files between work and home machines.
I'm pretty sure that a freeDOS boot floppy would work just as well as a Win95 boot disk.
Most BIOS flashing utilities run in 16 bit real mode, and I believe the reason why Tyan specifies a Win95/98 boot disk is because it's the version of a DOS boot disk that most readily available. I'd bet that the utility would run just fine under DOS 6.0, or any other DOS.
And if you really must insist on using Linux, you might want to look up DOSemu, if it still exists. Last I heard, they're using the freeDOS kernel.
IIRC, the only system service which a Flash utility uses is the executable loader. I would think that any program capable of loading the.com or.exe files in real mode would suffice for your purposes. Since Win95/98/DOS doesn't have the direct ability to flash the BIOS, the only system services the flash utility might use are the file opening and reading services - which I believe freeDOS supports.
..doesn't attaching the engine to the wheel seem like the *most* logical choice in the first place? Why build complicated transmission mechanisms and a centralized engine in the first place?
In the first place, the transmission is the least complicated component of an automobile; today's computer controlled engines make a manual transmission (and even an automatic, sans the valve body) simply by comparison.
Automakers found that a smaller engine (less weight) could run cleaner, more efficiently, and produce more power if it was tuned for a small rpm range. Witness Indy cars - 3 liter V12 engines producing ~750-850 horsepower - contrast with 180 hp for the average 3 liter sedan engine. The drawback was that the engine couldn't produce enough power at low rpm's to start the vehicle moving. Hence the necessity of the transmission.
Smaller engines meant smaller mass. Smaller mass meant better fuel economy, and greater agility. And then there's the torque issue.
By far, the gear train has the greatest impact on the off-the-line performance of a vehicle. With engines getting smaller to meet EPA guidelines, automakers found that by tuning an engine to produce horsepower in a narrow range, they could get more horsepower for a given engine size. Given the right transmission, a driver could keep the engine spinning in the peak-horsepower range, and thus achieve much greater acceleration than possible without a transmission.
There has been a lot of controversy surrounding Linux - first with DeCSS, and now with SCO.
I wonder if the entertainment cartel is aware that SCO has probably, at some point in the past, distributed the DeCSS code with the Linux kernel. I wonder how the RIAA would react to SCO claiming ownership of this "Linux". If indeed, they owned Linux as they claim, wouldn't it make them liable for distributing a "circumvention device" under the DMCA?
I'm wondering if the RIAA is going to sue SCO should SCO win "ownership" of Linux? After all, SCO won't reveal exactly which parts it "owns", so we have to assume they claim all of it - the good, the bad, and the DeCSS....
As for Linux proper, it's no big deal to remove DeCSS should it exist in the kernel. But for a company such as SCO to claim ownership of it implies that they created it - a fact which would make them guilty of willful infringement under the DMCA. So Linux could very easily survive the scourge by claiming ignorance, whereas SCO could go from predator to prey.
Smithers: Did you hear? "Loser Pays" has now become law; if we sue someone and lose, we'll have to pay their legal fees!
CEO: Perfect.
Smithers: WHAT?! Do you know what this means?
CEO: I know EXACTLY what it means. It means we'll hire the most expensive lawyers we can find. It means that no one will risk paying a million dollars in legal fees if they lose their ten grand lawsuit against us. It means when we sue people, they'll settle because the cost of losing just got higher. It means that we can rip off the customer even more! We'll have the best lawyers in the country - we're bound to win, and we'll make our victims pick up the tab! Yessss, this is EXACTLY what we wanted....
Well, that was a good troll. I think, however, that you inadvertently made a point that needs attention.
There are a lot of people prejudiced against those who know more than they do. Their inferiority complex causes them to believe that it's impossible for someone to be both humble and more knowledgeable than them.
I find that it's very difficult to convince stupid people that you know more than they do. You see, a stupid person actually believes that their self worth is a factor of how much they know. If I claim to know more, it must be because I think I'm a better person, right? To them, it's impossible to fathom that I might know more than they do in one particular area because I've spent time studying it. They can't understand that a person's worthiness is independent of their intellectual capacity.
I think you missed the point. It's not about judging another person's choice so much as explaining it. The failure of Linux to be widely adopted on the desktop is the result of the way it was designed.
A person can drive a car without an intimate knowledge of thermodynamics and combustion theory. A person can use a washing machine without knowing the chemistry involved. Yet Linux zealots often expect computer users to undertand some rather arcane computer science concepts. To those who want to use a computer as a means rather than an end, this is just an impediment to getting the real work done.
Windows fills one need, Linux another. It has nothing to do with who is better, but rather with which OS better suits the particular user.
Back when I was a rabid Linux fan, I had a professor say to me, "We use operating systems for what they're good for, not what their bad at..."
Which kind of turned my head around and made me think of Linux and Windows differently. Linux fills a need that Microsoft can't - it's a secure, reliable operating system.
Windows, OTOH, is for people who _don't_ like computers - it makes an otherwise awkward experience at least a little tolerable. Given that the majority of America would rather get drunk and watch football, the popularity of Windows is easily explained. Because most normal people's lives _don't_ revolve around their computer, it's easy for them not to care about Windows reliability problems - they don't want to become a computer expert just so they can read their email.
I have no idea whether the databases of the future will store their data in XML form or not
Not likely. XML is designed to solve the data identification problem, not the data storage problem.
Due to the heirarchical nature of XML, a validating parser must read the entire document before returning any results. Given the way that most parsers are designed, the entire document will be read into memory and first parsed, then validated. Which, of course, limits the size of your database to the machine's memory.
The relational databases aren't going to go away. XML is more like a text-mode IMS for the PC. For those who have never heard of IMS, it was a heirarchical database built for IBM mainframes back in the 60's. When DB2 came out with it's relational model, IMS was largely abandoned. XML is no different, except it incurs a significant performance penalty - it isn't indexed, so binary searches are automatically precluded. Instead, searching a large XML "database" would require using a linear search after loading the document into memory.
But I think I've heard it best put by a manager, "XML forces your database to follow an arbitrary structure. It forces your database to be built around the presentation of the data, rather than the efficiency of retrieval." Until then, I hadn't thought about it in those terms, but I realized that he was exactly right. With a relational database, it's easy to represent many different views and relationships of the same data. But with XML, you're stuck with what the DTD designer believes necessary - the presentation in effect dictates the database structure.
I like XML as an exchange format. But it's the COBOL of the new millenium. The inherent inefficiencies involved (the entire document must be read to extract a single node?), and the inflexibility of relationships (it will always be heirarchical), make it a poor candidate for a database format.
Yes, I've used XML as a database format, with horrible results. A year or so ago, I used it for a financial application. I had written the frontend, and later decided to write an add-on piece which would compile statistics about the transaction data. Rather than being able to read a single record and do things like:
Now tell me that's an improvement!? And should I change my DTD, this code would useless. Yes, I could add fields, but I can't otherwise change the structure of the document without invalidating all of my code.
So XML isn't really as "universal" as the pundits would like to claim. In order to parse an XML document, you still need the DTD, and should the DTD change, your code will be broken. Here's a brief comparison of database formats:
XML
Memory Constrained
No update in place (requires entire file rewrite)
No fast search (1)
Not architecture independent (2)
Not self-documenting(3)
Comma delimited:
No update in place (requires entire file rewrite)
No fast search (1)
Not architecture independent (2)
Not self-documenting(3)
Fixed Width:
Update in place
Fast search (on indexed/sorted fields)
Not architecture independent
Not self-documenting.
Okay, flame away. Basically, XML doesn't offer any advantages to the old fixed-width mainframe formats, except possibly that it can be editted with a text editor. But it's not like any self-respecting DBA would let a programmer edit a production database with a text editor, so it's a moot point anyway.
Notes:
1. Since the record and field boundaries can be predicted in advance, a fixed width file doesn't need to pa
Encryption is now considered a weapon by the State Department.
I wonder how long it will be before the State Department and the content cartel go head to head over the issue: the content cartel arguing that they need unbreakable encryption to protect their content, and the State Department arguing that they need to limit encryption strength to catch "terrorists". The results will be interesting.
That the US will delete this data when the three years are over? More likely, it will be "removed" from one database only to go into another more classified database at the NSA or FBI.
That Microsoft will someday be able to release a stable operating system?
Sorry, I just couldn't resist...
</troll>
But seriously, it looks as if the mere presence of Linux is having an effect on Redmond. Perhaps Microsoft will produce better systems than they have in the past if they consider Linux a threat to their business model. Nothing inspires excellence like a little competition...
Anything written by RMS has a certain stigma attached to it which tends to polarize the discussion. Rather than parrot the FSF party line, I'd rather expose readers to some new ideas.
Part of the problem with posting a link to Right to Read is that it implies content consumers have the right to enjoy the work of an author without compensating the author for their effort. That argument is better left avoided, as it adds nothing to the discussion.
Besides, Stallman didn't go so far as to suggest that publishing one's own content would be heavily restricted. But I can see the day coming when it will be illegal to even create works without approval from government authorities. In fact, it has already happened; Communist China comes to mind.
The real problem I see is that consumers are more concerned with the here and now than the gradual changes encroaching upon their freedoms. Most people expect to pay for books and movies and music - what they don't expect is that the technology which is first sold as a protection measure will be later used to destroy their freedom of expression. (First ammendment nullified by technical measures, anyone?)
The FBI stopped by to see me earlier this morning.
Apparently, they found an unlicensed compiler on one of my student's computers. Copyright central has visited the campus on more than one occasion, so I expected this to be fairly routine. Far from it - for the better part of the morning, they questioned me about this kid's activities. Being a college professor, I couldn't tell them much. This was probably the first time that a student was glad his professor didn't pay more attention to him.
I don't think he's been charged yet, but I was able to discover the nature of what he'll be charged with. The unlicensed compiler is problematic, though not technically illegal since it can't sign object code (illegally). Instead, he was found with a great deal of original material - some dating back 10 years or more - that was never registered with the copyright office. Some was on paper, but most of it was on disk. At a dollar per kB, he's looking at close to a million dollars in fines, not to mention a felony conviction.
But I think that's the least of his worries. About 15 years ago, unlicensed media formats became illegal. In order to record music or video today, you must use one of the state-approved formats which incorporate DRM, and you have to digitally sign the file. Given that the encoders are patented and held by private companies, it's not surprising to learn that leasing a music encoder (just the softare!) costs about $50,000 per year. And after you are finished recording, a general distribution license costs another $50,000 per year. Writing your own encoder would land you in jail for creating a "circumvention device". Which is why anyone who owns a compiler is viewed with suspicion, even though such ownership is not strictly illegal.
Apparently, this kid had a few mp3 files (illegal format), a few mp3 encoders (illegal tools - a felony), and a plethora of original content which hadn't been registered with Copyright Central. He's probably looking at about ten to fifteen years in jail, plus some pretty hefty fines.
Slashdot Mirror
Scalability and code reuse.
Often times when someone writes something useful, other programmers want to use it as a building block in larger applications. The problem is that the interpreted languages make this kind of system building almost impossible. While your WonderWidget might work well for parsing a single file or two, the performance differences really begin to show up when it gets called for every file in a directory, or is scaled up to handle large files. An order of magnitude difference is trivial when used in an end-user application and the elapsed time is only a second or two. But that difference becomes really significant when working with large amounts of data.
I know people downplay the performance disadvantages of interpreted languages, but this is still a very real problem for businesses. A small corporate system has a thousand modules; the larger ones have upwards of 30,000. A single millisecond difference in execution speed makes a full second difference in user response time. While one second isn't likely to be noticed by a consumer-grade web user, online help desks can't wait 30 seconds for a page to load.
I guess I should qualify this further. I know of projects using interpreted languages that have failed - the application did work - albeit, it took 30 seconds (best time) to 5 minutes to respond to a single keystroke. It was later abandoned because despite buying faster hardware, the programmers couldn't get better than a 20 second response time. An average improvement of just 15 milliseconds per module would have saved the project!
While this may be true of Microsoft's customers, it is definitely not true of IBM's. For many years, IBM distributed software in source form, which was then compiled and optimized by the systems programmer for the particular machine installation.
Of course, I didn't expect a study funded by Microsoft to be objective, but I can't help but think that this study is going to do them more harm than good. Any mainframe programmer reading this is going to laugh at the naivete shown - no custom compiles? On a mainframe?! What were these folks smoking?
So why would anyone still run mainframes?
Oh, that's right - downtime on a WinTel server is still 100 times more expensive than Linux Mainframes.
Where I sit, the average cost of staff is around $45/hour. With 100 people in our organization dependent on mainframe access, when our mainframe goes down, it costs us $4500 per hour.
If we were using WinTel servers for our datacenter, even a single hour of downtime would double the TCO. Even 5 minutes of lost productivity would cost us $375 - and double the cost of Windows. The weekend the Blaster worm hit, for instance, cost a certain well-known local insurance company $50,000. And that was just over the weekend. Total cleanup is expected to cost more than a million dollars!
We can't afford viruses. We can't afford mandatory updates. We can't accept arbitrary updates which change the EULA. Even a single hour of downtime per year is one too many.
Microsoft just doesn't get it. Hardware and Software licensing costs, and even staffing, are far from Total Cost of Ownership. System downtime is the single largest factor in the "real" TCO - something that Microsoft conveniently forgets.
Yeah, I think the real problem is that slashdot concentrates on specific security problems rather than design problems. Quite frankly, I only read the headlines when I hear of Yet Another Microsoft Security Hole. It's not news - it's the expected result of poor design. And quite frankly, if a lot of slashdotters _weren't_ running Windows, it wouldn't be an issue.
For the Microsoft trolls to pick this one up.
Is this just more proof that Linux was built by amateurs? Or wait - I know - that Linux can't be trusted because the source code is open.
Now, for those who think I'm serious, think about it for a moment. Slashdot hypes up every single MS vulnerability as "proof" that MS systems are inherently insecure. And I wouldn't disagree that MS systems are insecure. But discovering a single (or a few) vulnerability doesn't make an OS insecure.
What it comes down to is vigilance and design. The numerous security holes in MS products are a result of bad design, not merely a mistake or two. And this is the big difference between this vulnerability - a mere isolated mistake - and Microsoft's complete lack of engineering which ensures that their software _will_ have security holes.
Okay, flame away Microsofties!
Part of me is wondering if this is necessarily a bad thing. Why not sell CD's containing bogus addresses to "poison the well" of spammers as it were? The ideal situation would be one in which 1.) every address was invalid, and 2.) the spammers paid for every bounce via bandwidth charges.
To be honest, this might be the most effective way of reducing spam. Simply register a large number of TLD's with the same IP address, make up bogus email addresses using said TLD's, and sell it on CD. Use the money from the sales to support the hardware and infrastructure costs. As an added bonus, one could sell several "levels" of lists - one CD would have a bunch of email addresses, another would have a mix of valid and invalid addresses, and for a premium, a spammer could buy a list of guaranteed valid addresses. Of course, just because the address is valid doesn't mean a human has to read it - a script could be used to set up and clean "valid" email accounts on the sacrificial server.
It would work out well for everyone, except the businesses who hire spammers. Spammers would be able to rake in cash by charging by the mailing. The email addresses would be legitimate, but nobody would actually have to read the spam. And those of us who hate spam wouldn't have to deal with it as much.
I don't know... Something about taking money from a spammer just warms my heart, even if it is a rip off...
Granted, even with electronic methods, _perfect_ lossless copying is still impossible. Parity bits will only detect a single bit inversion; inverting two bits will not alter the parity at all. Likewise, the Hamming code makes the transmission of errors improbable, but not impossible.
Even with the stemmata, there exists only a very limited number of potential manuscripts. Furthermore, in regard to the Bible, there is a great deal of consistency - among the few thousand known manuscripts, none of the differences are so great that they would affect any official doctrinal position or tenet of the faith.
In the ancient world, scripture played the same role that the Constitution plays in modern America. It was the standard by which society was ruled. It was not simply literature for personal inspiration or entertainment. Because of its public and legal role, the accurate copying of the scriptures was of paramount importance. One suggesting the Bible differs substantially from the original might as well make the same claim regarding the Constitution - after all, it's been more than 200 years! (Now before pointing out that we still have the original, ask yourself how many textbook publishers actually go to the national archives and transcribe from the original. Chances are, the closest they get is a grainy photograph of the original.)
Mis-transcribing a children's story or parable is a much different matter than mis-transcribing "the Law", as it was known. The disparity of copying quality between the Bible and other ancient manuscripts should come as no surprise to those who understand the role that the scriptures played in the ancient world. To change scripture in the ancient world would be the equivalent of a textbook publisher publishing a "revised" version of the Constitution today. One who did so would expect to retain neither their reputation nor their profession.
I do believe that there are "codes" in the Bible, but the reason is different than what the fanatics describe. My belief is that the Bible codes exist for only one reason: to ensure accuracy. Consider the following:
The cat in the hat caught a rat and that was the end of that.
Notice the rhyming. Now translated into spanish (courtesy babelfish):
El gato en el sombrero cogio una rata y ese era el final de eso.
Now translated back into english:
The cat in the hat took a rat and that one was the end of that.
Okay, so notice in the original that the rhyming words appeared in positions 1, 4, 7, 9, and 14 (zero based). In the retranslation, the rhyming words appear in positions 1, 4, 7, 9 and 15. This disparity alone is enough to determine that the retranslation is not accurate.
Supposing that one writes in such a manner that there is a definitive pattern to their sentences and word choices, it is easy to determine the accuracy of a text after having gone through many translations. For a book such as the Bible, this was of paramount importance. I believe the original purpose of the "Bible codes" was to ensure that the meaning of scripture was not lost as it was passed from one generation to the next.
Consider for example, the poem. If a poem is incorrectly copied, it no longer rhymes, or the meter is disrupted. This simple mechanism not only ensures easy memorization, but provides a security against unintended alteration. In much the same manner, the "Bible codes" have provided scholars a way of discerning the accuracy of a copy of scripture. In fact, some of scripture is indeed poetic, further reinforcing the confidence in the original scriptures.
I find it somewhat interesting that lossless copying was available long before digital electronics were invented.
Yeh huell? Methinkses int et so easy ferfun fule...
And then there are the folks who can wix up mords, mometimes in sid-sentence, on fle thy. (Yes, I'm just as fluent when speaking as well. With dome sifficulty, I man wix up three cords as well.)
I don't know if it was a side effect of all the programming I've done, or just some latent dyslexia, but I'm able to mix up words and invent new ones with relative ease. Perhaps the challenge of having to remember umpteen different passwords, and change them every month did it. Consider:
Transflagradation - being flamed by someone who's mistaken you for someone else; commonly caused by someone accidentally replying to the wrong thread...
Insidoctrinate - convincing someone else to believe something absurd based on logical arguments....
Well, you get the point. It's not very difficult.
Well, that's an even better idea - provided one has the time.
Even a small consulting business is much more than forty hours a week. For those who want to make money, though, it is very profitable. I could double my salary if I did consulting.
Which is why I apply for jobs I'm just barely qualified to do. But then I hear:
Frankly, it doesn't matter. An HR employee who doesn't like you, or even their job, for that matter, is going to make sure you don't get the job. They've got a list of excuses for every possible scenario:
There's no silver bullet to getting hired. Just put down what you're good at and submit your resume.
The CD-RW has not replaced the floppy. You cannot edit the files on a CD-RW the same way you would edit files on a floppy or zip disk. You either erase and reburn the entire disk, or you copy the files to a temp directory and reburn once you're finished. And since reburn takes about 5-10 minutes, I really doubt students will save and backup their work at regular intervals.
Yes, a CD-RW does hold more. But they don't solve the fundamental problem of being able to edit one's work from any computer.
Until something better comes along, I'm using Zip disks. The larger ones will hold 750MB, and they are almost as fast as a hard drive. Plus, I can edit and save files in place, without going through some special software.
Now you might say that zip drives are relatively rare, and you'd be right. But just try to read your CD-RW in a WindowsNT system, or try to edit it in an older machine without a burner.
It's the same compatibility problem: floppies worked because, despite their disadvantages, they were the one media that every PC could read and write. Now it looks as if it's going to be a while before there's a de facto standard for a read-write-update media.
And no, CD-R/RW aren't better than floppies for data storage. In fact, they're worse, because much more is lost when they fail. I've had CD-R's go bad after six months of storage in a closet. Contrast this with Zip disks that have lasted several years.
I used to think the same thing about getting rid of floppies, until I bought a machine without one.
Even though it's slow, and small, a floppy is the one common denominator among almost every PC in use today - except mine.
Floppies Just Work(tm).
I don't have to configure networking. I don't have to ask them to burn me a CD (some don't even have burners). I don't need ten different networking configurations for every possible OS version out there. I don't have to wait for a CD to finish burning(5 minutes...) when I want to send them a 10kB text document. I don't have to worry if they don't have UFS drivers for their OS *cough* NT *cough*. I don't need to worry about whether or not they've got USB drivers (or heck, even a USB port!).
Yeah, I don't like the floppy, but it's much more inconvenient living without it - especially if you've got to transfer files between work and home machines.
I'm pretty sure that a freeDOS boot floppy would work just as well as a Win95 boot disk.
.com or .exe files in real mode would suffice for your purposes. Since Win95/98/DOS doesn't have the direct ability to flash the BIOS, the only system services the flash utility might use are the file opening and reading services - which I believe freeDOS supports.
Most BIOS flashing utilities run in 16 bit real mode, and I believe the reason why Tyan specifies a Win95/98 boot disk is because it's the version of a DOS boot disk that most readily available. I'd bet that the utility would run just fine under DOS 6.0, or any other DOS.
And if you really must insist on using Linux, you might want to look up DOSemu, if it still exists. Last I heard, they're using the freeDOS kernel.
IIRC, the only system service which a Flash utility uses is the executable loader. I would think that any program capable of loading the
In the first place, the transmission is the least complicated component of an automobile; today's computer controlled engines make a manual transmission (and even an automatic, sans the valve body) simply by comparison.
Automakers found that a smaller engine (less weight) could run cleaner, more efficiently, and produce more power if it was tuned for a small rpm range. Witness Indy cars - 3 liter V12 engines producing ~750-850 horsepower - contrast with 180 hp for the average 3 liter sedan engine. The drawback was that the engine couldn't produce enough power at low rpm's to start the vehicle moving. Hence the necessity of the transmission.
Smaller engines meant smaller mass. Smaller mass meant better fuel economy, and greater agility. And then there's the torque issue.
By far, the gear train has the greatest impact on the off-the-line performance of a vehicle. With engines getting smaller to meet EPA guidelines, automakers found that by tuning an engine to produce horsepower in a narrow range, they could get more horsepower for a given engine size. Given the right transmission, a driver could keep the engine spinning in the peak-horsepower range, and thus achieve much greater acceleration than possible without a transmission.
There has been a lot of controversy surrounding Linux - first with DeCSS, and now with SCO.
I wonder if the entertainment cartel is aware that SCO has probably, at some point in the past, distributed the DeCSS code with the Linux kernel. I wonder how the RIAA would react to SCO claiming ownership of this "Linux". If indeed, they owned Linux as they claim, wouldn't it make them liable for distributing a "circumvention device" under the DMCA?
I'm wondering if the RIAA is going to sue SCO should SCO win "ownership" of Linux? After all, SCO won't reveal exactly which parts it "owns", so we have to assume they claim all of it - the good, the bad, and the DeCSS....
As for Linux proper, it's no big deal to remove DeCSS should it exist in the kernel. But for a company such as SCO to claim ownership of it implies that they created it - a fact which would make them guilty of willful infringement under the DMCA. So Linux could very easily survive the scourge by claiming ignorance, whereas SCO could go from predator to prey.
Smithers: Did you hear? "Loser Pays" has now become law; if we sue someone and lose, we'll have to pay their legal fees!
CEO: Perfect.
Smithers: WHAT?! Do you know what this means?
CEO: I know EXACTLY what it means. It means we'll hire the most expensive lawyers we can find. It means that no one will risk paying a million dollars in legal fees if they lose their ten grand lawsuit against us. It means when we sue people, they'll settle because the cost of losing just got higher. It means that we can rip off the customer even more! We'll have the best lawyers in the country - we're bound to win, and we'll make our victims pick up the tab! Yessss, this is EXACTLY what we wanted....
Well, that was a good troll. I think, however, that you inadvertently made a point that needs attention.
There are a lot of people prejudiced against those who know more than they do. Their inferiority complex causes them to believe that it's impossible for someone to be both humble and more knowledgeable than them.
I find that it's very difficult to convince stupid people that you know more than they do. You see, a stupid person actually believes that their self worth is a factor of how much they know. If I claim to know more, it must be because I think I'm a better person, right? To them, it's impossible to fathom that I might know more than they do in one particular area because I've spent time studying it. They can't understand that a person's worthiness is independent of their intellectual capacity.
I think you missed the point. It's not about judging another person's choice so much as explaining it. The failure of Linux to be widely adopted on the desktop is the result of the way it was designed.
A person can drive a car without an intimate knowledge of thermodynamics and combustion theory. A person can use a washing machine without knowing the chemistry involved. Yet Linux zealots often expect computer users to undertand some rather arcane computer science concepts. To those who want to use a computer as a means rather than an end, this is just an impediment to getting the real work done.
Windows fills one need, Linux another. It has nothing to do with who is better, but rather with which OS better suits the particular user.
I'd object to point number 2.
Back when I was a rabid Linux fan, I had a professor say to me, "We use operating systems for what they're good for, not what their bad at..."
Which kind of turned my head around and made me think of Linux and Windows differently. Linux fills a need that Microsoft can't - it's a secure, reliable operating system.
Windows, OTOH, is for people who _don't_ like computers - it makes an otherwise awkward experience at least a little tolerable. Given that the majority of America would rather get drunk and watch football, the popularity of Windows is easily explained. Because most normal people's lives _don't_ revolve around their computer, it's easy for them not to care about Windows reliability problems - they don't want to become a computer expert just so they can read their email.
Not likely. XML is designed to solve the data identification problem, not the data storage problem.
Due to the heirarchical nature of XML, a validating parser must read the entire document before returning any results. Given the way that most parsers are designed, the entire document will be read into memory and first parsed, then validated. Which, of course, limits the size of your database to the machine's memory.
The relational databases aren't going to go away. XML is more like a text-mode IMS for the PC. For those who have never heard of IMS, it was a heirarchical database built for IBM mainframes back in the 60's. When DB2 came out with it's relational model, IMS was largely abandoned. XML is no different, except it incurs a significant performance penalty - it isn't indexed, so binary searches are automatically precluded. Instead, searching a large XML "database" would require using a linear search after loading the document into memory.
But I think I've heard it best put by a manager, "XML forces your database to follow an arbitrary structure. It forces your database to be built around the presentation of the data, rather than the efficiency of retrieval." Until then, I hadn't thought about it in those terms, but I realized that he was exactly right. With a relational database, it's easy to represent many different views and relationships of the same data. But with XML, you're stuck with what the DTD designer believes necessary - the presentation in effect dictates the database structure.
I like XML as an exchange format. But it's the COBOL of the new millenium. The inherent inefficiencies involved (the entire document must be read to extract a single node?), and the inflexibility of relationships (it will always be heirarchical), make it a poor candidate for a database format.
Yes, I've used XML as a database format, with horrible results. A year or so ago, I used it for a financial application. I had written the frontend, and later decided to write an add-on piece which would compile statistics about the transaction data. Rather than being able to read a single record and do things like:
RunningTotal += CurrentRecord.AmountPayable;
I had to use syntax like:
RunningTotal = RunningTotal + Float.parseFloat(DocumentRoot().NextRecord().Item( "CurrentTransactions).Item("Transaction").Item("Am ountPayable"));
Now tell me that's an improvement!? And should I change my DTD, this code would useless. Yes, I could add fields, but I can't otherwise change the structure of the document without invalidating all of my code.
So XML isn't really as "universal" as the pundits would like to claim. In order to parse an XML document, you still need the DTD, and should the DTD change, your code will be broken. Here's a brief comparison of database formats:
Okay, flame away. Basically, XML doesn't offer any advantages to the old fixed-width mainframe formats, except possibly that it can be editted with a text editor. But it's not like any self-respecting DBA would let a programmer edit a production database with a text editor, so it's a moot point anyway.
Notes:
1. Since the record and field boundaries can be predicted in advance, a fixed width file doesn't need to pa
Encryption is now considered a weapon by the State Department.
I wonder how long it will be before the State Department and the content cartel go head to head over the issue: the content cartel arguing that they need unbreakable encryption to protect their content, and the State Department arguing that they need to limit encryption strength to catch "terrorists". The results will be interesting.
That the US will delete this data when the three years are over? More likely, it will be "removed" from one database only to go into another more classified database at the NSA or FBI.
<troll>
That Microsoft will someday be able to release a stable operating system?
Sorry, I just couldn't resist...
</troll>
But seriously, it looks as if the mere presence of Linux is having an effect on Redmond. Perhaps Microsoft will produce better systems than they have in the past if they consider Linux a threat to their business model. Nothing inspires excellence like a little competition...
Anything written by RMS has a certain stigma attached to it which tends to polarize the discussion. Rather than parrot the FSF party line, I'd rather expose readers to some new ideas.
Part of the problem with posting a link to Right to Read is that it implies content consumers have the right to enjoy the work of an author without compensating the author for their effort. That argument is better left avoided, as it adds nothing to the discussion.
Besides, Stallman didn't go so far as to suggest that publishing one's own content would be heavily restricted. But I can see the day coming when it will be illegal to even create works without approval from government authorities. In fact, it has already happened; Communist China comes to mind.
The real problem I see is that consumers are more concerned with the here and now than the gradual changes encroaching upon their freedoms. Most people expect to pay for books and movies and music - what they don't expect is that the technology which is first sold as a protection measure will be later used to destroy their freedom of expression. (First ammendment nullified by technical measures, anyone?)
The FBI stopped by to see me earlier this morning.
Apparently, they found an unlicensed compiler on one of my student's computers. Copyright central has visited the campus on more than one occasion, so I expected this to be fairly routine. Far from it - for the better part of the morning, they questioned me about this kid's activities. Being a college professor, I couldn't tell them much. This was probably the first time that a student was glad his professor didn't pay more attention to him.
I don't think he's been charged yet, but I was able to discover the nature of what he'll be charged with. The unlicensed compiler is problematic, though not technically illegal since it can't sign object code (illegally). Instead, he was found with a great deal of original material - some dating back 10 years or more - that was never registered with the copyright office. Some was on paper, but most of it was on disk. At a dollar per kB, he's looking at close to a million dollars in fines, not to mention a felony conviction.
But I think that's the least of his worries. About 15 years ago, unlicensed media formats became illegal. In order to record music or video today, you must use one of the state-approved formats which incorporate DRM, and you have to digitally sign the file. Given that the encoders are patented and held by private companies, it's not surprising to learn that leasing a music encoder (just the softare!) costs about $50,000 per year. And after you are finished recording, a general distribution license costs another $50,000 per year. Writing your own encoder would land you in jail for creating a "circumvention device". Which is why anyone who owns a compiler is viewed with suspicion, even though such ownership is not strictly illegal.
Apparently, this kid had a few mp3 files (illegal format), a few mp3 encoders (illegal tools - a felony), and a plethora of original content which hadn't been registered with Copyright Central. He's probably looking at about ten to fifteen years in jail, plus some pretty hefty fines.