Determining whether a finite state system is in an inconsistent state is not equivalent to solving the halting problem. Consistency is defined by a set of invariants which must remain true at all times. If you evaluate the invariants after the change, and they're not true, you have to back out the change. Database systems do this routinely.
There's a difference between applying a simple set of rules, noting something that's wrong according to them and saying "that's wrong", and determining when you're going into an "inconsistent state". A program internally has to be able to stay consistent at all times, know where it's at and what it's doing. You'd have to be a lot more specific about what you're considering an inconsistent state.
Also, this is part of the problem with programmers trying to listen to non-programmers for suggestions for improvement in software - a lot of times, non-programmers have very different definitions, or at least ideas about what these terms mean, than the accepted definitions of the terms, so discerning (and getting them to explain!) what they mean by these terms can be diifficult, because they think they know what they mean. (I'm a programmer/admin, but I do deal with customers, so I have first hand experience with this - trying to reconcile the terms that a customer tosses around with what they really are trying to say.)
J. Random Hacker may not need those tools on her own desktop, but she needs those tools on somebody's desktop.
Maybe your definition of "need" is just different than mine, but just because I write a piece of software, and decide to provide it for free (and I do try to provide decent, reasonable documentation, and such, so you can use it), doesn't mean I _need_ you to use it. It doesn't make the software I've written any more fundamentally valuable to _me_ personally.
I agree with what others are saying here - there are certain people who want for Linux to take over - on the desktop, and elsewhere. I don't care if it does, as long as I can continue to use it, and no one can tell me I can't, I'm happy with it. I'll also happily admit, at this point, that Linux is not for everybody. It's the right answer for me. If you want a Unix-like system, with a pretty GUI and all the design and such that goes with it, look at OS X - Linux is not for you. If you want to use the machine but have no interest in having any greater understanding of it, Linux is not for you. Just accept the fact that maybe Linux isn't the right answer for you, and use whatever is, don't try to tell the people writing open-source/free software that they "need" you.
Something about looking in the mouth of a gift horse definitely belongs here.
If a program needs some piece of information, and there's some way the program can find it out without asking the user, the program MUST find it out by itself. Even if it's more work for the programmer. Asking the user is not an option. Period.
I've run into software that made this assumption in the past. Yeah, it's nice when its assumptions make it look smart, and it gets it right 90, 95, even 99.9% of the time. However, there will ALWAYS, and I mean ALWAYS, be some unexpected corner case where the device it's talking to gives it wrong info, or something, and what it thinks about the hardware it's talking to is WRONG. 100% wrong. If the software assumes "I'm infallible! I'm always right! I know EVERYTHING!", you'll be beating your head against it, cursing it to high heaven, because it won't let you just bypass it trying to be smart, and tell it "you are the machine. you are stupid. do what i tell you."
If the system is in an inconsistent state, it must detect that it is in an inconsistent state. It's not the user's job to validate the internal consistency of the system's tables.
If it could always know if it was in an inconsistent state, or would be going into an inconsistent state, then you would be able to solve the halting problem. However, go take a course that covers finite state automata - you will learn about the halting problem, and why a program cannot always know if it's going to end up in an inconsistent state. Expecting the machine to just know these things is ridiculous, no matter how much sense it makes to someone who's not familiar with the nuts and bolts of the technology.
And the first mistake you made is the same mistake that so many people have made before you. Rule #1 - the machine is STUPID. Computers only know the lies we tell them. Expecting the machine to be smart is just asking for trouble.
Unfortunately, there are two major points of view on the human-computer interaction - one of them is the Mac and Windows mentality, which basically assumes you, the user, are a complete and utter moron, who could barely find your ass with both hands. This works OK some of the time, but when it doesn't work, the number of failure modes is simply astronomical, and the one the machine will pick is unpredictable at best. Then there's the more traditional UNIX mentality (which VMS and other similar systems also follow, IMO) - which assumes that you, the human, are intelligent, literate, and you do in fact know more than the machine about what you are doing and how you want it done, but the machine is a tool for you to achieve that. This means the machine doesn't make silly assumptions about what you do or don't want, and it doesn't try to force those ridiculous assumptions on you. It requires that you know more, and has a more daunting learning curve, but if something's wrong, you can fix it. You at least have the option of fixing it. Whereas with the former mentality, everything is so closed up, that even if you know exactly what you want, you're still stuck jumping through whatever hoops the people who assembled the environment put there, and if things break... well gee, you're just stuck.
This is why I prefer Linux - and I don't _want_ it to be "just like Windows, but free!" If I wanted my operating system to make assumptions and decisions for me, I'd have just stuck with Windows. That's not what I want from a computer. It's more like, "you're the stupid machine, I'm the smart human. You're my bitch, you do what I say." That's the way I prefer it.
What are you on about? I did 'apt-get install module-init-tools', built and installed the 2.6 kernel, and I've been running 2.6 kernels on my office workstation ever since (1.33 GHz Athlon, 2 GB of PC133 SDRAM, dual head). There are these lovely things called "distributions" now, you really ought to try them...
I have a 400MHz Pismo (I recently upgraded it to 768 MB of RAM, and added an AirPort card to it). Is the performance gain as good as PowerLogix claims it is? The price is a little steep, but if the performance gain is good enough, I'd like to get one. (I run Debian GNU/Linux on mine.)
Seconded. A couple years ago, I was standing in the local Borders back home, browsing the tech section, when a woman walked up to the networking section, and started looking at CCNA books. I heard her say, "I really wish they had these as audio books, I just don't have the time to read all this technical stuff..."
It really seems like the people who get these certifications, or at least as their primary means of education/self-improvement toward a job, are otherwise clueless, lazy, and really shouldn't be around a computer to begin with.
Unfortunately, as far as POST beep codes go, systems with an Award BIOS are pretty much useless. They basically have one "something's wrong" beep, which is one long beep. At least AMI and, afaik, Phoenix BIOSes still employ them.
At best you might question whether Solaris 10 will be SunOS 6; but there's never been any comment or rumor about that.
I've been told they might have too - too many thing might think that SunOS 5.10 == SunOS 5.1, and that might cause an assortment of nasty problems, so they may have to call it SunOS 6.0. Apparently they even have an internal list of "Things that Don't Like SunOS 5.10"...
It's not so much that Sun as a whole doesn't like Linux. It seems there are 2 major factions - there's the hardware side, which says "hey, Linux is good, it means more software to run on our hardware!"; and the software side, which seems to say "we're still pissed that Linux ate our lunch on x86, they can go get bent". The two sides seem to alternately rise and fall in prominence within the company; thus, the apparently-changing stance of Sun about Linux.
No, that actually wasn't "the same Porsche". I believe it was done by F. A. Porsche Design, which is a business started by the grandson of the man who started the automobile company. So they're related, but not the same company.
Well, there's always the Titanium PowerBook latches that I saw break so many times. I was underwhelmed in several ways with certain aspects of the design of the new PowerBooks. I have a PowerBook Pismo (bronze keyboard, FireWire) on my lap right now, running Debian sid, and I think it's way better engineered than the current crop of Apple notebooks. Simple black, clean design. I love it. (Yeah, it's a bit older, but there's plenty of room for upgrading.)
As another followup mentioned, AXP, PPC and MIPS were all supported through NT 4, not just 3.5/3.51. The NT moniker came, not from a chip, but a chip simulator - NT was originally developed to run on Intel's i960 RISC architecture, but because Intel was so far behind on its development, it only ever ran on the i960 simulator - which was known as "N-Ten". That's where "NT" came from, though Microsoft variably admits or denies that.
Incidentally, I think you'll find NT was always going to have its own filesystem and HPFS was simply an interim/migration support solution (much like the albatross of FAT/FAT32). Certainly every *released* version of NT has used NTFS.
Wrong. Wrong, wrong, _wrong_. NTFS _is_ HPFS! Windows NT 3.1 could read HPFS volumes, because at the time NTFS was HPFS, to the letter. MS added features to it as time went on, eventually making them incompatible, but NTFS started life as code borrowed straight-across from OS/2.
Also, Caldera (before morphing into the SCO Group) provided higher-end x86 hardware (especially multiprocessor systems) for Linux developers to test the kernel on, for SMP development. So how they can claim Linux developers didn't have access to that kind of hardware is ludicrous, considering they provided the hardware for testing. Ah, more examples of their crack(-smoking) legal team at work...
Well, you could run several apps via the FX!32 dynamic-recompiling emulation layer. However, yeah, there was precious little software ever built for NT on non-x86 platforms - almost no third-party vendors released anything, and even Microsoft didn't release much (some of the Office apps, some of the BackOffice software, and development tools - that was really about it).
The sad thing was, on Alpha, it was still a 32-bit OS - and it used the non-native "little-endian" mode of all the other CPUs it ran on. Basically, it made the system look as much like an x86 as it could, which doesn't seem like the super-portable platform that MS claimed it to be. What a surprise...
NT (through version 4) also ran on certain PowerPC-based systems (made by... wait for it... IBM!) along with MIPS and Alpha/AXP-based systems. NT was actually originally developed to run on Intel's i960 RISC processor family, but the i960 ended up being so far behind schedule that it only ever ran on the i960 CPU simulator - dubbed N-Ten (which is where NT came from).
But yes, SCO is off their collective rocker if they think IBM has "little or no experience" with Intel CPUs. What about the IBM PC? The PS/2 line? Their more current line of PCs? DOS, which they did most of the work (from what I understand) to take from the early QDOS product to something (relatively) usable? OS/2? AIX for x86? Geez, they're not even trying.
After perusing the PDF and looking at their quoted examples of infringement, I noticed something. Practically everything they quote is part of some outside patch, which isn't in the mainline kernel at all. It really seems like they're reaching, if their "examples" are legitimate at all. Even that remains to be seen. I'll be watching intently - hopefully either PJ from Groklaw, or Bruce Perens, or someone will have a good analysis soon of the claimed infringement.
No, he didn't. All you have to do with 2.6's build process, once you've configured it, is 'make', and everything (appropriate kernel images, modules, etc.) are built automatically. It's really quite nice.
Did anyone really care about backward compatibility with N64 titles? As I recall, the N64 was something of a bust in general, so I don't think it really would have mattered in that case. With their current system, yeah, it might be more of an issue - it may be at the bottom of the "big 3" console pile, but it's got a much better following than the N64 ever did.
I would think Microsoft would have put that idea to death, considering the quiet obliteration of UltimateTV. But who knows, Microsoft might just try another round of beating that dead horse. Guess we'll see.
You're kidding, right? Please, show me a hard drive from an Apple system that I can't plug into my x86 Linux box and read just fine. I'll give you a damn cookie if you can show me one. (No, FireWire doesn't count, I can use one of those too.)
Determining whether a finite state system is in an inconsistent state is not equivalent to solving the halting problem. Consistency is defined by a set of invariants which must remain true at all times. If you evaluate the invariants after the change, and they're not true, you have to back out the change. Database systems do this routinely.
There's a difference between applying a simple set of rules, noting something that's wrong according to them and saying "that's wrong", and determining when you're going into an "inconsistent state". A program internally has to be able to stay consistent at all times, know where it's at and what it's doing. You'd have to be a lot more specific about what you're considering an inconsistent state.
Also, this is part of the problem with programmers trying to listen to non-programmers for suggestions for improvement in software - a lot of times, non-programmers have very different definitions, or at least ideas about what these terms mean, than the accepted definitions of the terms, so discerning (and getting them to explain!) what they mean by these terms can be diifficult, because they think they know what they mean. (I'm a programmer/admin, but I do deal with customers, so I have first hand experience with this - trying to reconcile the terms that a customer tosses around with what they really are trying to say.)
Suggest that they tack on "or MacOS X", instead of saying they're completely wrong?
J. Random Hacker may not need those tools on her own desktop, but she needs those tools on somebody's desktop.
Maybe your definition of "need" is just different than mine, but just because I write a piece of software, and decide to provide it for free (and I do try to provide decent, reasonable documentation, and such, so you can use it), doesn't mean I _need_ you to use it. It doesn't make the software I've written any more fundamentally valuable to _me_ personally.
I agree with what others are saying here - there are certain people who want for Linux to take over - on the desktop, and elsewhere. I don't care if it does, as long as I can continue to use it, and no one can tell me I can't, I'm happy with it. I'll also happily admit, at this point, that Linux is not for everybody. It's the right answer for me. If you want a Unix-like system, with a pretty GUI and all the design and such that goes with it, look at OS X - Linux is not for you. If you want to use the machine but have no interest in having any greater understanding of it, Linux is not for you. Just accept the fact that maybe Linux isn't the right answer for you, and use whatever is, don't try to tell the people writing open-source/free software that they "need" you.
Something about looking in the mouth of a gift horse definitely belongs here.
If a program needs some piece of information, and there's some way the program can find it out without asking the user, the program MUST find it out by itself. Even if it's more work for the programmer. Asking the user is not an option. Period.
I've run into software that made this assumption in the past. Yeah, it's nice when its assumptions make it look smart, and it gets it right 90, 95, even 99.9% of the time. However, there will ALWAYS, and I mean ALWAYS, be some unexpected corner case where the device it's talking to gives it wrong info, or something, and what it thinks about the hardware it's talking to is WRONG. 100% wrong. If the software assumes "I'm infallible! I'm always right! I know EVERYTHING!", you'll be beating your head against it, cursing it to high heaven, because it won't let you just bypass it trying to be smart, and tell it "you are the machine. you are stupid. do what i tell you."
If the system is in an inconsistent state, it must detect that it is in an inconsistent state. It's not the user's job to validate the internal consistency of the system's tables.
If it could always know if it was in an inconsistent state, or would be going into an inconsistent state, then you would be able to solve the halting problem. However, go take a course that covers finite state automata - you will learn about the halting problem, and why a program cannot always know if it's going to end up in an inconsistent state. Expecting the machine to just know these things is ridiculous, no matter how much sense it makes to someone who's not familiar with the nuts and bolts of the technology.
And the first mistake you made is the same mistake that so many people have made before you. Rule #1 - the machine is STUPID. Computers only know the lies we tell them. Expecting the machine to be smart is just asking for trouble.
Unfortunately, there are two major points of view on the human-computer interaction - one of them is the Mac and Windows mentality, which basically assumes you, the user, are a complete and utter moron, who could barely find your ass with both hands. This works OK some of the time, but when it doesn't work, the number of failure modes is simply astronomical, and the one the machine will pick is unpredictable at best. Then there's the more traditional UNIX mentality (which VMS and other similar systems also follow, IMO) - which assumes that you, the human, are intelligent, literate, and you do in fact know more than the machine about what you are doing and how you want it done, but the machine is a tool for you to achieve that. This means the machine doesn't make silly assumptions about what you do or don't want, and it doesn't try to force those ridiculous assumptions on you. It requires that you know more, and has a more daunting learning curve, but if something's wrong, you can fix it. You at least have the option of fixing it. Whereas with the former mentality, everything is so closed up, that even if you know exactly what you want, you're still stuck jumping through whatever hoops the people who assembled the environment put there, and if things break... well gee, you're just stuck.
This is why I prefer Linux - and I don't _want_ it to be "just like Windows, but free!" If I wanted my operating system to make assumptions and decisions for me, I'd have just stuck with Windows. That's not what I want from a computer. It's more like, "you're the stupid machine, I'm the smart human. You're my bitch, you do what I say." That's the way I prefer it.
What are you on about? I did 'apt-get install module-init-tools', built and installed the 2.6 kernel, and I've been running 2.6 kernels on my office workstation ever since (1.33 GHz Athlon, 2 GB of PC133 SDRAM, dual head). There are these lovely things called "distributions" now, you really ought to try them...
I have a 400MHz Pismo (I recently upgraded it to 768 MB of RAM, and added an AirPort card to it). Is the performance gain as good as PowerLogix claims it is? The price is a little steep, but if the performance gain is good enough, I'd like to get one. (I run Debian GNU/Linux on mine.)
Seconded. A couple years ago, I was standing in the local Borders back home, browsing the tech section, when a woman walked up to the networking section, and started looking at CCNA books. I heard her say, "I really wish they had these as audio books, I just don't have the time to read all this technical stuff..."
It really seems like the people who get these certifications, or at least as their primary means of education/self-improvement toward a job, are otherwise clueless, lazy, and really shouldn't be around a computer to begin with.
Unfortunately, as far as POST beep codes go, systems with an Award BIOS are pretty much useless. They basically have one "something's wrong" beep, which is one long beep. At least AMI and, afaik, Phoenix BIOSes still employ them.
At best you might question whether Solaris 10 will be SunOS 6; but there's never been any comment or rumor about that.
I've been told they might have too - too many thing might think that SunOS 5.10 == SunOS 5.1, and that might cause an assortment of nasty problems, so they may have to call it SunOS 6.0. Apparently they even have an internal list of "Things that Don't Like SunOS 5.10"...
Actually, a friend of mine who works for Sun was joking about them using that moniker awhile back, but apparently they decided against it. Darn.
It's not so much that Sun as a whole doesn't like Linux. It seems there are 2 major factions - there's the hardware side, which says "hey, Linux is good, it means more software to run on our hardware!"; and the software side, which seems to say "we're still pissed that Linux ate our lunch on x86, they can go get bent". The two sides seem to alternately rise and fall in prominence within the company; thus, the apparently-changing stance of Sun about Linux.
Or maybe I'm just full of it.
Godwin's law only applies to Usenet. And besides, you can't intentionally invoke Godwin's law. Heh.
No, that actually wasn't "the same Porsche". I believe it was done by F. A. Porsche Design, which is a business started by the grandson of the man who started the automobile company. So they're related, but not the same company.
Well, there's always the Titanium PowerBook latches that I saw break so many times. I was underwhelmed in several ways with certain aspects of the design of the new PowerBooks. I have a PowerBook Pismo (bronze keyboard, FireWire) on my lap right now, running Debian sid, and I think it's way better engineered than the current crop of Apple notebooks. Simple black, clean design. I love it. (Yeah, it's a bit older, but there's plenty of room for upgrading.)
As another followup mentioned, AXP, PPC and MIPS were all supported through NT 4, not just 3.5/3.51. The NT moniker came, not from a chip, but a chip simulator - NT was originally developed to run on Intel's i960 RISC architecture, but because Intel was so far behind on its development, it only ever ran on the i960 simulator - which was known as "N-Ten". That's where "NT" came from, though Microsoft variably admits or denies that.
Incidentally, I think you'll find NT was always going to have its own filesystem and HPFS was simply an interim/migration support solution (much like the albatross of FAT/FAT32). Certainly every *released* version of NT has used NTFS.
Wrong. Wrong, wrong, _wrong_. NTFS _is_ HPFS! Windows NT 3.1 could read HPFS volumes, because at the time NTFS was HPFS, to the letter. MS added features to it as time went on, eventually making them incompatible, but NTFS started life as code borrowed straight-across from OS/2.
Also, Caldera (before morphing into the SCO Group) provided higher-end x86 hardware (especially multiprocessor systems) for Linux developers to test the kernel on, for SMP development. So how they can claim Linux developers didn't have access to that kind of hardware is ludicrous, considering they provided the hardware for testing. Ah, more examples of their crack(-smoking) legal team at work...
Well, you could run several apps via the FX!32 dynamic-recompiling emulation layer. However, yeah, there was precious little software ever built for NT on non-x86 platforms - almost no third-party vendors released anything, and even Microsoft didn't release much (some of the Office apps, some of the BackOffice software, and development tools - that was really about it).
The sad thing was, on Alpha, it was still a 32-bit OS - and it used the non-native "little-endian" mode of all the other CPUs it ran on. Basically, it made the system look as much like an x86 as it could, which doesn't seem like the super-portable platform that MS claimed it to be. What a surprise...
NT (through version 4) also ran on certain PowerPC-based systems (made by... wait for it... IBM!) along with MIPS and Alpha/AXP-based systems. NT was actually originally developed to run on Intel's i960 RISC processor family, but the i960 ended up being so far behind schedule that it only ever ran on the i960 CPU simulator - dubbed N-Ten (which is where NT came from).
But yes, SCO is off their collective rocker if they think IBM has "little or no experience" with Intel CPUs. What about the IBM PC? The PS/2 line? Their more current line of PCs? DOS, which they did most of the work (from what I understand) to take from the early QDOS product to something (relatively) usable? OS/2? AIX for x86? Geez, they're not even trying.
After perusing the PDF and looking at their quoted examples of infringement, I noticed something. Practically everything they quote is part of some outside patch, which isn't in the mainline kernel at all. It really seems like they're reaching, if their "examples" are legitimate at all. Even that remains to be seen. I'll be watching intently - hopefully either PJ from Groklaw, or Bruce Perens, or someone will have a good analysis soon of the claimed infringement.
Oh... XFree 4.4.0. You must be a time traveler. Got any good sports scores to share with us?
Seriously, they're not building a 4.4.0 final release, it's some 4.3.99.x tree pulled out of CVS. 4.4.0 definitely isn't out yet.
No, he didn't. All you have to do with 2.6's build process, once you've configured it, is 'make', and everything (appropriate kernel images, modules, etc.) are built automatically. It's really quite nice.
Did anyone really care about backward compatibility with N64 titles? As I recall, the N64 was something of a bust in general, so I don't think it really would have mattered in that case. With their current system, yeah, it might be more of an issue - it may be at the bottom of the "big 3" console pile, but it's got a much better following than the N64 ever did.
I would think Microsoft would have put that idea to death, considering the quiet obliteration of UltimateTV. But who knows, Microsoft might just try another round of beating that dead horse. Guess we'll see.
You're kidding, right? Please, show me a hard drive from an Apple system that I can't plug into my x86 Linux box and read just fine. I'll give you a damn cookie if you can show me one. (No, FireWire doesn't count, I can use one of those too.)