This is a variant of the napsack problems. It's a little more complicated, but not much. You have a collection of objects (employee hours) and a collection of containers (hours of time that need to be filled by some employee). You also have various restrictions (certain employees can't work at certain times, or equivelently certain employees can only work at certain times). Just start grabbing employee-hours at random, and shoving them in. If you reach an impasse (no employee can work a given hour) you backtrack to an earlier decision and pick differently.
There are degenerate situations where, although a solution exists, this algorithm will take an excessive amount of time to find the solution. But I'd bet you find them in this situation.
I agree, but it's more than just requirements. It's unreasonable schedules, a lack- in many cases- of release management or even version control, and a consumer environment that allows, even encourages, software companies to focus on new features instead of getting the features they already have to work right.
Re:Signature Practice has Sucked Badly in the Past
on
Pardon, Is This Your File?
·
· Score: 3, Informative
CRC-16's are trivially easy to find matches. At somewhere around 256 files (I'm too lazy to do the math) you have a 50/50 shot of two having the same checksum. CRC-32's mildly harder, requiring ~64K images. One hopes that they are using a cryptographically secure hash, like MD-5 or SHA, where the chances of "accidental" collisions are astronomically remote.
This whole idea is trivially easy to defeat, however. Simply make minor modifications to the copyrighted work before reposting it. Take that picture of Natalie Portman, load it up into the GIMP, and change one pixel to a slightly different shade. Then post. One important feature of cryptographic hashs (like the aforementioned MD-5 and SHA) is that changing a single bit flips, on average, about half the bits. I.e. small changes in the picture make for large changes in the hash value.
Here's the problem with this theory: monopolies are in the best position to take advantage of new technologies and become monopolies in them as well.
Case in point: IBM. IBM was founded in the 1800's as a punch card monopoly. A variant of the Jacquard loom allowed you to sort, perform simple sums, etc., on stacks of punch cards, and every big buisness had built up a library of punched card stacks (literally a data warehouse). And IBM was the #1 supplier of punch cards and punch card equipment, holding a monopoly over the market as great as it ever held over the computer market. When computers were introduced in the late fourties/early fifties as buisness tool, IBM moved into computers to protect it's punch card monopoly.
IBM held onto it's monopoly position in computers using tactics as scummy and evil as any Microsoft has used (see Big Blue for details) for over 30 years. They only made one mistake: they made a computer where IBM did not make the CPU and write the Operating System, the original PC. Which lead to the fall of IBM and the rise of the Wintel duopoly. I make a very strong case that the IBM monopoly, started in the 1880's, is very much alive and well, just not IBM's anymore.
Every other monopoly I am aware of has fallen to goverment action. Every one. From United Shoe to Standard Oil to AT&T. Long before technological innovation could overthrow them (if, indeed, technological innovation *can* overthrow a monopoly- an unproved assumption).
Re:One thing I've NEVER seen here....
on
Fair IP Laws?
·
· Score: 2
I'm a software engineer. I make my living selling the fruits of my intellectual work. And I hate software patents.
Why? Let's put the shoe on the other foot for a moment. The only way you should be able to use a computer is if you pay for a professional to sit at your left elbow and tell you what you can and can't do, and how to do it. No WSIWYG, no GUIs, no documentation. Oh, and failure to have a computer professional on hand while using a computer could lead to a fine of a million or more US dollars.
Doesn't sit well, does it? Well, that's what is being asked of us programmers. We need an IP lawyer to sit at out left elbows to tell us what ideas we can use and what ideas we can't. Failure to do so can wind us up in court- and the average cost for an IP lawsuit is a million dollars. That's what a patent bust costs- which is why fixing bad patents in the courtroom doesn't work. I don't know about you, but I don't have a million dollars to defend myself.
The rampant incompetence in the USPTO just makes things worse. I don't just have to worry about the big ideas, *any* idea is in danger of violating a patent. We have a patent for swinging sideways, for Christ's sake. Using a bubble sort to sort an array of integers may be a blatantly obvious idea to me or anyone else who survived the first two semesters of a CS course. But if it hit the moron examiner who allowed the swinging sideways patent through, it could still be patented. And prior art is only relevent if you have the attorney fees to fight it in court, remember.
Software patents are rapidly making it impossible for a programmer to do his job without the protection of (and control by) a large corporation with lots of IP lawyers and lots of patents itself. Say good bye to the garage inventor/programmer- which means saying good bye to the future Hewlett Packards, the future Apples, and the future Microsofts, all whom started in garages or basements. (OK, maybe we can do without the future Microsofts. You get my drift.)
Sofware is also the only thing that can be copyrighted *and* patented. Which means you get situations where ownership is disputed. Person A owns the patent for a peice of code, and person B owns the copyright. Who controls the code? (Answer: the lawyers!)
I question the real value of the ideas, in the end. This may be because I have enough of them. Or rather ideas only have value once they're implemented- an unimplemented idea is of no use to anyone. Try the following exercise- find a published author. Slide up to them and say that you have a brilliant idea for a plot, which you'll give them for half the proceeds on the book. All they have to do is write your idea down. If you picked a nice author, they will kindly explain to you that ideas are a dime a dozen, turning the ideas into a saleable book is work. Pick a not so nice author and you're liable to learn some new words. Pick Harlan Ellison, and you're likely to get a chair thrown at you.
As plots are to books, so are algorithms to programs. But we don't buy plots, we buy books. And we don't buy algorithms, we buy working programs. Now, what would happen if I could patent plots?
If you allow me two fundamental freedoms: 1) The freedom to run any software on my PC that I want, and 2) The right to record my own content and distribute it how I like, including for free, then piracy is a fact of life. Deny me those rights, and you deny me freedom of speech.
Our congresspeople may be searching for a way to make Pi equal to 3, or repeal the law of gravity, but it's doomed to fail.
Re:Two transition periods?
on
If I Had a Hammer
·
· Score: 3, Interesting
Actually, assuming Moore's Law (in it's debased form) continues, we can calculate how long it will be before we need to go to 128 bits. The calculation is easy- 18 months of growth for every extra bit.
So to go from 8 bits to 16 bits took a mere 12 years. Say 1966 to 1978. Going from 16 to 32 took a little bit longer- 24 years (1978-2002). Going from 32 to 64 bits will take 48 years- it'll be 2050 before we outgrow 64 bits.
And it'll be 2242 before we outgrow 128 bits, 2626 before we outgrow 256 bits, 3394 before we outgrow 512 bits, etc.
Of course, there are slight physics problems with Moore's law continuing for the next 1,392 years. But that's for a different post...
Everyone remember the "Intel Inside" marketing campaign? Anyone remember "Authentic AMD"? The Intel Inside campaign was based mainly on FUD and Intel's control over the x86 processor. Since the x86 was a "defacto standard" defined by Intel, only Intel could gaurentee that it followed the standard. If you used other people's CPUs, they might work, but they might not. Better safe than sorry, right?
If Intel publically implements the x86-64 architecture, while more-or-less simultaneously dropping the IA64 architecture, it will be diaster. It would be publically admitting, in deed if not in word, that AMD controls the future evolution of the x86, not Intel. The best Intel could hope for would be for AMD to gain an incredible amount of credibility- which translates as sales in the lucrative but conservative buisness markets. Even worse, the current positions of AMD and Intel might even be reversed, with AMD being perceived as the flagship processor company and Intel the clone maker.
Going to 64-bit is rapidly becoming not an option. Many desktop systems are having a gigabyte of memory installed. Even x86 servers often have three gigabytes of ram installed. The server market is even worse off than the desktop market, as all the ram is generally given over to a single application (Exchange, or a database, for example)- and a 32-bit processor simply can not access more than about 2-3 gig of memory in a single application. The big-iron Unix cpus (Sun's SPARC, HP's PA-RISC, IBM's Power-4, etc) all went 64-bit years ago. It's not unusual to see even "moderate" servers of 4-, 8-, and 16- CPUs having tens of gigabytes of RAM already. The only market that still supports 32-bit CPUs is the embedded market- not a market Intel has ever displayed much interest in.
I figure that the x86 has maybe 3 years to go 64-bit across the board, or we'll be facing another 640K like situation. 3 years is two Moore's Law generations- meaning the people with 1G of memory today will be wanting 4G in 3 years, and the people only getting 256M today will be getting 1G. They'll continue to be hurt in the server market, but they won't lose much in the desktop. Unfortunately, to be 64-bit across the board means the high end needs to be 64-bit within about 18 months (allowing for a Moore's Law generation to push the 64-bit CPUs down the price scale).
Hammer is in a position to do that. McKinnley is the succeed or die point for the IA64. To use an analogy, Intel will have run out of runway- either it flies, or it'll hit the trees.
The successors don't matter- if McKinnley doesn't succeed, Hammer will be there to take the sales. If Intel stays in denial and doesn't offer a viable 64-bit path, they'll be in worse shape than simply admitting that they lost.
At that point, the best thing Intel could do is roll out a Hammer of their own, and plan on less than 50% market share.
Why spend the time, money, and effort to sneak someone into Microsoft to add a back door? Look at the damage done by Goner, Sircam, LoveBug, and all the rest using the front door! Anyone talented enough to a) get a job at Microsoft (even as an H1B temp), b) add a back door or timebomb to the XP code, and c) do it in such a way that it doesn't get noticed, has enough talent to stay at home and write lovebug knockoffs.
It would be perfectly legal for me to grab a copy of the Linux source code, rip out all the credits as to who did what work, and release my new OS "Brianux". This would be reprehensible (and for the record, I have no intention of actually doing this, so save your flames)- but perfectly legal so long as I released the source.
OK. Objective speed measurements. Find all files in the current directory or any directory under the current directory which contain the word "foo" (may be upper or lower case) and open an editor on them.
Oh, and you're in a directory of 10 subdirectories each with 100 files in them (a moderately sized software project).
On the command line:
vi `find . -type f | xargs grep -li foo`
Hmm. Took me a couple of seconds. Start clicking.
For simple tasks (like opening a file and scrolling to the bottom) the time saved one way or the other is trivial, especially compared to the time spent reading the file. It's *complex* tasks where the CLI rocks. Most of the UI studies I've seen studied only simple tasks. Open a small file. Make a few changes. Etc.
So the question becomes how often are you doing complex tasks? And before you ask: I do something similiar to the above multiple times a day. Which is why it rolled off my tounge (so to speak).
1) Last time I used Windows, support was seperate there to ($95 a call, as I recall). One advantage open source gives you is that you can shop around for support. Don't like Redhat? Dozens of company will happily give you support.
With Windows, if Microsoft doesn't give yousatisfication, you are SOL.
2) If it breaks, you can fix it, or pay someone else to fix it.
3) If the original developers decide to move on to bigger or better things, you (and everyone else depending upon the software) can pick up the development. I note you comment on Mozilla- this is the problem with *corporate* supported code. When the corporation decides to stop paying for it, development stops. With Mozilla, development can get picked up- this is how Apache started. NSCA had stopped funding development on their server, so the various webmins teamed together and picked up development. Mozilla may do this. Had the source been closed, there would have been no choice- development simply stops.
Open source doesn't mean you stop paying for software. Nor does free software- they mean free as in speech, not free as in beer. The difference is one of choice, and true free-market competition.
1) At work, it's OK to say "I don't know the answer to that question- try asking Bob, he may know."
2) Work is an open book test. Sitting at my desk now, I have four different books open, and dozens more closed and stacked close to hand.
3) If you find code lying around that someone you don't even know wrote ten years ago, polish it up a bit and use it, this is called code reuse and is strongly encouraged.
4) At work, code you wrote years ago comes back to haunt you. Programming is like sex- one mistake and you're supporting it forever.
5) At work, code other people wrote years ago comes back to haunt you. "Ted left the company six years ago, but some of his code has a bug. Go forth and fix it."
6) At work, information isn't fed to you in easily digestable chunks. If you're lucky, they drop a pile of books on your desk two feet high, and expect you to get what you need to know out of them (I've had this happen to me). If you're not lucky, you need to find the books yourself (I've had this happen to me too). If you're really not lucky, the books don't exist- have fun! (Yep, that too).
7) College students don't have to deal with tech support calls. On either end.
There are probably more, but I need to go accomplish something.
If both the private and public key are calculated from the same publically available peice of knowledge (the email address), how do you keep the private key *private*? I am as capable as anyone of feeding "rms@fsf.org", "hemos@slashdot.org", or "billg@microsoft.com" into the algorithm as Richard Stallman, Hemos, or Bill Gates are. This gives me the ability to impersonate any of those people.
The whole idea of a private key is that it's *private*, i.e. only I know it, and no one else can figure it out from the publically available information about me.
Baiscally, the method the crypto backdoors work is by putting a known, designed-in weakness into the algorithm. For example, it could leak key bits into the encrypted stream. The goverment could then pick the keybits back out of the stream and use them to either directly decrypt the data, or use it to simplify a brute forcing ("OK, we know what a 112 bits of the 128 bit key are- know all we need to do is brute force the last 16.")
There is an obvious problems with this from the cryptological angle- the encryption algorithm has to remain secret. Once you figure out the encryption scheme, and notice where the key information is being leaked, you too can take advantage of the back door. It's the classic problem with master keys- once they get out and get duplicated, it quickly becomes worthless to have the locks. So not only do you not dare publish the algorithm, you do not dare let anyone reverse engineer it.
I find it humorous that *any* concern to the people who would be harmed in a corporate death penalty, or in any corporate fine. No such considerations are ever given to *human* criminals who are punished. How often do you hear a judge say something like "I know you committed this crime, and you've admitted it, and normally I'd sentence you to life imprisonment for it, but since you have a wife and family who are depending upon you for financial support, and parents and siblings who would be emotionally harmed by your incareration, I'm going to commute you sentence to 60 days of probation"?
I'm a NAIC club member and stock investor. I'm also an employee. *Both* of these attributes have a certain amount of risk involved- the company I am working for may go out of buisness, or may simply downsize me, with little or no warning. The stocks I buy may declare bankruptcy, or plummet in price so far that the stocks may as well be worthless. You can't avoid risk, so you manage it. You don't put all your money into one stock, you diversify. That way if one company bombs, it doesn't take your entire portfolio with it. You keep you skills current, live in a city with many job opportunities, and keep technical contacts up, so when you loose your current job you can get another one. Risk is a fact of life.
This makes writting proprietary code for Linux *very* tricky. How do you know you're not including some file which includes some file from either the/usr/include/linux or/usr/include/asm directories?
For example, you include to handle POSIX errnos- a very common occurance./usr/include/errno.h includes/usr/include/bits/errno.h, which in turn includes/usr/include/linux/errno.h But/usr/include/linux is a symlink to/usr/src/linux/include/linux, and the file/usr/src/linux/include/linux/errno.h is part of the GPL'd, not LGPL'd, linux kernel! So every program which includes has to be GPL'd!
Can I draw you attention to Donald Knuth's "Art of Computer Programming"- the definitive work on computer algorithms, which was named by Scientific American as one of the seminal works of the 20th Century (see Knuth's Home Page) putting him in the company of Albert Einstein, Russell and Whitehead, von Neumann, and Dirac.
In it he passionate argues that not only do you need source code to intelligably discuss algorithms, but you need *assembly code* (one short step shy of object code). And all of the algorithms are presented in assembly language.
The fundamental problem is hardware. Task switchs, under *any* OS, take a long time.
At the time of the Tannenbaum/Torvalds debate, the primary CPU in use was still the 386- which took 300 to 500 clock cycles to task switch. No, that's not a typo- three to five *hundred*.
The situation has imporved enormously- Pentium class CPUs only take ~50 clock cycles to task switch. Of course, this is disregarding any TLB misses which are incurred.
The task switch overhead is what caused NT to move the graphics calls into kernel space in 4.0 (causing a large improvement in performance and a huge decrease in reliability). The hardware costs of task switching is what kills "true" microkernel OSs on performance. And don't bother to whine about "poor processor design"- people (including me) want an OS that runs well on the hardware they have.
The best operating systems are the "mutts"- not true microkernels nor true monolithic kernels. Which is how linux evolved- kernel modules for many if not most things, virtual file systems, etc.
Using Microsoft products doesn't protect you from this- quite the contrary. It places you on an ugrade treadmill *forever*.
Corporations were discouraged by Microsoft from upgrading from Windows 98 to Windows ME. But when Windows XP comes out RSN, Windows 98 will go on the dustbin of history and cease to be supported by Microsoft. Corporations will be forced to upgrade their entire networks immediately. I hope they're preparing.
Slashdot Mirror
... well, in algorithms, anyways.
This is a variant of the napsack problems. It's a little more complicated, but not much. You have a collection of objects (employee hours) and a collection of containers (hours of time that need to be filled by some employee). You also have various restrictions (certain employees can't work at certain times, or equivelently certain employees can only work at certain times). Just start grabbing employee-hours at random, and shoving them in. If you reach an impasse (no employee can work a given hour) you backtrack to an earlier decision and pick differently.
There are degenerate situations where, although a solution exists, this algorithm will take an excessive amount of time to find the solution. But I'd bet you find them in this situation.
Brian
I agree, but it's more than just requirements. It's unreasonable schedules, a lack- in many cases- of release management or even version control, and a consumer environment that allows, even encourages, software companies to focus on new features instead of getting the features they already have to work right.
CRC-16's are trivially easy to find matches. At somewhere around 256 files (I'm too lazy to do the math) you have a 50/50 shot of two having the same checksum. CRC-32's mildly harder, requiring ~64K images. One hopes that they are using a cryptographically secure hash, like MD-5 or SHA, where the chances of "accidental" collisions are astronomically remote.
This whole idea is trivially easy to defeat, however. Simply make minor modifications to the copyrighted work before reposting it. Take that picture of Natalie Portman, load it up into the GIMP, and change one pixel to a slightly different shade. Then post. One important feature of cryptographic hashs (like the aforementioned MD-5 and SHA) is that changing a single bit flips, on average, about half the bits. I.e. small changes in the picture make for large changes in the hash value.
Opps. Did I just fall afoul of the DMCA?
Here's the problem with this theory: monopolies are in the best position to take advantage of new technologies and become monopolies in them as well.
Case in point: IBM. IBM was founded in the 1800's as a punch card monopoly. A variant of the Jacquard loom allowed you to sort, perform simple sums, etc., on stacks of punch cards, and every big buisness had built up a library of punched card stacks (literally a data warehouse). And IBM was the #1 supplier of punch cards and punch card equipment, holding a monopoly over the market as great as it ever held over the computer market. When computers were introduced in the late fourties/early fifties as buisness tool, IBM moved into computers to protect it's punch card monopoly.
IBM held onto it's monopoly position in computers using tactics as scummy and evil as any Microsoft has used (see Big Blue for details) for over 30 years. They only made one mistake: they made a computer where IBM did not make the CPU and write the Operating System, the original PC. Which lead to the fall of IBM and the rise of the Wintel duopoly. I make a very strong case that the IBM monopoly, started in the 1880's, is very much alive and well, just not IBM's anymore.
Every other monopoly I am aware of has fallen to goverment action. Every one. From United Shoe to Standard Oil to AT&T. Long before technological innovation could overthrow them (if, indeed, technological innovation *can* overthrow a monopoly- an unproved assumption).
I'm a software engineer. I make my living selling the fruits of my intellectual work. And I hate software patents.
Why? Let's put the shoe on the other foot for a moment. The only way you should be able to use a computer is if you pay for a professional to sit at your left elbow and tell you what you can and can't do, and how to do it. No WSIWYG, no GUIs, no documentation. Oh, and failure to have a computer professional on hand while using a computer could lead to a fine of a million or more US dollars.
Doesn't sit well, does it? Well, that's what is being asked of us programmers. We need an IP lawyer to sit at out left elbows to tell us what ideas we can use and what ideas we can't. Failure to do so can wind us up in court- and the average cost for an IP lawsuit is a million dollars. That's what a patent bust costs- which is why fixing bad patents in the courtroom doesn't work. I don't know about you, but I don't have a million dollars to defend myself.
The rampant incompetence in the USPTO just makes things worse. I don't just have to worry about the big ideas, *any* idea is in danger of violating a patent. We have a patent for swinging sideways, for Christ's sake. Using a bubble sort to sort an array of integers may be a blatantly obvious idea to me or anyone else who survived the first two semesters of a CS course. But if it hit the moron examiner who allowed the swinging sideways patent through, it could still be patented. And prior art is only relevent if you have the attorney fees to fight it in court, remember.
Software patents are rapidly making it impossible for a programmer to do his job without the protection of (and control by) a large corporation with lots of IP lawyers and lots of patents itself. Say good bye to the garage inventor/programmer- which means saying good bye to the future Hewlett Packards, the future Apples, and the future Microsofts, all whom started in garages or basements. (OK, maybe we can do without the future Microsofts. You get my drift.)
Sofware is also the only thing that can be copyrighted *and* patented. Which means you get situations where ownership is disputed. Person A owns the patent for a peice of code, and person B owns the copyright. Who controls the code? (Answer: the lawyers!)
I question the real value of the ideas, in the end. This may be because I have enough of them. Or rather ideas only have value once they're implemented- an unimplemented idea is of no use to anyone. Try the following exercise- find a published author. Slide up to them and say that you have a brilliant idea for a plot, which you'll give them for half the proceeds on the book. All they have to do is write your idea down. If you picked a nice author, they will kindly explain to you that ideas are a dime a dozen, turning the ideas into a saleable book is work. Pick a not so nice author and you're liable to learn some new words. Pick Harlan Ellison, and you're likely to get a chair thrown at you.
As plots are to books, so are algorithms to programs. But we don't buy plots, we buy books. And we don't buy algorithms, we buy working programs. Now, what would happen if I could patent plots?
Hope this helps.
Brian
If you allow me two fundamental freedoms:
1) The freedom to run any software on my PC that I want, and
2) The right to record my own content and distribute it how I like, including for free,
then piracy is a fact of life. Deny me those rights, and you deny me freedom of speech.
Our congresspeople may be searching for a way to make Pi equal to 3, or repeal the law of gravity, but it's doomed to fail.
Actually, assuming Moore's Law (in it's debased form) continues, we can calculate how long it will be before we need to go to 128 bits. The calculation is easy- 18 months of growth for every extra bit.
So to go from 8 bits to 16 bits took a mere 12 years. Say 1966 to 1978. Going from 16 to 32 took a little bit longer- 24 years (1978-2002). Going from 32 to 64 bits will take 48 years- it'll be 2050 before we outgrow 64 bits.
And it'll be 2242 before we outgrow 128 bits, 2626 before we outgrow 256 bits, 3394 before we outgrow 512 bits, etc.
Of course, there are slight physics problems with Moore's law continuing for the next 1,392 years. But that's for a different post...
Everyone remember the "Intel Inside" marketing campaign? Anyone remember "Authentic AMD"? The Intel Inside campaign was based mainly on FUD and Intel's control over the x86 processor. Since the x86 was a "defacto standard" defined by Intel, only Intel could gaurentee that it followed the standard. If you used other people's CPUs, they might work, but they might not. Better safe than sorry, right?
If Intel publically implements the x86-64 architecture, while more-or-less simultaneously dropping the IA64 architecture, it will be diaster. It would be publically admitting, in deed if not in word, that AMD controls the future evolution of the x86, not Intel. The best Intel could hope for would be for AMD to gain an incredible amount of credibility- which translates as sales in the lucrative but conservative buisness markets. Even worse, the current positions of AMD and Intel might even be reversed, with AMD being perceived as the flagship processor company and Intel the clone maker.
Going to 64-bit is rapidly becoming not an option. Many desktop systems are having a gigabyte of memory installed. Even x86 servers often have three gigabytes of ram installed. The server market is even worse off than the desktop market, as all the ram is generally given over to a single application (Exchange, or a database, for example)- and a 32-bit processor simply can not access more than about 2-3 gig of memory in a single application. The big-iron Unix cpus (Sun's SPARC, HP's PA-RISC, IBM's Power-4, etc) all went 64-bit years ago. It's not unusual to see even "moderate" servers of 4-, 8-, and 16- CPUs having tens of gigabytes of RAM already. The only market that still supports 32-bit CPUs is the embedded market- not a market Intel has ever displayed much interest in.
I figure that the x86 has maybe 3 years to go 64-bit across the board, or we'll be facing another 640K like situation. 3 years is two Moore's Law generations- meaning the people with 1G of memory today will be wanting 4G in 3 years, and the people only getting 256M today will be getting 1G. They'll continue to be hurt in the server market, but they won't lose much in the desktop. Unfortunately, to be 64-bit across the board means the high end needs to be 64-bit within about 18 months (allowing for a Moore's Law generation to push the 64-bit CPUs down the price scale).
Hammer is in a position to do that. McKinnley is the succeed or die point for the IA64. To use an analogy, Intel will have run out of runway- either it flies, or it'll hit the trees.
The successors don't matter- if McKinnley doesn't succeed, Hammer will be there to take the sales. If Intel stays in denial and doesn't offer a viable 64-bit path, they'll be in worse shape than simply admitting that they lost.
At that point, the best thing Intel could do is roll out a Hammer of their own, and plan on less than 50% market share.
Brian
Why spend the time, money, and effort to sneak someone into Microsoft to add a back door? Look at the damage done by Goner, Sircam, LoveBug, and all the rest using the front door! Anyone talented enough to a) get a job at Microsoft (even as an H1B temp), b) add a back door or timebomb to the XP code, and c) do it in such a way that it doesn't get noticed, has enough talent to stay at home and write lovebug knockoffs.
Brian
It would be perfectly legal for me to grab a copy of the Linux source code, rip out all the credits as to who did what work, and release my new OS "Brianux". This would be reprehensible (and for the record, I have no intention of actually doing this, so save your flames)- but perfectly legal so long as I released the source.
That means that DVD players are encryption technology, and you need a munitions license to export them!
"Here, you two morons fight it out. Let us know if you need more ammo."
Brian
It's not just Windows. I'm using Konquerer on Linux, and I can't see MSN either.
No big loss, though. If they don't want me to view their web page, that's their problem, not mine.
OK. Objective speed measurements. Find all files in the current directory or any directory under the current directory which contain the word "foo" (may be upper or lower case) and open an editor on them.
Oh, and you're in a directory of 10 subdirectories each with 100 files in them (a moderately sized software project).
On the command line:
vi `find . -type f | xargs grep -li foo`
Hmm. Took me a couple of seconds. Start clicking.
For simple tasks (like opening a file and scrolling to the bottom) the time saved one way or the other is trivial, especially compared to the time spent reading the file. It's *complex* tasks where the CLI rocks. Most of the UI studies I've seen studied only simple tasks. Open a small file. Make a few changes. Etc.
So the question becomes how often are you doing complex tasks? And before you ask: I do something similiar to the above multiple times a day. Which is why it rolled off my tounge (so to speak).
Actually, Ford is mostly Sun IIRC.
Prohibition == War on Drugs
Why is left as an exercise to the reader.
You get what you pay for, and maybe some more.
1) Last time I used Windows, support was seperate there to ($95 a call, as I recall). One advantage open source gives you is that you can shop around for support. Don't like Redhat? Dozens of company will happily give you support.
With Windows, if Microsoft doesn't give yousatisfication, you are SOL.
2) If it breaks, you can fix it, or pay someone else to fix it.
3) If the original developers decide to move on to bigger or better things, you (and everyone else depending upon the software) can pick up the development. I note you comment on Mozilla- this is the problem with *corporate* supported code. When the corporation decides to stop paying for it, development stops. With Mozilla, development can get picked up- this is how Apache started. NSCA had stopped funding development on their server, so the various webmins teamed together and picked up development. Mozilla may do this. Had the source been closed, there would have been no choice- development simply stops.
Open source doesn't mean you stop paying for software. Nor does free software- they mean free as in speech, not free as in beer. The difference is one of choice, and true free-market competition.
By someone who has been in both:
1) At work, it's OK to say "I don't know the answer to that question- try asking Bob, he may know."
2) Work is an open book test. Sitting at my desk now, I have four different books open, and dozens more closed and stacked close to hand.
3) If you find code lying around that someone you don't even know wrote ten years ago, polish it up a bit and use it, this is called code reuse and is strongly encouraged.
4) At work, code you wrote years ago comes back to haunt you. Programming is like sex- one mistake and you're supporting it forever.
5) At work, code other people wrote years ago comes back to haunt you. "Ted left the company six years ago, but some of his code has a bug. Go forth and fix it."
6) At work, information isn't fed to you in easily digestable chunks. If you're lucky, they drop a pile of books on your desk two feet high, and expect you to get what you need to know out of them (I've had this happen to me). If you're not lucky, you need to find the books yourself (I've had this happen to me too). If you're really not lucky, the books don't exist- have fun! (Yep, that too).
7) College students don't have to deal with tech support calls. On either end.
There are probably more, but I need to go accomplish something.
Brian
If both the private and public key are calculated from the same publically available peice of knowledge (the email address), how do you keep the private key *private*? I am as capable as anyone of feeding "rms@fsf.org", "hemos@slashdot.org", or "billg@microsoft.com" into the algorithm as Richard Stallman, Hemos, or Bill Gates are. This gives me the ability to impersonate any of those people.
The whole idea of a private key is that it's *private*, i.e. only I know it, and no one else can figure it out from the publically available information about me.
Baiscally, the method the crypto backdoors work is by putting a known, designed-in weakness into the algorithm. For example, it could leak key bits into the encrypted stream. The goverment could then pick the keybits back out of the stream and use them to either directly decrypt the data, or use it to simplify a brute forcing ("OK, we know what a 112 bits of the 128 bit key are- know all we need to do is brute force the last 16.")
There is an obvious problems with this from the cryptological angle- the encryption algorithm has to remain secret. Once you figure out the encryption scheme, and notice where the key information is being leaked, you too can take advantage of the back door. It's the classic problem with master keys- once they get out and get duplicated, it quickly becomes worthless to have the locks. So not only do you not dare publish the algorithm, you do not dare let anyone reverse engineer it.
I find it humorous that *any* concern to the people who would be harmed in a corporate death penalty, or in any corporate fine. No such considerations are ever given to *human* criminals who are punished. How often do you hear a judge say something like "I know you committed this crime, and you've admitted it, and normally I'd sentence you to life imprisonment for it, but since you have a wife and family who are depending upon you for financial support, and parents and siblings who would be emotionally harmed by your incareration, I'm going to commute you sentence to 60 days of probation"?
I'm a NAIC club member and stock investor. I'm also an employee. *Both* of these attributes have a certain amount of risk involved- the company I am working for may go out of buisness, or may simply downsize me, with little or no warning. The stocks I buy may declare bankruptcy, or plummet in price so far that the stocks may as well be worthless. You can't avoid risk, so you manage it. You don't put all your money into one stock, you diversify. That way if one company bombs, it doesn't take your entire portfolio with it. You keep you skills current, live in a city with many job opportunities, and keep technical contacts up, so when you loose your current job you can get another one. Risk is a fact of life.
This makes writting proprietary code for Linux *very* tricky. How do you know you're not including some file which includes some file from either the /usr/include/linux or /usr/include/asm directories?
/usr/include/errno.h includes /usr/include/bits/errno.h, which in turn includes /usr/include/linux/errno.h But /usr/include/linux is a symlink to /usr/src/linux/include/linux, and the file /usr/src/linux/include/linux/errno.h is part of the GPL'd, not LGPL'd, linux kernel! So every program which includes has to be GPL'd!
For example, you include to handle POSIX errnos- a very common occurance.
Can I draw you attention to Donald Knuth's "Art of Computer Programming"- the definitive work on computer algorithms, which was named by Scientific American as one of the seminal works of the 20th Century (see Knuth's Home Page) putting him in the company of Albert Einstein, Russell and Whitehead, von Neumann, and Dirac.
In it he passionate argues that not only do you need source code to intelligably discuss algorithms, but you need *assembly code* (one short step shy of object code). And all of the algorithms are presented in assembly language.
The fundamental problem is hardware. Task switchs, under *any* OS, take a long time.
At the time of the Tannenbaum/Torvalds debate, the primary CPU in use was still the 386- which took 300 to 500 clock cycles to task switch. No, that's not a typo- three to five *hundred*.
The situation has imporved enormously- Pentium class CPUs only take ~50 clock cycles to task switch. Of course, this is disregarding any TLB misses which are incurred.
The task switch overhead is what caused NT to move the graphics calls into kernel space in 4.0 (causing a large improvement in performance and a huge decrease in reliability). The hardware costs of task switching is what kills "true" microkernel OSs on performance. And don't bother to whine about "poor processor design"- people (including me) want an OS that runs well on the hardware they have.
The best operating systems are the "mutts"- not true microkernels nor true monolithic kernels. Which is how linux evolved- kernel modules for many if not most things, virtual file systems, etc.
Using Microsoft products doesn't protect you from this- quite the contrary. It places you on an ugrade treadmill *forever*.
Corporations were discouraged by Microsoft from upgrading from Windows 98 to Windows ME. But when Windows XP comes out RSN, Windows 98 will go on the dustbin of history and cease to be supported by Microsoft. Corporations will be forced to upgrade their entire networks immediately. I hope they're preparing.
Brian
Are they paying anything to the thousands of developers who contributed code *FOR FREE* to their distribution? Why should they earn all the money?
If they don't like the racket, they should get out of the buisness of selling other people's code.