Thinking about it - hashes, by their every nature will always have collisions. The only safe way is to use encryption instead, but that kind of defeats the purpose.
There are two distinct uses for hashing functions:
Proving that the file hasn't been maliciously tampered with.
Proving that the file hasn't been damaged by a dirty network or cosmic rays impacting a disk drive/RAM module/flash drive/etc.
Only the first is significantly impacted by collisions. If you are betting the company (or country) on the unforgability of your computer files, you better have a more secure system than any hash algorithm. A good hash algorithm is a good tool, but it isn't a complete protocol. And don't let anyone fool you: Designing a good security protocol is hard. Very few companies really want the hassle. That is why the kids from Finland usually have it so easy when they take the time to crack things like CSS.
If you're simply defending against shoddy networks, SHA-1 might even be overkill: Statistically, the odds are heavily in your favor even with something as 'insecure' as MD5. These news reports won't really impact people who simply have to maintain file integrity against random lossage.
The one thing that can't be cracked is an educated, skeptical mind. Use yours and if you don't have one, stay the hell away from my computers.
Okay, there were aspects I didn't know or didn't consider. I was, most likely, absolutely wrong. But I do have one parting shot:
But people can't legally build Mac clones.
People couldn't legally build IBM PC clones, either. People (Compaq!) especially couldn't clone the IBM BIOS to put into their IBM PC clones. That obviously stopped nobody.
Now that it's been verified (apparently), I guess it's even more certain that I was wrong. Jobs isn't (that) stupid (anymore).
I guess I'm not explaining myself well enough or you aren't reading well enough. Apple won't be able to maintain their margins if Taiwanese are cloning their boxes right and left because MS wants OEMs to build clones. MS wants people to build clones because Apple lives and dies on hardware margins, and if Apple moves to x86 chips MS-friendly OEMs will be willing to play along. Finally, putting a MacOS API into the Windows released for those clones would put the final nail in Apple's coffin by rendering MacOS redundant in the eyes of many people.
There isn't anything hard in my posts. Apple can only maintain margins if it has a monopoly on its hardware. Since x86 machines are cheaper for the foreign OEMs to build than PPC machines, it will not maintain that monopoly if it ever builds an x86 Macintosh machine. No monopoly, no margins, and MS moves in with a special Windows version to clean up the remains of Apple's customer base.
The x86 Mac will cost more than a comparable Wintel machine, even if the Wintel machine is as well made, because Apple's got higher margins.
Not for long. Apple has no divine right to margins if it is no longer the single source of that hardware.
They could do that now. You used to be able to buy Openstep for Windows, and the Openstep/Cocoa API is well documented. They don't because Microsoft's whole being is based around Win32. They only reluctantly produced a complete POSIX subsystem, even.
Plus the small matter of all MacOS software running on PPC instead of x86. If MacOS ran on x86, that huge barrier would disappear.
I'm not talking about developers. I'm talking about MacOS users who would love a cheap source for Macintosh hardware. The market exists to fill needs, even if Apple does not. Especially if Apple does not.
Why on earth would Microsoft doing anything at all on it make it cheap?
Because MS doesn't sell hardware. It sells software. People buy more software if hardware is cheap. MS would love it if hardware were somehow absolutely free, but the best it can do is get the OEMs to pump out gajillions of Dells and Compaqs with Windows pre-installed. Those OEMs can't get PPC chips cheap enough to clone current Macs, but if Macs were x86-based it would become feasible for the OEMs to clone them.
So far, the biggest distinction Apple has over MS is Mac OS X. Everything else is secondary.
No, the biggest distinction is the software. Most people don't know or care what OS they're running. They would just as soon run Windows if it ran the programs they liked. And if Apple goes through with the x86 deal, it will.
Maybe I am out in left field somewhere. My line of reasoning goes like this:
Apple may or may not be able to make laptops that really compete with Pentium M machines and their inevitable x86 follow-ons. The Pentium M is surprisingly good at giving acceptable muscle in a cool-running package.
If it can't beat the x86 crowd, it's liable to join them. That's assuming nobody will give them a better deal, but nobody seems willing to.
Micosoft wants to crush Apple. That much is a given. So far, the biggest distinction Apple has over MS is that Apple sells its own hardware and MacOS will not run on any other platform.
If MacOS suddenly runs on x86 chips, a certain number of people will switch from MacOS to the sure-to-be-released Windows version tailored for that new x86 Macintosh. This is perhaps my biggest heresy. I think MS would jump at the idea of releasing Windows for a PC that was well-designed, as opposed to tossed together by an OEM working under the Dell or Compaq label. Good hardware could make their OS seem more stable, at least to the extent Windows' problems are caused by bad hardware and not bad code. Further, I think the Mac people who don't care about MacOS per se will switch to Windows if their box supports it, because then they will get games and a whole lot more other applications.
Especially if Microsoft builds a MacOS API into that version of Windows. (Like WINE, but for MacOS. MINE?) This will allow all Mac programs to run on that Windows machine, because there wouldn't be any hardware problems.
And that machine would get cheap. This would get Apple more than the dirty software tricks, because MS would ensure Apple could never make a profit on that box. It would become the cheapest Windows machine ever made.
And then not even MacOS users would buy their hardware from Apple anymore. Apple would be finished as a computer hardware company, and can it really survive as a software company in direct competition with MS? Be, Inc. couldn't.* Perhaps this is why Jobs hypes the iPod so much: It's a piece of hardware MS's armies can't clone more cheaply. Yet.
*(And why has nobody compared Apple to Be yet? This is exactly what Be did right before it sank beneath the waves: The last versions of BeOS ran on whitebox x86 machines)
For one thing, it's difficult to design a program that does everything. This is because the complexity in software mainly comes from the interfaces between components, and the more your program does the more interfaces it has to have.
(Interfaces aren't always explicit, but the best ones are. Bad software is mainly characterized by fuzzy boundaries between functional units and promiscuous sharing of data between blocks of code that don't need to know it.)
The easiest program to design does one thing and hooks up to a simple API for its communication with the outside world. Unix command-line programs are built this way, and it has resulted in a lot of stable programs. Trying to expand a program is usually best done by splitting it and giving each part an easy way to talk with the other parts. This can be as easy as a bunch of subroutines that call each other or as complex as a client/server pair that send data to each other over the Internet. That way, each part can be reasoned about in isolation and ignored when you need to think about other parts, or the connections between all of the parts.
For another thing, it's difficult to change one part of a program. Making the boundaries between parts clear and strong helps, but it's never quite as easy as you first imagine. If you want to change the web browser component, do you really want to rebuild the entire project and try to integrate another browser into your framework? (If you don't have a framework of some kind, it would be easier to scrap the project and start again. An ad hoc communication system between components is usually impossible to change cleanly.)
It could be done. But I don't think it could be done well.
It's entirely possible that the x86 ISA is utterly unsuited to emulate any real chip that isn't many hundreds of times slower than the physical processor. Hell, I have a (somewhat) slow time of emulating a VAX (simh) on my 800MHz Duron, and I have plenty of RAM. Register spill is too expensive and the cache simply can't keep up, apparently.
It would probably be too expensive to design a multi-CPU computer, but if the G4 and G5 can't hold up against the Pentium M and sequelae in the laptop game Apple will have to do something. (As a point of reference, my Pentium M laptop is quiet and cool-running. I frequently don't know it's on when I'm across the room unless the screen is up and lit, and I can comfortably hold it in my lap.) Computers are only going to get smaller, and therefore noise and heat are only going to be bigger marks against any machine. I think fans will be effectively phased out sooner than most of us think.
I don't think Apple is going anywhere. I also agree with you that the x86 isn't an ideal PPC emulation platform, but where else will Apple turn? They couldn't convince Motorola to make a better 68k, so they were forced to move to PPC. Can they convince IBM to make a better PPC chipset, now that IBM is so aligned with Linux and its own service business? Will Intel risk Microsoft's wrath by luring Apple with a well-designed ISA? If Apple actually ports MacOS to x86 chips, what's to stop Microsoft from porting Windows to that generation of Mac hardware? Driver here, tweak there, and Apple is looking at serious OS competition in its own ballfield.* Not to mention the inevitable Linux ports.
*Microsoft could even entice a few Taiwanese whitebox makers to churn out Mac clones at a much smaller fraction of the cost Apple would want to sell them for. Remember that while Apple makes money from hardware sales, Microsoft benefits from hardware being as cheap as possible.
How does that in any way negate my position? Where does it say that thimerosal has anything to do with autism? I'll repost the relevant material, even though you're apparently so far in denial you can no longer read for comprehension:
No harmful effects have been reported from thimerosal at doses used in vaccines, except for minor reactions like redness and swelling at the injection site.
Apparently, the worst it ever did was cause mild redness and swelling. Redness and swelling is a common immune reaction to anything that penetrates the skin. Autism is in a completely different ballpark... hell, it's a different game from a mild immune reaction.
I don't know why you are in denial over this. Is your conspiracy theory so precious that you won't allow actual evidence to damage it? Is it so wonderful to be able to hate that you would try to hurt children in order to keep your hatred fresh in your mind?
I don't expect you to respond, because I don't expect you to have anything to respond with. Your mind is so poisoned by hate and suspicion you can't even read the plain meaning of a text. I can only hope that you aren't actually hurting any children with your lunacy.
And this precludes them from going x86 how? Surely you can run Apple ][ software at many times native speed under emulation if your real chip is a Pentium M or Pentium D. And since these aren't games, the speed boost is an unmixed blessing. It becomes more difficult to beat hardware as you go from Apple ][ to m68k to PPC, but correctness is maintained and that's what really counts.
In other words, emulation is the key here. Emulation allowed Apple to dump the aging m68k and move to PPC and it at least could allow them to dump PPC for next-generation Intel chips.
Neither of which would have been terribly impressive, since they would be ground-bursts and not much different from a few tons of dynamite.
If dynamite caused radiation sickness and cancer, this would be exactly right. As it stands, however, even a Nazi dirty bomb would have had at least a huge psychological effect, if not a very large military one.
It might have opened our eyes to the true dangers of radiation sooner, but I don't think so. It could be an interesting jumping-off point for an alternative history story: What if it gave other groups the idea to make their own dirty bombs in the unsettled postwar years?
And if I CAPITALIZE most WORDS I will become MICROSOFT'S worst nightmare and break the WINTEL monopoly even SOONER. Then APPLE and IBM will pay me MONEY for my CAPS-LOCK of DOOM.
The story of SPAM® luncheon meat began in 1936. Hormel Foods devised a recipe for a 12-ounce can of spiced ham. Jay C. Hormel was determined to find a brand name with a distinct identity that would set it apart from the competition. The company offered a $100 prize for the best name for the spiced ham product. The winner was Kenneth Daigneau, the actor brother of Hormel Vice President Ralph Daigneau. He created the new word by combining the "sp" from spiced ham with the "am" from ham.
It's almost an initialism, but not quite, and it predates the military's association with the product.
The only drawback is that there's nothing to preventing the new kernal from segfaulting when it see all the legacy Windows code it has to run. There's only so much you can do with OSS.
WINE seems to do okay with the code in and of itself. It doesn't emulate all of the APIs it needs to, but that wouldn't be a problem if MS itself was designing the system.
MS needs something like WINE or even Bochs if it wants Longhorn to be anything more than XP with a few new features and subtly different theme. Windows 95-era code cannot be trusted to run on the bare OS: It needs to be fooled completely and kept inside a small sandbox. Mutilating Longhorn's security model to keep SimCity and MSIE 3.0 happy will just ensure future security nightmares.
It might be better if MS does like Apple did when it moved from 68000-model CPUs to the PPC chips: Treat the old machine code as bytecode and run it inside a VM that hosts its own OS.
MOD PARENT UP Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 1
The design of X and Linux might not be the best of all possible designs, but we use them because they work, and nothing else does. For all the bitching about X's network overhead, I, for one, could not live without it.
This should probably be posted in large, red text right at the top of this discussion. If I had mod points, I would be modding this up right now.
The people who think X's networking is slow and inefficient need to realize that, first, on most machines it isn't noticeable, and, second, it's vital to making X usable in a lot of cases. X's networking is the difference between being able to run a graphical program on a remote machine and being limited to running text programs.
Frankly, if X wasn't built around the networking model it would be necessary to reinvent it at a higher level, thus making it orders of magnitude less flexible and, ultimately, less usable. That ignores the inevitable standards wars that would surround any such reinvention process, probably leading to dozens of subtly and individually broken ways of putting a window on a remote machine.
The people who focus on creating a GUI for a desktop machine that only ever runs local programs aren't creating a credible replacement for X. They're trying to reinvent the 'graphical shells' of the 1980s, back when DOS and the original Macintosh ruled the microcomputer world.
You know, I have a feeling X might even run on some other OS than linux.
In fact, now I think about it, isn't X11 actually/older/ than linux?
Right on both counts, but so what? Nobody in the summary mentioned Linux, and the article isn't about how this will impact Linux. It happens to be in the Linux section, but I don't think Slashdot has a specific X section.
And realistically speaking, most people will be using this on a Linux machine of one form or another.
I'm a UNIX guy and I agree with you, actually. If the VMS security model is implemented properly on Longhorn (or if it was implemented on WNT), MS would have something legitimate to gloat over when talking about how 'archaic' UNIX systems are. But MS couldn't do that with WNT or Windows XP and it won't be able to do that with Longhorn.
Backwards compatibility for applications is one piece of the puzzle, but not the most interesting one. You can run applications in a virtual machine or a sandbox and solve most of the problems. Think of something between chroot and WINE as the new 'Operating Environment' for pre-Longhorn applications that need to think they're running as Admin when they really can't be trusted with Admin-level access. This is nothing new, and MS could have done it in the original WNT.
The main problem for MS is that they feel the need to talk down to their users. The command line is too complex for their intended audience, so they have deprecated it and made it less powerful in favor of endless graphical wizards that walk you through everything. VMS style privileges are too complex, so they completely ignore the issue until their users are screaming at them, then they cruft on UNIX-style privileges and ignore the better but more complex VMS model originally part of their design.
MS thinks everyone who uses their OSes, even sysadmins, is unskilled labor. That is why they don't give people powerful tools: Powerful tools are complex, and liable to turn in your hand if you don't understand them.
(The unansked question is why Linux or the BSDs haven't adopted the VMS privilege model yet. I hope that becomes an option someday.)
Well, they also aren't selling the software they make, or building businesses around the fundamental research they do. All their money comes from tuitions and philanthropic groups and (at least for some) taxes. If a university professor or student invented a million-dollar idea, I don't know if the university itself could hope to reap the profits directly.
The example I think most people here will be familiar with is BSD Unix, originally developed at the University of California at Berkeley. A lot of people got a lot of use out of that code, but I don't think UC-Berkeley ever saw a dime of direct profit.
Lets say a CPU runs great, but fails on a coupla instructions. Why not just compile for it sans those instructions? For this to make any sense, there would have to be plenty of similarly flawed chips to work with though.
The current practice is if the chipmaker knows that some opcodes aren't going to work on all chips, it doesn't document those opcodes and the people who search for them know that they can't build reliable programs that use them. This is similar to what you're suggesting, but it isn't quite the same.
(Emulators of popular 8-bit chips like the 6510 (for the Commodore-64 and variants) and the Z80 (for the ZX-Spectrum and others) will almost always support the undocumented opcodes in ways faithful to at least some of the real chips. This is mainly because 8-bit chips didn't have that many opcodes to begin with.)
Another possibility, used on some assemblers for RISC CPUs like the MIPS, is for the assembler to translate a single unsupported opcode into a string of opcodes the chip does support. (That is, some 'opcodes' are really macros.) This might be useful to work around chip flaws, but it makes stepping through the machine code that much less intuitive. All the Real OSes these days have source-level debuggers, I suppose.
The FSF certainly couldn't take, say, FreeBSD and decide that they wanted to make it GPL. They could of course create GPLed derivative works of it, but the original code would remain under its orginal licence.
I think we all understand this, but as I understand the BSD license you could change one line of code and relicense the result under terms far more restrictive than the GPL. The original project wouldn't be hit, but it has happened that the derivative work became some company's closed-source product.
That is what RMS saw as being wrong with BSD style licenses, even if you take it as read that nobody still has (or expects to enforce) the archaic licensing clause. He wanted a way for people to say that this project stays in the open-source world, so open-source developers don't become unpaid R&D for every two-bit company under the sun.
Most of us aren't that bitter, but we do care that we'll be allowed to use the software derived from our own labor.
In summary, to win against the GPL, you cannot argue that it is invalid: if it were invalid then normal copyright law would mean that any copying or distribution was illegal
The other alternative is to argue that the GPL is the legal equivalent of public domain and so the creator relinquished all rights when he released the code.
That, however, would be exceedingly difficult to prove in the US, because the presumption of full copyright protection is so strong in this country. The Berne Convention, which the US is party to, doesn't even require that you explicitly claim copyright protection for that work: It is simply assumed, unless there is an existing reason the work automatically falls into the public domain. (All non-classified works of the US Government are public domain, for example.) To argue that the work is public domain without explicit words from the creator to that effect is difficult bordering on impossible, and most likely actually impossible in this country.
Read the whole comment: By "impossible", Bruce means "so hard it isn't worth trying." Obviously, there is no way to make an absolutely one-to-one correspondence between arbitrary-length messages and fixed-length hashes. The idea, therefore, is to make it so difficult to generate two messages with the same hash that it isn't worth anyone's effort to try.
Absolute security is almost always a chimera. You can only really achieve it with one-time pads, which aren't practical for the vast majority of cases. So you try to make things so difficult to crack that by the time anyone has succeeded, nobody still cares about the security of that message. Ideally, therefore, breaking one message does nothing to help you break any other message.
The crack of SHA-1 does help an attacker break any security system that uses SHA-1 by making it much easier to generate two messages that map to the same hash. This kind of thing makes cryptographers sit up and take notice, and hopefully develop some new algorithms. We have algorithms better than SHA, but until now nobody's had much reason to use them. This should change that.
I start to get worried when an implementation of a nice clean idea (such as Free Software) starts getting bogged down in special cases and exceptions.
Law is quite often focused on special cases and exceptions. It is frequently inelegant and, in point of fact, extremely ugly from a software designer's or philosopher's point of view.
But it needs to cover everything, because it needs to resist attacks from people who have financial reason to exploit edge cases and very technical, legalistic flaws. It can't leave anything, really, up to the reasonable person, because lawyers are paid to be highly unreasonable when going after the big money. Hence, all sorts of language to cover special cases abounds.
What's the point of license homogeneity?
For the same reason you don't have untrusted software running your heart-lung machine: When failure is extremely costly, you need one solid solution as opposed to a load of less-tested options. For good or ill, the GPL is the license the corporations are willing to defend, and that strengthens it immesurably.
Ascii was around a century before computers, and adopted by computers via teletypes.
Nope. ASCII was invented in 1963 and finalized in 1967.
You're probably thinking of Baudot's code, invented in 1874 and still in (limited) use in modern telecommunications. But that wasn't nearly a century before computers, either.
BTW, it's still conventional to put acronyms in all-caps, with a very few exceptions (Fortran, for example).
Slashdot Mirror
There are two distinct uses for hashing functions:
Only the first is significantly impacted by collisions. If you are betting the company (or country) on the unforgability of your computer files, you better have a more secure system than any hash algorithm. A good hash algorithm is a good tool, but it isn't a complete protocol. And don't let anyone fool you: Designing a good security protocol is hard. Very few companies really want the hassle. That is why the kids from Finland usually have it so easy when they take the time to crack things like CSS.
If you're simply defending against shoddy networks, SHA-1 might even be overkill: Statistically, the odds are heavily in your favor even with something as 'insecure' as MD5. These news reports won't really impact people who simply have to maintain file integrity against random lossage.
The one thing that can't be cracked is an educated, skeptical mind. Use yours and if you don't have one, stay the hell away from my computers.
Okay, there were aspects I didn't know or didn't consider. I was, most likely, absolutely wrong. But I do have one parting shot:
People couldn't legally build IBM PC clones, either. People (Compaq!) especially couldn't clone the IBM BIOS to put into their IBM PC clones. That obviously stopped nobody.
Now that it's been verified (apparently), I guess it's even more certain that I was wrong. Jobs isn't (that) stupid (anymore).
I guess I'm not explaining myself well enough or you aren't reading well enough. Apple won't be able to maintain their margins if Taiwanese are cloning their boxes right and left because MS wants OEMs to build clones. MS wants people to build clones because Apple lives and dies on hardware margins, and if Apple moves to x86 chips MS-friendly OEMs will be willing to play along. Finally, putting a MacOS API into the Windows released for those clones would put the final nail in Apple's coffin by rendering MacOS redundant in the eyes of many people.
There isn't anything hard in my posts. Apple can only maintain margins if it has a monopoly on its hardware. Since x86 machines are cheaper for the foreign OEMs to build than PPC machines, it will not maintain that monopoly if it ever builds an x86 Macintosh machine. No monopoly, no margins, and MS moves in with a special Windows version to clean up the remains of Apple's customer base.
Not for long. Apple has no divine right to margins if it is no longer the single source of that hardware.
Plus the small matter of all MacOS software running on PPC instead of x86. If MacOS ran on x86, that huge barrier would disappear.
I'm not talking about developers. I'm talking about MacOS users who would love a cheap source for Macintosh hardware. The market exists to fill needs, even if Apple does not. Especially if Apple does not.
Because MS doesn't sell hardware. It sells software. People buy more software if hardware is cheap. MS would love it if hardware were somehow absolutely free, but the best it can do is get the OEMs to pump out gajillions of Dells and Compaqs with Windows pre-installed. Those OEMs can't get PPC chips cheap enough to clone current Macs, but if Macs were x86-based it would become feasible for the OEMs to clone them.
No, the biggest distinction is the software. Most people don't know or care what OS they're running. They would just as soon run Windows if it ran the programs they liked. And if Apple goes through with the x86 deal, it will.
Maybe I am out in left field somewhere. My line of reasoning goes like this:
*(And why has nobody compared Apple to Be yet? This is exactly what Be did right before it sank beneath the waves: The last versions of BeOS ran on whitebox x86 machines)
For one thing, it's difficult to design a program that does everything. This is because the complexity in software mainly comes from the interfaces between components, and the more your program does the more interfaces it has to have.
(Interfaces aren't always explicit, but the best ones are. Bad software is mainly characterized by fuzzy boundaries between functional units and promiscuous sharing of data between blocks of code that don't need to know it.)
The easiest program to design does one thing and hooks up to a simple API for its communication with the outside world. Unix command-line programs are built this way, and it has resulted in a lot of stable programs. Trying to expand a program is usually best done by splitting it and giving each part an easy way to talk with the other parts. This can be as easy as a bunch of subroutines that call each other or as complex as a client/server pair that send data to each other over the Internet. That way, each part can be reasoned about in isolation and ignored when you need to think about other parts, or the connections between all of the parts.
For another thing, it's difficult to change one part of a program. Making the boundaries between parts clear and strong helps, but it's never quite as easy as you first imagine. If you want to change the web browser component, do you really want to rebuild the entire project and try to integrate another browser into your framework? (If you don't have a framework of some kind, it would be easier to scrap the project and start again. An ad hoc communication system between components is usually impossible to change cleanly.)
It could be done. But I don't think it could be done well.
It's entirely possible that the x86 ISA is utterly unsuited to emulate any real chip that isn't many hundreds of times slower than the physical processor. Hell, I have a (somewhat) slow time of emulating a VAX (simh) on my 800MHz Duron, and I have plenty of RAM. Register spill is too expensive and the cache simply can't keep up, apparently.
It would probably be too expensive to design a multi-CPU computer, but if the G4 and G5 can't hold up against the Pentium M and sequelae in the laptop game Apple will have to do something. (As a point of reference, my Pentium M laptop is quiet and cool-running. I frequently don't know it's on when I'm across the room unless the screen is up and lit, and I can comfortably hold it in my lap.) Computers are only going to get smaller, and therefore noise and heat are only going to be bigger marks against any machine. I think fans will be effectively phased out sooner than most of us think.
I don't think Apple is going anywhere. I also agree with you that the x86 isn't an ideal PPC emulation platform, but where else will Apple turn? They couldn't convince Motorola to make a better 68k, so they were forced to move to PPC. Can they convince IBM to make a better PPC chipset, now that IBM is so aligned with Linux and its own service business? Will Intel risk Microsoft's wrath by luring Apple with a well-designed ISA? If Apple actually ports MacOS to x86 chips, what's to stop Microsoft from porting Windows to that generation of Mac hardware? Driver here, tweak there, and Apple is looking at serious OS competition in its own ballfield.* Not to mention the inevitable Linux ports.
*Microsoft could even entice a few Taiwanese whitebox makers to churn out Mac clones at a much smaller fraction of the cost Apple would want to sell them for. Remember that while Apple makes money from hardware sales, Microsoft benefits from hardware being as cheap as possible.
How does that in any way negate my position? Where does it say that thimerosal has anything to do with autism? I'll repost the relevant material, even though you're apparently so far in denial you can no longer read for comprehension:
Apparently, the worst it ever did was cause mild redness and swelling. Redness and swelling is a common immune reaction to anything that penetrates the skin. Autism is in a completely different ballpark... hell, it's a different game from a mild immune reaction.
I don't know why you are in denial over this. Is your conspiracy theory so precious that you won't allow actual evidence to damage it? Is it so wonderful to be able to hate that you would try to hurt children in order to keep your hatred fresh in your mind?
I don't expect you to respond, because I don't expect you to have anything to respond with. Your mind is so poisoned by hate and suspicion you can't even read the plain meaning of a text. I can only hope that you aren't actually hurting any children with your lunacy.
And this precludes them from going x86 how? Surely you can run Apple ][ software at many times native speed under emulation if your real chip is a Pentium M or Pentium D. And since these aren't games, the speed boost is an unmixed blessing. It becomes more difficult to beat hardware as you go from Apple ][ to m68k to PPC, but correctness is maintained and that's what really counts.
In other words, emulation is the key here. Emulation allowed Apple to dump the aging m68k and move to PPC and it at least could allow them to dump PPC for next-generation Intel chips.
The CDC disputes that claim. This has links to more recent research which also calls your claims into question. Unless you have evidence, you would be well advised to shut up and let us find the real cause so we can actually help people.
If dynamite caused radiation sickness and cancer, this would be exactly right. As it stands, however, even a Nazi dirty bomb would have had at least a huge psychological effect, if not a very large military one.
It might have opened our eyes to the true dangers of radiation sooner, but I don't think so. It could be an interesting jumping-off point for an alternative history story: What if it gave other groups the idea to make their own dirty bombs in the unsettled postwar years?
And if I CAPITALIZE most WORDS I will become MICROSOFT'S worst nightmare and break the WINTEL monopoly even SOONER. Then APPLE and IBM will pay me MONEY for my CAPS-LOCK of DOOM.
Ah yes, the sound of a new urban legend in the making. I've not heard this one yet, and it's already as stupid as they come.
No, SPAM stands for spiced ham, and it has nothing to do with the military. Here's Hormel on the topic:
It's almost an initialism, but not quite, and it predates the military's association with the product.
WINE seems to do okay with the code in and of itself. It doesn't emulate all of the APIs it needs to, but that wouldn't be a problem if MS itself was designing the system.
MS needs something like WINE or even Bochs if it wants Longhorn to be anything more than XP with a few new features and subtly different theme. Windows 95-era code cannot be trusted to run on the bare OS: It needs to be fooled completely and kept inside a small sandbox. Mutilating Longhorn's security model to keep SimCity and MSIE 3.0 happy will just ensure future security nightmares.
It might be better if MS does like Apple did when it moved from 68000-model CPUs to the PPC chips: Treat the old machine code as bytecode and run it inside a VM that hosts its own OS.
This should probably be posted in large, red text right at the top of this discussion. If I had mod points, I would be modding this up right now.
The people who think X's networking is slow and inefficient need to realize that, first, on most machines it isn't noticeable, and, second, it's vital to making X usable in a lot of cases. X's networking is the difference between being able to run a graphical program on a remote machine and being limited to running text programs.
Frankly, if X wasn't built around the networking model it would be necessary to reinvent it at a higher level, thus making it orders of magnitude less flexible and, ultimately, less usable. That ignores the inevitable standards wars that would surround any such reinvention process, probably leading to dozens of subtly and individually broken ways of putting a window on a remote machine.
The people who focus on creating a GUI for a desktop machine that only ever runs local programs aren't creating a credible replacement for X. They're trying to reinvent the 'graphical shells' of the 1980s, back when DOS and the original Macintosh ruled the microcomputer world.
Right on both counts, but so what? Nobody in the summary mentioned Linux, and the article isn't about how this will impact Linux. It happens to be in the Linux section, but I don't think Slashdot has a specific X section.
And realistically speaking, most people will be using this on a Linux machine of one form or another.
I'm a UNIX guy and I agree with you, actually. If the VMS security model is implemented properly on Longhorn (or if it was implemented on WNT), MS would have something legitimate to gloat over when talking about how 'archaic' UNIX systems are. But MS couldn't do that with WNT or Windows XP and it won't be able to do that with Longhorn.
Backwards compatibility for applications is one piece of the puzzle, but not the most interesting one. You can run applications in a virtual machine or a sandbox and solve most of the problems. Think of something between chroot and WINE as the new 'Operating Environment' for pre-Longhorn applications that need to think they're running as Admin when they really can't be trusted with Admin-level access. This is nothing new, and MS could have done it in the original WNT.
The main problem for MS is that they feel the need to talk down to their users. The command line is too complex for their intended audience, so they have deprecated it and made it less powerful in favor of endless graphical wizards that walk you through everything. VMS style privileges are too complex, so they completely ignore the issue until their users are screaming at them, then they cruft on UNIX-style privileges and ignore the better but more complex VMS model originally part of their design.
MS thinks everyone who uses their OSes, even sysadmins, is unskilled labor. That is why they don't give people powerful tools: Powerful tools are complex, and liable to turn in your hand if you don't understand them.
(The unansked question is why Linux or the BSDs haven't adopted the VMS privilege model yet. I hope that becomes an option someday.)
Well, they also aren't selling the software they make, or building businesses around the fundamental research they do. All their money comes from tuitions and philanthropic groups and (at least for some) taxes. If a university professor or student invented a million-dollar idea, I don't know if the university itself could hope to reap the profits directly.
The example I think most people here will be familiar with is BSD Unix, originally developed at the University of California at Berkeley. A lot of people got a lot of use out of that code, but I don't think UC-Berkeley ever saw a dime of direct profit.
Especially those of us who think this place is called Dotslash. ;-)
The current practice is if the chipmaker knows that some opcodes aren't going to work on all chips, it doesn't document those opcodes and the people who search for them know that they can't build reliable programs that use them. This is similar to what you're suggesting, but it isn't quite the same.
(Emulators of popular 8-bit chips like the 6510 (for the Commodore-64 and variants) and the Z80 (for the ZX-Spectrum and others) will almost always support the undocumented opcodes in ways faithful to at least some of the real chips. This is mainly because 8-bit chips didn't have that many opcodes to begin with.)
Another possibility, used on some assemblers for RISC CPUs like the MIPS, is for the assembler to translate a single unsupported opcode into a string of opcodes the chip does support. (That is, some 'opcodes' are really macros.) This might be useful to work around chip flaws, but it makes stepping through the machine code that much less intuitive. All the Real OSes these days have source-level debuggers, I suppose.
I think we all understand this, but as I understand the BSD license you could change one line of code and relicense the result under terms far more restrictive than the GPL. The original project wouldn't be hit, but it has happened that the derivative work became some company's closed-source product.
That is what RMS saw as being wrong with BSD style licenses, even if you take it as read that nobody still has (or expects to enforce) the archaic licensing clause. He wanted a way for people to say that this project stays in the open-source world, so open-source developers don't become unpaid R&D for every two-bit company under the sun.
Most of us aren't that bitter, but we do care that we'll be allowed to use the software derived from our own labor.
The other alternative is to argue that the GPL is the legal equivalent of public domain and so the creator relinquished all rights when he released the code.
That, however, would be exceedingly difficult to prove in the US, because the presumption of full copyright protection is so strong in this country. The Berne Convention, which the US is party to, doesn't even require that you explicitly claim copyright protection for that work: It is simply assumed, unless there is an existing reason the work automatically falls into the public domain. (All non-classified works of the US Government are public domain, for example.) To argue that the work is public domain without explicit words from the creator to that effect is difficult bordering on impossible, and most likely actually impossible in this country.
Read the whole comment: By "impossible", Bruce means "so hard it isn't worth trying." Obviously, there is no way to make an absolutely one-to-one correspondence between arbitrary-length messages and fixed-length hashes. The idea, therefore, is to make it so difficult to generate two messages with the same hash that it isn't worth anyone's effort to try.
Absolute security is almost always a chimera. You can only really achieve it with one-time pads, which aren't practical for the vast majority of cases. So you try to make things so difficult to crack that by the time anyone has succeeded, nobody still cares about the security of that message. Ideally, therefore, breaking one message does nothing to help you break any other message.
The crack of SHA-1 does help an attacker break any security system that uses SHA-1 by making it much easier to generate two messages that map to the same hash. This kind of thing makes cryptographers sit up and take notice, and hopefully develop some new algorithms. We have algorithms better than SHA, but until now nobody's had much reason to use them. This should change that.
Law is quite often focused on special cases and exceptions. It is frequently inelegant and, in point of fact, extremely ugly from a software designer's or philosopher's point of view.
But it needs to cover everything, because it needs to resist attacks from people who have financial reason to exploit edge cases and very technical, legalistic flaws. It can't leave anything, really, up to the reasonable person, because lawyers are paid to be highly unreasonable when going after the big money. Hence, all sorts of language to cover special cases abounds.
For the same reason you don't have untrusted software running your heart-lung machine: When failure is extremely costly, you need one solid solution as opposed to a load of less-tested options. For good or ill, the GPL is the license the corporations are willing to defend, and that strengthens it immesurably.
I found a bug in your code already.
Nope. ASCII was invented in 1963 and finalized in 1967.
You're probably thinking of Baudot's code, invented in 1874 and still in (limited) use in modern telecommunications. But that wasn't nearly a century before computers, either.
BTW, it's still conventional to put acronyms in all-caps, with a very few exceptions (Fortran, for example).