You just totally missed the point. I'm not saying that a $380 computer is as powerfull as an iMac. They're not competing on the same grounds.
But fact is that Apple is not competing on $380 computers, and have never shown an interest in doing so.
This low-level entry point exist only for PCs, and is certainly is a gateway for more expensive PCs. I mean, being a student and having $500 to put in a computer, I'm going to buy that one. It'll give me poor performances maybe, but I will learn and get my first computer experience on a PC. What do you think will be my next computer? Will I want to re-learn everything from scratch by changing platforms? Or will I go through the path of least resistance and just "upgrade" to a faster PC?
Thank you for illustrating my point. A computer for $299 Here and a monitor for $79.99 Here.
So if you have just $380 to put in a computer (think student here, his very first computer, the one that'll start molding his brain), then what could you possibly choose?
And keep in mind that outpost.com was the first website I tried. There _has_ to be less expensive. But we are already at less than 50% of the price of the lower Mac!!!!
While interesting and informative, it is also interesting to note one *huge* point that is left out in the article: The price. Mac have always been more expensive than PCs. Not that they are a lower value, but they are almost inexistent in the "entry-level" personal computer market. And they have always been.
Hence, the entry-level investment has always been higher for a Mac. You couldn't say "I'll buy this crappy one, and if I like it i'll upgrade later". Or simply speaking, if you had a thousand bucks to buy a machine, there was no alternative.
So if you deployed a Linux on 10000 machines on all your tech, marketing, IT, sales teams computers, and you had developped specific applications, drivers for some specific devices, and all the crap, you would just tell them: Sure, let's upgrate from 2.4 to 2.6 and cross your fingers?
The fact that they are cautious doesn't mean they distrust SP2. Like any major upgrage to a kernel (to any OS), it is going to break some of your specific devs, would it be only slightly.
This would be true for any OS. The fact that this one is Microsoft doesn't make it something against MS.
The funny thing is the last sentence of the story: "One IBM employee in the company's internal technology department characterized the decision as routine".
So a routine decision makes the front page of Slashdot, clearly advertized as "IBM doesn't trust Microsoft".
No matter how much secrets are at stake, nobody should (And I don't think Seagate can) prevent anyone from working to sustain his/her family. Giving that the guy did work on HDD for the last 17 years, I guess it is safe to say that it will be hard for him to find another job in an unrelated field, at least a job at the same level he was at Seagate. Seagate should offer compensation for this 2 year period. Of course, I didn't RTFA, so maybe they do. In which case it is fine. But if they don't, they'll get laughed out of court. At least I hope.
So you would like all these equipments to be "home made" with a "home made" minimalistic OS. They would cost twice as much and your health coverage would probably bump up by 25%. And I'm sure you wouldn't like it.
There is a proper balance to find between "very cheap and crappy" and "100.0000% secure, properly tested bu 15x more expensive". Nothing is perfect, nor is software, nor is hardware, nor is nurses and doctors. My guess is that as long as death by software mistakes are much lower than (and so insignificants compared to) deaths by human mistake, nobody will care.
Mistakes are part of life. Of course, software mistake can be minimized, but at what cost? And is it worth it?
Wow, you mean if the control computer crashes leaving the shutter to the Cobalt source open nobody could die? How about gamma knife overexposing the brain stem, cooking the brain stem couldn't possibly kill someone. How about a faulty homing cycle where the radiation head homes to the patient table, even if a patient is there.
And during all that time I guess the operator is just looking at it from behind the console, laughing his ass off of the patient getting his brain fried.
That was due to a bug in the software running the machine, not a trojan/virus/computer crash.
There is always an operator operating these machines, hence if the control machine (running win2k) was to go crazy, I hope the operator would shut down the actual radiation machine.
What you are describing is something else: The machine would act normally, but would deliver the wrong dosage.
This is the most stupid example. A trojan would have to be specially targetted for *that* specific machine. Hence, if it was running any other OS, the possibility to write a trojan for that OS would also exist.
The irresponsibility if from the hospital to connect their machines to the internet. AFAIK, a properly tuned Windows system with stable drivers is as stable as any other system (at least for WinNT/2K/XP), as long as it is air-tight isolated from any external source, read: No fdd drive, no CDROM drive, no network access to any computer that is not in that situation.
Apart from that, Windows is as suited for this kind of application as any OS.
Isn't the entire point (well, one of the many) of coding to standards that the page will degrade cleanly on lesser browsers?
That would work if the major browser was standard compliant. By doing what you suggest, you end up having a website that looks good for 4% of your audience and moderately crappy for 95% of them.
You should code to the Standards, not a browser There are so many irrelevant standards out there, that if we had to use them all, we would just be dying.
You should not code to standards. You should code to your audience. If they happen to be massively using a browser that is standard compliant, then you may code to the standard in replacement of that. If they use different browsers for which the only common denominator is a standard, then you should code to the standard.
Alas, most of the users to any website don't fall into any of the above category.
So I guess I'll keep on coding to a browser(s). So that 94% of the people can read me.
The NT kernel did not originate from unix, it originated from OS/2 and even before that, VMS Well, if you had read the article you just linked to, you would have found out that the NT kernel doesn't have anything to do with the OS/2 kernel. They just planned (plan which was later dropped) to support most of its APIs. NT is derived from VMS, not OS/2, and that's what I missasociated with UNIX in my previous post. Fact is, VMS is not too different from UNIX, but that's besides the point.
the initial idea of NT was to support for portions of the DOS, OS/2 The idea behind the NT kernel was certainly not to support DOS or OS/2. That might have been an early option, but was clearly dropped along the way. The idea was for microsoft to finally have a kernel. DOS is nowhere close to what I would call a kernel.
Memory allocation you are describing is the stuff a 5 years old would write. This proves my point, the MS kernels don't keep good enough track of memory to avoid this problem Well, that one is interesting? How my analogy with a bad programmer proves anything is just beyond me.
In my experience, BSOD in the NT kernel are due to two problems: 1. Bad drivers. Linux isn't exempt from problems in that area either. The BSOD is called a Kernel Panic. 2. A stupid architecture problem which lets any program override system dlls with "updated" ones. So let's say the foo.dll installed is v1.2 and a program needs foo.dll v1.3 to run, then the program will override the system dll (Yes, the program will override some of the code used by the kernel) with it's own version of the dll. Of course, when you deal with serious vendors, those dlls will have been properly tested. But when you deal with poor vendors, the side effect is that those poor vendors end up installing buggy dlls, making the kernel buggy along the way. This was a huge issue until XP, which disallow this practice by keeping all versions of the dlls. So the kernel only uses the code that was written by MS.
The BSOD is just a materialization of a SIGSEGV sent to the kernel, nothing else, proving that the memory allocation works the way it should by killing processes that try to access memory in a segment they don't own.
This has nothing to do with a kernel that "don't keep good enough track of memory" (again, you serve me that vague sentence). Otherwise how would you explain my system being up since 4 month? Or my server being up since 2.5 years? How can that work with system that vaguely mistake system pages with program pages?
and I was just thinking that if that had of happened in windows, my system would still probally be all lagged Well, I have never encountered that in almost 8 years of heavy NT usage. Maybe it's just me then.
ok, well I don't have time to argue every point you made so I'll just sum it up, and I call it bullshit.
WinNT kernel was made right our of a UNIX kernel. It was (The original one, WinNT 3.51) almost POSIX. Memory allocation you are describing is the stuff a 5 years old would write. Give me a break.
I tried as hard as I could to give facts, and then you just reply with a " Now when the program that originally had that memory tries to access that memory you have a problem" or a "so often after a crash, windows wont free up all the memory that it as using" which is so irrelevant (Because even if it happenned, and it does because of Shared Memory - not Windows fault, Linux has the same issues - then the pages that are left can be paginated because nobody accesses them) than it made me laugh.
Anyways, have agood night. And when you don't have anything else to say, don't say anything. It'a always better.
Well, since I installed my XP box 9 month ago, I haven't have to reboot for a windows update yet. For sure, it warns you that you may have to, but it doesn't. Except for the first time, just after installing the OS, where it spent 2 hours downloading all the cumulative patches after prompting for a reboot.
I must have a WU every other week, so that's a lot of them without any reboot.
Well, IIRC, the thread started saying that Firefox will have a hard time catching up with IE because a lot of pages are broken with FF because designed for IE.
Someone then ranted about that being IE's fault, and he was put back in his right place because irrelevant. The fact that it is IE's fault doesn't change the fact that a lot of website would not work with FF. And that makes the spread of Firefox a little more difficult.
Those percentages were just here to illustrate the fact that many webmaster rightfully (from a productivity standpoint) don't support FF, because it is less that 1% in their logs.
The fact that they prevent users from using their site with FF spoils these numbers is only relevant is you want to grant all these people a high IQ, good proffesionalism, great experience. We know better, but most of webmasters out there don't.
The fact remains, globally IE is dominant (more than 85%) and that is the reason for most websites to not work when browsed with FF. This slows down FF acceptance, but I don't think it'll stop it.
Sorry for being a little harsh in the grandparent, I guess I was a little drunk yesterday night...
ok, well I'm not talking about NULL pointers Me neither, I was just taking it as an example. If you write a program that allocate an array of 1000 ints and write 2000 ints in it, your program will crash, very similarly to a SIGSEGV. That's the window message that says "This program has performed an illegal operation and will be closed". It even can dump the core memory for you. In that regard, I don't see what you mean by "still not perfect". You *cannot* start two processes that would write (or read for that matter) in each other's memory. Unless they want to and then it's called shared memory. There is no major difference (apart from implementation I guess) in how Linux and Windows manage memory. Each process has it's allocated heap, and it deals with it.
I just flat out dont believe this Well, tell me one good technical reason why a process that would hog memory or CPU could leave residual stuff once it's killed. CPU is of course released. Memory is also released. One slight possibility is that the faulty process went mad on memory allocation and after you killed it, lots of stuff will be in the paging files and the disk caches would be empty. But that's just as true with Linux (If you're using pagefile), so you just wait for the other apps to "wake up" and everyhing is back to normal.
Just because microsoft realized they needed to add user seperation and networking support to their original kernel You didn't get your history right. Windows NT 3.51 is a brand new Kernel that didn't share one line of code with any previous one (MSDOS, Win1,2,3,95). It was written and lead by some members of the team that originally developped VMS. NT3.51 is a rock-solid OS that is very very similar to a unix system (apart from the utilities, shells, UI, etc...). It is almost not compatible at all with any version of Win9x, and certainly not at all with any Win31 stuff.
In WinNT4 and 2k, they gradually added support for multimedia in an attempt to eradicate Win9x. It took longer than they originally expected because of the huge crappiness of Win9x to be brought over and "made clean".
WinXP is the resulting OS from that migration, and I don't believe there will be a successor to WinME.
So all in all, the kernel in XP has very little to do with the kernel in Win9x.
So when you say "their original kernel", you diregard the fact that there are two different original kernels, and that WinXP's kernel is in no way an evolution of the "original kernel".
But Windows needs reboots for some things. It loses.
So can you download a new driver - for a new piece of hardware, name my digital camera - under linux and install it without rebooting? Windows does that.
The problem windows has is it has flat memory access, so one bad program is allowed to overwrite virtually any data on the system it wants, including any memory the operating system itself needs You know that is completely untrue, right? NULL pointers access kills the process under Windows as surely as it does under Linux. You can override memory that you allocated only, and shared memory of course.
If this was windows, I probally would have had to close the program, my system would have ran noticibally slower after that than before I had opened the program in the first place Why would the system run slower after you've closed the faulty program? Never happenned to me over almost 7 years of using NT (3.51, 4, 2k or XP).
If the process is killed, Windows will free all ressources used by it. Same as for any UNIX OS.
Both of the problems you are describing were applicable in Win3.1, and - to some extent only - in Win9x.
WinNT, 2k, XP are based on a kernel that is much closer to a UNIX kernel than MS-DOS (Which is what Win31&9x are based upon)
Slashdot Mirror
You just totally missed the point. I'm not saying that a $380 computer is as powerfull as an iMac. They're not competing on the same grounds.
But fact is that Apple is not competing on $380 computers, and have never shown an interest in doing so.
This low-level entry point exist only for PCs, and is certainly is a gateway for more expensive PCs. I mean, being a student and having $500 to put in a computer, I'm going to buy that one. It'll give me poor performances maybe, but I will learn and get my first computer experience on a PC. What do you think will be my next computer? Will I want to re-learn everything from scratch by changing platforms? Or will I go through the path of least resistance and just "upgrade" to a faster PC?
Thank you for illustrating my point. A computer for $299 Here and a monitor for $79.99 Here.
So if you have just $380 to put in a computer (think student here, his very first computer, the one that'll start molding his brain), then what could you possibly choose?
And keep in mind that outpost.com was the first website I tried. There _has_ to be less expensive. But we are already at less than 50% of the price of the lower Mac!!!!
While interesting and informative, it is also interesting to note one *huge* point that is left out in the article: The price. Mac have always been more expensive than PCs. Not that they are a lower value, but they are almost inexistent in the "entry-level" personal computer market. And they have always been.
Hence, the entry-level investment has always been higher for a Mac. You couldn't say "I'll buy this crappy one, and if I like it i'll upgrade later". Or simply speaking, if you had a thousand bucks to buy a machine, there was no alternative.
So if you deployed a Linux on 10000 machines on all your tech, marketing, IT, sales teams computers, and you had developped specific applications, drivers for some specific devices, and all the crap, you would just tell them: Sure, let's upgrate from 2.4 to 2.6 and cross your fingers?
The fact that they are cautious doesn't mean they distrust SP2. Like any major upgrage to a kernel (to any OS), it is going to break some of your specific devs, would it be only slightly.
This would be true for any OS. The fact that this one is Microsoft doesn't make it something against MS.
The funny thing is the last sentence of the story: "One IBM employee in the company's internal technology department characterized the decision as routine".
So a routine decision makes the front page of Slashdot, clearly advertized as "IBM doesn't trust Microsoft".
The basic anti MS movement is still out there.
No matter how much secrets are at stake, nobody should (And I don't think Seagate can) prevent anyone from working to sustain his/her family. Giving that the guy did work on HDD for the last 17 years, I guess it is safe to say that it will be hard for him to find another job in an unrelated field, at least a job at the same level he was at Seagate. Seagate should offer compensation for this 2 year period. Of course, I didn't RTFA, so maybe they do. In which case it is fine. But if they don't, they'll get laughed out of court. At least I hope.
So you would like all these equipments to be "home made" with a "home made" minimalistic OS. They would cost twice as much and your health coverage would probably bump up by 25%. And I'm sure you wouldn't like it.
There is a proper balance to find between "very cheap and crappy" and "100.0000% secure, properly tested bu 15x more expensive". Nothing is perfect, nor is software, nor is hardware, nor is nurses and doctors. My guess is that as long as death by software mistakes are much lower than (and so insignificants compared to) deaths by human mistake, nobody will care.
Mistakes are part of life. Of course, software mistake can be minimized, but at what cost? And is it worth it?
Hmmm. Yes. Everyone agrees on that one. Thanks.
Wow, you mean if the control computer crashes leaving the shutter to the Cobalt source open nobody could die? How about gamma knife overexposing the brain stem, cooking the brain stem couldn't possibly kill someone. How about a faulty homing cycle where the radiation head homes to the patient table, even if a patient is there.
And during all that time I guess the operator is just looking at it from behind the console, laughing his ass off of the patient getting his brain fried.
A software bug is very different from a crash of the system, a virus or a trojan.
The software bug will act as if everything was normal, but will command the radiation machine to do crazy things.
If the operator gets a BSOD, I hope he will shut down the radiation machine.
That was due to a bug in the software running the machine, not a trojan/virus/computer crash.
There is always an operator operating these machines, hence if the control machine (running win2k) was to go crazy, I hope the operator would shut down the actual radiation machine.
What you are describing is something else: The machine would act normally, but would deliver the wrong dosage.
These are different problems.
This is the most stupid example. A trojan would have to be specially targetted for *that* specific machine. Hence, if it was running any other OS, the possibility to write a trojan for that OS would also exist.
The irresponsibility if from the hospital to connect their machines to the internet. AFAIK, a properly tuned Windows system with stable drivers is as stable as any other system (at least for WinNT/2K/XP), as long as it is air-tight isolated from any external source, read: No fdd drive, no CDROM drive, no network access to any computer that is not in that situation.
Apart from that, Windows is as suited for this kind of application as any OS.
Very honestly, most of these machines couldn't "kill omeone". I mean, if the radiation therapy machine crashes, nobody dies.
There really are a few machines that would be highly critical, and I'm not sure those run UNIX or Windows.
Isn't the entire point (well, one of the many) of coding to standards that the page will degrade cleanly on lesser browsers?
That would work if the major browser was standard compliant. By doing what you suggest, you end up having a website that looks good for 4% of your audience and moderately crappy for 95% of them.
Way to go.
You should code to the Standards, not a browser
There are so many irrelevant standards out there, that if we had to use them all, we would just be dying.
You should not code to standards. You should code to your audience. If they happen to be massively using a browser that is standard compliant, then you may code to the standard in replacement of that. If they use different browsers for which the only common denominator is a standard, then you should code to the standard.
Alas, most of the users to any website don't fall into any of the above category.
So I guess I'll keep on coding to a browser(s). So that 94% of the people can read me.
Nice of you to provide te link, buyt a drop from 95.48 to 94.42% in market share is nowhere near what I call a "Mass migration" either.
The NT kernel did not originate from unix, it originated from OS/2 and even before that, VMS
Well, if you had read the article you just linked to, you would have found out that the NT kernel doesn't have anything to do with the OS/2 kernel. They just planned (plan which was later dropped) to support most of its APIs. NT is derived from VMS, not OS/2, and that's what I missasociated with UNIX in my previous post. Fact is, VMS is not too different from UNIX, but that's besides the point.
the initial idea of NT was to support for portions of the DOS, OS/2
The idea behind the NT kernel was certainly not to support DOS or OS/2. That might have been an early option, but was clearly dropped along the way. The idea was for microsoft to finally have a kernel. DOS is nowhere close to what I would call a kernel.
Memory allocation you are describing is the stuff a 5 years old would write.
This proves my point, the MS kernels don't keep good enough track of memory to avoid this problem
Well, that one is interesting? How my analogy with a bad programmer proves anything is just beyond me.
In my experience, BSOD in the NT kernel are due to two problems:
1. Bad drivers. Linux isn't exempt from problems in that area either. The BSOD is called a Kernel Panic.
2. A stupid architecture problem which lets any program override system dlls with "updated" ones. So let's say the foo.dll installed is v1.2 and a program needs foo.dll v1.3 to run, then the program will override the system dll (Yes, the program will override some of the code used by the kernel) with it's own version of the dll. Of course, when you deal with serious vendors, those dlls will have been properly tested. But when you deal with poor vendors, the side effect is that those poor vendors end up installing buggy dlls, making the kernel buggy along the way.
This was a huge issue until XP, which disallow this practice by keeping all versions of the dlls. So the kernel only uses the code that was written by MS.
The BSOD is just a materialization of a SIGSEGV sent to the kernel, nothing else, proving that the memory allocation works the way it should by killing processes that try to access memory in a segment they don't own.
This has nothing to do with a kernel that "don't keep good enough track of memory" (again, you serve me that vague sentence). Otherwise how would you explain my system being up since 4 month? Or my server being up since 2.5 years? How can that work with system that vaguely mistake system pages with program pages?
and I was just thinking that if that had of happened in windows, my system would still probally be all lagged
Well, I have never encountered that in almost 8 years of heavy NT usage. Maybe it's just me then.
ok, well I don't have time to argue every point you made so I'll just sum it up, and I call it bullshit.
WinNT kernel was made right our of a UNIX kernel. It was (The original one, WinNT 3.51) almost POSIX. Memory allocation you are describing is the stuff a 5 years old would write. Give me a break.
I tried as hard as I could to give facts, and then you just reply with a " Now when the program that originally had that memory tries to access that memory you have a problem" or a "so often after a crash, windows wont free up all the memory that it as using" which is so irrelevant (Because even if it happenned, and it does because of Shared Memory - not Windows fault, Linux has the same issues - then the pages that are left can be paginated because nobody accesses them) than it made me laugh.
Anyways, have agood night. And when you don't have anything else to say, don't say anything. It'a always better.
Well, since I installed my XP box 9 month ago, I haven't have to reboot for a windows update yet. For sure, it warns you that you may have to, but it doesn't. Except for the first time, just after installing the OS, where it spent 2 hours downloading all the cumulative patches after prompting for a reboot.
I must have a WU every other week, so that's a lot of them without any reboot.
Well, IIRC, the thread started saying that Firefox will have a hard time catching up with IE because a lot of pages are broken with FF because designed for IE.
Someone then ranted about that being IE's fault, and he was put back in his right place because irrelevant. The fact that it is IE's fault doesn't change the fact that a lot of website would not work with FF. And that makes the spread of Firefox a little more difficult.
Those percentages were just here to illustrate the fact that many webmaster rightfully (from a productivity standpoint) don't support FF, because it is less that 1% in their logs.
The fact that they prevent users from using their site with FF spoils these numbers is only relevant is you want to grant all these people a high IQ, good proffesionalism, great experience. We know better, but most of webmasters out there don't.
The fact remains, globally IE is dominant (more than 85%) and that is the reason for most websites to not work when browsed with FF. This slows down FF acceptance, but I don't think it'll stop it.
Sorry for being a little harsh in the grandparent, I guess I was a little drunk yesterday night...
ok, well I'm not talking about NULL pointers
Me neither, I was just taking it as an example. If you write a program that allocate an array of 1000 ints and write 2000 ints in it, your program will crash, very similarly to a SIGSEGV. That's the window message that says "This program has performed an illegal operation and will be closed". It even can dump the core memory for you. In that regard, I don't see what you mean by "still not perfect". You *cannot* start two processes that would write (or read for that matter) in each other's memory. Unless they want to and then it's called shared memory. There is no major difference (apart from implementation I guess) in how Linux and Windows manage memory. Each process has it's allocated heap, and it deals with it.
I just flat out dont believe this
Well, tell me one good technical reason why a process that would hog memory or CPU could leave residual stuff once it's killed. CPU is of course released. Memory is also released. One slight possibility is that the faulty process went mad on memory allocation and after you killed it, lots of stuff will be in the paging files and the disk caches would be empty. But that's just as true with Linux (If you're using pagefile), so you just wait for the other apps to "wake up" and everyhing is back to normal.
Just because microsoft realized they needed to add user seperation and networking support to their original kernel
You didn't get your history right. Windows NT 3.51 is a brand new Kernel that didn't share one line of code with any previous one (MSDOS, Win1,2,3,95). It was written and lead by some members of the team that originally developped VMS. NT3.51 is a rock-solid OS that is very very similar to a unix system (apart from the utilities, shells, UI, etc...). It is almost not compatible at all with any version of Win9x, and certainly not at all with any Win31 stuff.
In WinNT4 and 2k, they gradually added support for multimedia in an attempt to eradicate Win9x. It took longer than they originally expected because of the huge crappiness of Win9x to be brought over and "made clean".
WinXP is the resulting OS from that migration, and I don't believe there will be a successor to WinME.
So all in all, the kernel in XP has very little to do with the kernel in Win9x.
So when you say "their original kernel", you diregard the fact that there are two different original kernels, and that WinXP's kernel is in no way an evolution of the "original kernel".
But Windows needs reboots for some things. It loses.
So can you download a new driver - for a new piece of hardware, name my digital camera - under linux and install it without rebooting? Windows does that.
So I guess they're even.
The problem windows has is it has flat memory access, so one bad program is allowed to overwrite virtually any data on the system it wants, including any memory the operating system itself needs
You know that is completely untrue, right? NULL pointers access kills the process under Windows as surely as it does under Linux. You can override memory that you allocated only, and shared memory of course.
If this was windows, I probally would have had to close the program, my system would have ran noticibally slower after that than before I had opened the program in the first place
Why would the system run slower after you've closed the faulty program? Never happenned to me over almost 7 years of using NT (3.51, 4, 2k or XP).
If the process is killed, Windows will free all ressources used by it. Same as for any UNIX OS.
Both of the problems you are describing were applicable in Win3.1, and - to some extent only - in Win9x.
WinNT, 2k, XP are based on a kernel that is much closer to a UNIX kernel than MS-DOS (Which is what Win31&9x are based upon)
Of course, if IE is only 35% of your website's log, it _must_ mean it is 35% worldwide.
Thanks for your so great insight. I'm glad I didn't RTFA. So much bullshit sickens me.