And I do believe companies do want to provide real customer service, this whole phone system thing is merely herding clueless customers to designated areas [...]
Except (IME at least) it's completely pointless "herding". Typically, I find the first thing I have to do when I finally do get a person on the other end of the line, is just tell them the exact same things I've already "said".
It simply makes the already frustrating experience of dealing with an IVR even more so, when you have to repeat the exact same information you've just spent five minutes getting an IVR to understand, to the human you eventually end up talking to.
In what way(s) ? Be specific, and give examples of how/etc is better in that regard.
Having dealt with both, I'm still convinced the registry is seriously broken, compared to a bunch of files in/etc.
I can (and have, in this thread and others) reel of a list of definite and obvious ways/etc is broken. I can only think of a single good thing about it, and even that has nothing to do with the idea of/etc per se.
However, I'd be interested to hear why you think a system-wide, consistent, organised, transactional, auditable, finely permissioned central data repository is inferior to a mess of inconsistent, poorly organised monolithic text files with primitive access restrictions.
And the binary back end, while a serious problem, is only part of it.
What's the rest (it's also interesting how so few people typically get riled up about the "binary backend" of other databases) ?
At least it doesn't have a fucking registry - arguably _the_ _most_ _broken_ way of configuring a system.
The only (much overstated) weakness of the Registry is the binary file reliance on the backend. In every other way, it's a vastly superior concept than/etc.
The vast majority of scientists in America today are Christians, they believe in God and don't see any contradiction between studying the natural world and accepting that He created it. Why should they?
The complete lack of scientific evidence to support the premise that God even exists, let alone created the universe ?
Actually every Unix admin trying to remember the filenames (actively trying, not knowing from regular use) of config files is an idiot.
There is no distinction between "actively trying" and "just knowing".
Programs usually need a restart when you change their config file, I can't really remember any program that acts differently even though some programs offer an additional mechanism to re-read the config file without restarting by sending a SIGHUP to the program (usually daemons that need high-availability).
Most will reread with just a SIGHUP. Not all, though, and they don't all "reread" the same way (eg: some will only apply the changes to new instances, not existing ones).
Samba is an example of something that will automatically detect and apply changes without needing a restart or SUGHUP.
The problem, of course, is that the onus is on *you*, the user, to know which of these programs will behave in a certain fashion and be able to change your actions and expectations appropriately (bad UI), rather than just have a standard, defined, consistent set of procedures that will produce equivalent results (good UI).
I agree that the recursive option is specified differently and the same is true for the "do not look up hostnames and ports" option lots of programs use but apart from those few there really are no options all programs have in common.
Oh, come *on*.
* -f, -F can be "force", "file", "freshen"
* -v, -V can be "verbose", "version"
* -a can be "archive", "all"
This is completely off the top of my head without even thinking about it. There's *lots* more.
The inconsistency in config file syntax are actually a strength.
Only in the depths of sophistry could anyone consider pointless, labour-creating inconsistency a "strength".
For one it makes the effort to develop a program lower if you can use a format that is easy to parse in the program language of your choice (actually use the interpreter of your language to do the parsing e.g.).
Of course, if there were actually *standards* for things like the format/structure of files in/etc, your whole argument falls apart because there would be a standardised parser (like getopt for commandline switches) ported to every programming language unix has ever seen. "A format easier to parse in the language of your choice" would be meaningless because they could all do it.
The catastrophe of/etc is not in any way, shape or form a "strength". It's one redeeming feature is that files can (usually) be edited manually in case of disaster. The downside of this, is that the accepted and encouraged practice for making day to day changes to these files is manually doing so in a text editor or some text stream processing tool (which, while a somewhat understandable decision 30 years ago, is simply a broken concept today).
If all programs would have to use a fixed format you would have a system similar to xml, all files look the same but it doesn't make configuring programs any easier (and automatically changisng them would probably be more difficult).
Huh ? How on earth would a standard format and structure (and, even better, API) make automated changes *more difficult* ? Instead of having to remember which of the dozen different formats a file is in before you write that sed or perl one liner, you could just call a single, standard command that takes a handful of arguments to make an atomic change of a single value in the file. The same command and arguments that would be used to make a change in *any* file. How on Earth could that be considered *more* difficult ?
(Heck, with just a little bit of foresight and actual design (something distinctly lacking from unix) you could even have that tool check the input for semantics and correctness, reducing even more the likelihood of a typo rendering an entire system useless.)
I think they have been executing spectacularly since K7. That's K7, Opteron, and now AMD64, at a minimum.
There wasn't really anything outstanding about the K7. Relatively speaking, it was impressive because for the first time AMD actually had a strongly competitive chip on the market at the same time as intel, but it didn't have the superiority over the P3 (and then P4) that the Athlon64/Opteron does over the P4.
The Ahtlon64 and Opteron can't really be considered different CPUs, any more than a (current) Celeron and a P4 could be considered different. They're the same CPU, just packaged differently for different market segments.
One of the biggest problems with using AMD processors has always been lacklustre motherboard chipsets. This was less of a problem back in the Pentium/K5/K6 days, because you could just use an AMD CPU on a motherboard with a good intel chipset. However, since then the quality of supporting electronics for an AMD CPU has been - at *best* - a hit-and-miss affair. VIA has probably done more to set back the adoption of AMD processors than intel could ever dream of.
So, to recap my original point, the market is still deciding whether the Athlon64/Opteron was a fluke, and whether or not intel will be back in front in a couple of years after shaking off itanic. Also, to add another point, the biggest weakness in the AMD platform has always been its support electronics (ie: motherboards and their chipsets). This has *not* improved markedly, even with the K8 architecture. There is a large range of high quality, stable and fast chipsets to accompany intel CPUs across all market segments. The same cannot be said of AMD CPUs. Indeed, it's damn near impossible to find a decent mid-range Athlon64/Opteron motherboard - you either get 8xDIMM, 6 PCI-X slot, 2/4/8 CPU fire breathing monsters, or you get shitty low-end consumer boards with limited bus bandwidth (this was the problem I had a few months back replacing my server - I ended up getting a dual xeon motherboard because I couldn't find an AMD *anything* at even close to the same price that had 3+ PCI-X slots, multiple PCI[-X] buses and supported dual CPUs (or even a multicore single CPU)
In a sense it does matter now because we can't clock any faster because of basic physical constraints, [...]
This is not really true. Even enthusiasts have gotten P4s up around the 5Ghz mark with (stupidly) high-end cooling and overclocking.
What's happening is that the characteristics of high-clock speed CPUs (long pipelines, big stalls if something goes wrong) are reaching the point of diminishing returns for general purpose computing. In other words, they *could* crank the clock speed up more, but it wouldn't deliver a proportionate performance improvement in the general case.
Remember, there are still a few things a P4 can do faster than an Athlon64.
[...] so since AMD does more in each cycle they have more room to grow.
No, they don't, because their architecture hasn't been designed to allow easy clock speed ramping like the P4. The tradeoff of a higher IPC ("doing more per Mhz") is less ability to ramp clock speed. You're not likely to see any 4Ghz Opterons (or Pentium Ms, for that matter) in the near future.
Parent tells me that "a clock is a clock", implying that performance is only related to frequence, I point to him that both Athlon64 and Pentium-M far outperform Pentium 4 "clock for clock" (since they match P4's performances with much lower frequencies) and that clock therefore doesn't matter unless the chip architectures are strictly the same. Case closed.
I think his point was that both an AMD and an intel CPU get the job done and for most people, perform identically.
When you do, you'll see the problem is not that 'there are simply more people targeting ISS and Windows'. (If it was about market penetration, more folks would be trying to exploit Apache, since it has had, and continues to have, the largest installed web-server base.)
And if you bother to look, you'll find that recent versions of Apache have a worse security record than recent versions of IIS.
Of course, the example (Apache vs IIS) in itself is flawed because you're cherrypicking an irrelevant subset of the actual markets involved. Which section of the tiny proprtion of machines running webservers is larger pales into insignificance when compared to the number of machines running Windows.
It's like trying draw some sort of meaningful conclusion about which brand of tyre predicts which brand of car will have the most thefts.
Or, in other words, which webserver gets exploited is statistical noise when compared to the number of Windows machines out there. Even if every single Linux/Apache machine in the world was r00ted tomorrow, it still wouldn't make the slightest dent in Windows being on that greatest proportion of exploited computers.
The root of the matter is that the OS upon which IIS is based, and the codebase of IIS itself, are inherently more vulnerable because Microsoft's standards, practices, methodologies, and implementations are considerably more flawed.
Baseless FUD.
At the file-level, Microsoft's adoption of LDAP-based authentication in Active Directory (heavily modelled upon Novell's NDS, itself modeled upon Vines Streettalk model), has helped, but AD still sufferes from the fundammentally flawed subtractive rights (default allow) model, instead of the more sound additive right (default deny) model.
Are you suggesting that, without specific configuration to deny access appropriately, AD will allow access to anyone trying to access it ?
At the root of it, it's not that Microsoft can't address all of these issues.
The single biggest security hole in Windows - as with any system - is the end user. There's not a whole lot Microsoft can do to stop end users installing spyware on their machines, not running with low privileges and running poorly written software.
When Linux starts to have a user demographic and market share that are even *close* to Windows', then somewhat valid conclusions about the two re: security - based on the number and types of exploits - can be made. But not before.
[...] copy works by marking, paste by middle click, [...]
Unless you want to copy/paste something that isn't plain text. Or - incredible as it may seem - select something without wiping out the contents of the clipboard.
I fail to see the inconsistency you moan.
You have got to be fucking joking...
* Apps regularly use different - and -- switches to specify the same thing (-r vs -R for recursive) and/or the same option to specific different things (-f (or -F !) for "force" vs "file"). Some of them use -long options with the -short delimiter (eg: find, openssl).
* Naming conventions for files in/etc are inconsistent (is it named after the app ? The service ? Something apparently random but with Historical Significance ?).
* Formatting conventions for files in/etc are inconsistent (key = value pairs ? Broken into [sections] ? Is whitespace important ? Are tabs vs spaces relevant ? Is it a shell script or just text ?).
* Locations for files are inconsistent (/etc ?/etc/sysconfig ?/etc/program_name ?/etc/program_name.d ?/etc/completelyrandom ?/usr/lib/programname ?/var/somethingorother ?).
* Results are inconsistent (will the changes take effect immediately/automatically ? Will they need to be manually reread ? Will an app need to be completely restarted ? Will they apply immediately, but only to subsequent users ? Will everything crash and burn if there's an error in the config file or will it be smart enough to check first ?)
(Then of course, there's the obligatory spaghetti-bowl of symlinks scattered over the entire filesystem to exacerbate the situation).
In fact, just about every aspect of/etc - and unix in general - is inconsistent. It's a tragedy that a "good" unix admin is typically identified solely by his ability to remember thousands of individual nuances each application, config file and system has (and the most obvious sign of how immature and unprofessional the industry is).
With the exception of a handful of projects like KDE and GNOME, unix is the poster child for unintuitive, unpredictable, inconsistent, user-hostile UI. It stuns me anyone would even *try* to argue otherwise.
Then check out this one from some HP people who think they've got a workaround.
From what I understand any process (owned by any user) can execute arbitrary code as any other user on a desktop system as long as then can find a window owned as that user. They simply tell the administrator owned window to run a function at a particular memory address (by using a timer with a callback).
Basically. The moral of the story is that developers shouldn't write applications such that they have windows with elevated privileges "just running" on regular user's desktops.
Interesting. I wonder if/when exploits for this will appear in the wild.
They probably already exist, but since the attack requires a) a local logon and b) a window with elevated privileges, none of them are ever likely to be "popular".
Shatter is a flaw, but it's only really exposed by poorly written applications. In the grand scheme of things, it's pretty low risk.
Secure Windows development will always be an oxymoron until Microsoft fixes their OS so that Administrator privileges are not required to do the most mundane tasks.
[...] the main reason AMD doesn't sell well is crappy marketing [...]
No, the main reason is because *historically* (which is to say, looking at the last twenty-five years instead of the last three to five), intel has delivered better performance, better stability, better technology and been quicker to market with a more reliable supply.
AMD has yet to prove the Athlon64 is more than a fluke (which is not to say I think it is a fluke, but AMD fanbois have a penchant for pretending AMD can do no wrong).
As the name suggests, it was IBM who first started building standardised desktops and letting others in on the standards in question.
"Just because IBM were the first to start building standardised desktops and letting others in on the standards in question[0] doesn't mean they deserve credit for the PC revolution."
Look, Microsoft had a significant part to play in the ascendence of the PC. So did IBM. So did Compaq. Certainly, any other company that just happened to have the same products, at the same time and willing to treat them the same way might have taken us to the same end result we have today, but the fact is it was Microsoft, IBM and Compaq.
I fail to see why people insist on saying "yeah, well another company could have done what Microsoft did", as if that somehow changes the fact that it was Microsoft that did it (or, even sillier, that the computing world would have turned out substantially differently today if it was "someone else"). Microsoft were in the right place, at the right time, with the foresight to sieze the opportunity - and by doing so became one of the key reasons we have the computer market we do today. Get over it, already. If it had been WhizzyBangWare instead of Microsoft, Slashdot would be bitching just as much about WhizzyBangWare instead.
Microsoft's one innovation was their refusal to exclusively license the DOS variant they acquired to IBM, thus opening the way for OS standardisation. And yes, that was fairly handy, but (IMO) nowhere near as big a contributory factor as you're making out.
It was just as important as the PC itself, if not more so (IBM-compatible PCs were a complement to the success of DOS, whereas DOS was basically a necessity for the success of IBM-compatible PCs) . Without DOS, there wouldn't have been any market for "IBM compatible" PCs. Compaq wouldn't have made record-breaking amounts of money off their first product if the buyers hadn't had an OS to run their "IBM PC-DOS" applications on.
[0]This isn't really true. While IBM did make the PC out of off-the-shelf parts, they didn't want to license it to anyone. That's why Compaq had to go and clean-room reverse engineer the BIOS. Had IBM got what they wanted (and they tried again with the PS/2), the "IBM PC" would have been just another single-sourced microcomputer. If you seriously think IBM *deliberately* created the "IBM PC revolution", you're delusional - no company seeks to create a marketplace where competition is easy.
The tobacco industry got into trouble for a) deliberately engineering their products to be more addictive, b) lying about it and c) going to great lengths to buy/threaten/discredit anyone who tried to provide evidence of their products' danger.
Back in the day, smoking was promoted in advertising as *healthy* and *safe*.
That said, I can't see how anyone under the age of about twenty-five to thirty has a leg to stand on with regards to blaming the tobacco corporations for any ill-health they might suffer from smoking.
Before you go correcting someone, you really ought to know what it is your speaking about.
Indeed you should. In particular, your laymans description of the differences between "CISC" and "RISC" isn't particularly good.
Oh, and as another FYI, Intel used to make a RISC chip - the PentiumPro.
The Pentium Pro was not RISC. Just like the P2, P3 and P-M derivatives that have come since - and the P4, even though it was a completely new design - they were "CISC" x86 CPUs with a "RISCish" core (trivia: AMD were actually first to market - by a couple of months - with a "RISC core" x86 design they bought - the K5. Unfortunately every other aspect of it was pretty underwhelming).
(In fact, intel did design a RISC CPU - the i860 and it's successor the i960 (trivia: it was the first CPU Windows NT was developed for). These days about the only place you'll find one of them is on a RAID controller, however. Intel also makes other RISC CPUs - the ARM product line - even though they didn't design them.)
Truth is, that ever since the early 90s, this:
You have two basic types of CPU's in the world. RISC and CISC.
Hasn't really been true - at least not for mainstream computer CPUs. Both philosophies have been borrowing features from each other for a long time - CISC is getting "RISCy" and RISC is getting "CISCy" (as the other post said, just look at Altivec).
Also, while (AFAIK) that poster's definition of "Regular Instruction Set Computing" is not correct, it is probably a better one than "Reduced Instruction Set Computing", since the defining feature of RISC is more the "regularity" of its instruction set rather than any "restricted" aspect of it (again, looking at modern "RISC" CPUs that certainly don't have particularly "reduced" instruction sets).
Something I've always considered incredibly ironic is that the big promise of RISC - why it was the future of CPU design - was how easy it would be to crank up the clock speed with that architecture (as DEC did with the Alpha, back in the day), doing less per cycle. Yet that never eventuated and Apple has spent the last 5 - 7 years on their bogus "Mhz myth" advertising campaign saying the exact opposite about their "RISC CPUs".
That's why any linux distro that ships binary packages has many flavors of each important or performance sensitive package (specially the kernel, in Debian you'll find images optimised for 386, 586, 686, k6, k7, etc). Is one of the reasons of the existence of Gentoo, also.
Do you have any benchmarks that show CPU-specific compiler optimisations, for OS level code, give any meaningful general performance improvement ?
So MS had to make a choise: ship a binary optimized for every possible mix of hw (being the processor the most important factor, but not the only one), which is impossible, or ship images compatible with any recent x86 processor/hw... without being specially optimised for any. That's why hyperthreading performance suffers.
HT performance is an OS scheduler issue, it has nothing to do with "special" compilation optimisations.
Want to archive a DVD movie and put your favorite CD on your mp3 player? Set the two apps to run on different cores.
You really shouldn't mess around with (relatively) low level scheduling behaviour like this. The OS will schedule appropriately and is far more capable of responding to changing system load dynamically to maximise performance than you are.
Its no secret that windows is really bad at multiprocessing.
This sounds like typical anti-Microsoft FUD.
They only introduced multithreading post windows 93 where as these unix gurus have been doing it since the 1970's. At the moment that part of windows is really bad. With luck in the future there will be improvement
Right, because BeOS (that only "introduced multithreading" when it was first written in the early 90s) was renowned for being "really bad at multiprocessing". Clearly not having been around since the 70s was a major problem for them.
Windows NT was built from the start to be heavily multithreaded and work well in multiprocessing environments. It was designed by the same people who built VMS. You'd think they might have a rough idea of how to handle "multiprocessing" reasonably well.
Slashdot Mirror
Except (IME at least) it's completely pointless "herding". Typically, I find the first thing I have to do when I finally do get a person on the other end of the line, is just tell them the exact same things I've already "said".
It simply makes the already frustrating experience of dealing with an IVR even more so, when you have to repeat the exact same information you've just spent five minutes getting an IVR to understand, to the human you eventually end up talking to.
In what way(s) ? Be specific, and give examples of how /etc is better in that regard.
Having dealt with both, I'm still convinced the registry is seriously broken, compared to a bunch of files in /etc.
I can (and have, in this thread and others) reel of a list of definite and obvious ways /etc is broken. I can only think of a single good thing about it, and even that has nothing to do with the idea of /etc per se.
However, I'd be interested to hear why you think a system-wide, consistent, organised, transactional, auditable, finely permissioned central data repository is inferior to a mess of inconsistent, poorly organised monolithic text files with primitive access restrictions.
And the binary back end, while a serious problem, is only part of it.
What's the rest (it's also interesting how so few people typically get riled up about the "binary backend" of other databases) ?
The only (much overstated) weakness of the Registry is the binary file reliance on the backend. In every other way, it's a vastly superior concept than /etc.
The complete lack of scientific evidence to support the premise that God even exists, let alone created the universe ?
There is no distinction between "actively trying" and "just knowing".
Programs usually need a restart when you change their config file, I can't really remember any program that acts differently even though some programs offer an additional mechanism to re-read the config file without restarting by sending a SIGHUP to the program (usually daemons that need high-availability).
Most will reread with just a SIGHUP. Not all, though, and they don't all "reread" the same way (eg: some will only apply the changes to new instances, not existing ones).
Samba is an example of something that will automatically detect and apply changes without needing a restart or SUGHUP.
The problem, of course, is that the onus is on *you*, the user, to know which of these programs will behave in a certain fashion and be able to change your actions and expectations appropriately (bad UI), rather than just have a standard, defined, consistent set of procedures that will produce equivalent results (good UI).
I agree that the recursive option is specified differently and the same is true for the "do not look up hostnames and ports" option lots of programs use but apart from those few there really are no options all programs have in common.
Oh, come *on*.
* -f, -F can be "force", "file", "freshen"
* -v, -V can be "verbose", "version"
* -a can be "archive", "all"
This is completely off the top of my head without even thinking about it. There's *lots* more.
The inconsistency in config file syntax are actually a strength.
Only in the depths of sophistry could anyone consider pointless, labour-creating inconsistency a "strength".
For one it makes the effort to develop a program lower if you can use a format that is easy to parse in the program language of your choice (actually use the interpreter of your language to do the parsing e.g.).
Of course, if there were actually *standards* for things like the format/structure of files in /etc, your whole argument falls apart because there would be a standardised parser (like getopt for commandline switches) ported to every programming language unix has ever seen. "A format easier to parse in the language of your choice" would be meaningless because they could all do it.
The catastrophe of /etc is not in any way, shape or form a "strength". It's one redeeming feature is that files can (usually) be edited manually in case of disaster. The downside of this, is that the accepted and encouraged practice for making day to day changes to these files is manually doing so in a text editor or some text stream processing tool (which, while a somewhat understandable decision 30 years ago, is simply a broken concept today).
If all programs would have to use a fixed format you would have a system similar to xml, all files look the same but it doesn't make configuring programs any easier (and automatically changisng them would probably be more difficult).
Huh ? How on earth would a standard format and structure (and, even better, API) make automated changes *more difficult* ? Instead of having to remember which of the dozen different formats a file is in before you write that sed or perl one liner, you could just call a single, standard command that takes a handful of arguments to make an atomic change of a single value in the file. The same command and arguments that would be used to make a change in *any* file. How on Earth could that be considered *more* difficult ?
(Heck, with just a little bit of foresight and actual design (something distinctly lacking from unix) you could even have that tool check the input for semantics and correctness, reducing even more the likelihood of a typo rendering an entire system useless.)
Sure, internally they are consistent but th
There wasn't really anything outstanding about the K7. Relatively speaking, it was impressive because for the first time AMD actually had a strongly competitive chip on the market at the same time as intel, but it didn't have the superiority over the P3 (and then P4) that the Athlon64/Opteron does over the P4.
The Ahtlon64 and Opteron can't really be considered different CPUs, any more than a (current) Celeron and a P4 could be considered different. They're the same CPU, just packaged differently for different market segments.
One of the biggest problems with using AMD processors has always been lacklustre motherboard chipsets. This was less of a problem back in the Pentium/K5/K6 days, because you could just use an AMD CPU on a motherboard with a good intel chipset. However, since then the quality of supporting electronics for an AMD CPU has been - at *best* - a hit-and-miss affair. VIA has probably done more to set back the adoption of AMD processors than intel could ever dream of.
So, to recap my original point, the market is still deciding whether the Athlon64/Opteron was a fluke, and whether or not intel will be back in front in a couple of years after shaking off itanic. Also, to add another point, the biggest weakness in the AMD platform has always been its support electronics (ie: motherboards and their chipsets). This has *not* improved markedly, even with the K8 architecture. There is a large range of high quality, stable and fast chipsets to accompany intel CPUs across all market segments. The same cannot be said of AMD CPUs. Indeed, it's damn near impossible to find a decent mid-range Athlon64/Opteron motherboard - you either get 8xDIMM, 6 PCI-X slot, 2/4/8 CPU fire breathing monsters, or you get shitty low-end consumer boards with limited bus bandwidth (this was the problem I had a few months back replacing my server - I ended up getting a dual xeon motherboard because I couldn't find an AMD *anything* at even close to the same price that had 3+ PCI-X slots, multiple PCI[-X] buses and supported dual CPUs (or even a multicore single CPU)
This is not really true. Even enthusiasts have gotten P4s up around the 5Ghz mark with (stupidly) high-end cooling and overclocking.
What's happening is that the characteristics of high-clock speed CPUs (long pipelines, big stalls if something goes wrong) are reaching the point of diminishing returns for general purpose computing. In other words, they *could* crank the clock speed up more, but it wouldn't deliver a proportionate performance improvement in the general case.
Remember, there are still a few things a P4 can do faster than an Athlon64.
[...] so since AMD does more in each cycle they have more room to grow.
No, they don't, because their architecture hasn't been designed to allow easy clock speed ramping like the P4. The tradeoff of a higher IPC ("doing more per Mhz") is less ability to ramp clock speed. You're not likely to see any 4Ghz Opterons (or Pentium Ms, for that matter) in the near future.
I think his point was that both an AMD and an intel CPU get the job done and for most people, perform identically.
And if you bother to look, you'll find that recent versions of Apache have a worse security record than recent versions of IIS.
Of course, the example (Apache vs IIS) in itself is flawed because you're cherrypicking an irrelevant subset of the actual markets involved. Which section of the tiny proprtion of machines running webservers is larger pales into insignificance when compared to the number of machines running Windows.
It's like trying draw some sort of meaningful conclusion about which brand of tyre predicts which brand of car will have the most thefts.
Or, in other words, which webserver gets exploited is statistical noise when compared to the number of Windows machines out there. Even if every single Linux/Apache machine in the world was r00ted tomorrow, it still wouldn't make the slightest dent in Windows being on that greatest proportion of exploited computers.
The root of the matter is that the OS upon which IIS is based, and the codebase of IIS itself, are inherently more vulnerable because Microsoft's standards, practices, methodologies, and implementations are considerably more flawed.
Baseless FUD.
At the file-level, Microsoft's adoption of LDAP-based authentication in Active Directory (heavily modelled upon Novell's NDS, itself modeled upon Vines Streettalk model), has helped, but AD still sufferes from the fundammentally flawed subtractive rights (default allow) model, instead of the more sound additive right (default deny) model.
Are you suggesting that, without specific configuration to deny access appropriately, AD will allow access to anyone trying to access it ?
At the root of it, it's not that Microsoft can't address all of these issues.
The single biggest security hole in Windows - as with any system - is the end user. There's not a whole lot Microsoft can do to stop end users installing spyware on their machines, not running with low privileges and running poorly written software.
When Linux starts to have a user demographic and market share that are even *close* to Windows', then somewhat valid conclusions about the two re: security - based on the number and types of exploits - can be made. But not before.
Unless you want to copy/paste something that isn't plain text. Or - incredible as it may seem - select something without wiping out the contents of the clipboard.
I fail to see the inconsistency you moan.
You have got to be fucking joking...
* Apps regularly use different - and -- switches to specify the same thing (-r vs -R for recursive) and/or the same option to specific different things (-f (or -F !) for "force" vs "file"). Some of them use -long options with the -short delimiter (eg: find, openssl).
* Naming conventions for files in /etc are inconsistent (is it named after the app ? The service ? Something apparently random but with Historical Significance ?).
* Formatting conventions for files in /etc are inconsistent (key = value pairs ? Broken into [sections] ? Is whitespace important ? Are tabs vs spaces relevant ? Is it a shell script or just text ?).
* Locations for files are inconsistent (/etc ? /etc/sysconfig ? /etc/program_name ? /etc/program_name.d ? /etc/completelyrandom ? /usr/lib/programname ? /var/somethingorother ?).
* Results are inconsistent (will the changes take effect immediately/automatically ? Will they need to be manually reread ? Will an app need to be completely restarted ? Will they apply immediately, but only to subsequent users ? Will everything crash and burn if there's an error in the config file or will it be smart enough to check first ?)
(Then of course, there's the obligatory spaghetti-bowl of symlinks scattered over the entire filesystem to exacerbate the situation).
In fact, just about every aspect of /etc - and unix in general - is inconsistent. It's a tragedy that a "good" unix admin is typically identified solely by his ability to remember thousands of individual nuances each application, config file and system has (and the most obvious sign of how immature and unprofessional the industry is).
With the exception of a handful of projects like KDE and GNOME, unix is the poster child for unintuitive, unpredictable, inconsistent, user-hostile UI. It stuns me anyone would even *try* to argue otherwise.
In the same way Linux is an unbelievably shitty OS peddled by a bunch of GNU/hippies ?
Take a look at this paper on shatter attacks.
Then check out this one from some HP people who think they've got a workaround.
From what I understand any process (owned by any user) can execute arbitrary code as any other user on a desktop system as long as then can find a window owned as that user. They simply tell the administrator owned window to run a function at a particular memory address (by using a timer with a callback).
Basically. The moral of the story is that developers shouldn't write applications such that they have windows with elevated privileges "just running" on regular user's desktops.
Interesting. I wonder if/when exploits for this will appear in the wild.
They probably already exist, but since the attack requires a) a local logon and b) a window with elevated privileges, none of them are ever likely to be "popular".
Shatter is a flaw, but it's only really exposed by poorly written applications. In the grand scheme of things, it's pretty low risk.
Like what ?
Which is undoubtedly why you kep stressing how much better the Athlon was on a "per Mhz" basis...
Which explains why OpenOffice is maybe on par Microsoft Office *97*, right ?
No, the main reason is because *historically* (which is to say, looking at the last twenty-five years instead of the last three to five), intel has delivered better performance, better stability, better technology and been quicker to market with a more reliable supply.
AMD has yet to prove the Athlon64 is more than a fluke (which is not to say I think it is a fluke, but AMD fanbois have a penchant for pretending AMD can do no wrong).
People who insist on measuring "clock for clock" are just as stupid (possibly even more so) as those who say "higher clock speed -> faster".
"Just because IBM were the first to start building standardised desktops and letting others in on the standards in question[0] doesn't mean they deserve credit for the PC revolution."
Look, Microsoft had a significant part to play in the ascendence of the PC. So did IBM. So did Compaq. Certainly, any other company that just happened to have the same products, at the same time and willing to treat them the same way might have taken us to the same end result we have today, but the fact is it was Microsoft, IBM and Compaq.
I fail to see why people insist on saying "yeah, well another company could have done what Microsoft did", as if that somehow changes the fact that it was Microsoft that did it (or, even sillier, that the computing world would have turned out substantially differently today if it was "someone else"). Microsoft were in the right place, at the right time, with the foresight to sieze the opportunity - and by doing so became one of the key reasons we have the computer market we do today. Get over it, already. If it had been WhizzyBangWare instead of Microsoft, Slashdot would be bitching just as much about WhizzyBangWare instead.
Microsoft's one innovation was their refusal to exclusively license the DOS variant they acquired to IBM, thus opening the way for OS standardisation. And yes, that was fairly handy, but (IMO) nowhere near as big a contributory factor as you're making out.
It was just as important as the PC itself, if not more so (IBM-compatible PCs were a complement to the success of DOS, whereas DOS was basically a necessity for the success of IBM-compatible PCs) . Without DOS, there wouldn't have been any market for "IBM compatible" PCs. Compaq wouldn't have made record-breaking amounts of money off their first product if the buyers hadn't had an OS to run their "IBM PC-DOS" applications on.
[0]This isn't really true. While IBM did make the PC out of off-the-shelf parts, they didn't want to license it to anyone. That's why Compaq had to go and clean-room reverse engineer the BIOS. Had IBM got what they wanted (and they tried again with the PS/2), the "IBM PC" would have been just another single-sourced microcomputer. If you seriously think IBM *deliberately* created the "IBM PC revolution", you're delusional - no company seeks to create a marketplace where competition is easy.
Not nearly as lucky as an 18 year old bloke would be to get a 35 year old woman.
The tobacco industry got into trouble for a) deliberately engineering their products to be more addictive, b) lying about it and c) going to great lengths to buy/threaten/discredit anyone who tried to provide evidence of their products' danger.
Back in the day, smoking was promoted in advertising as *healthy* and *safe*.
That said, I can't see how anyone under the age of about twenty-five to thirty has a leg to stand on with regards to blaming the tobacco corporations for any ill-health they might suffer from smoking.
Before you go correcting someone, you really ought to know what it is your speaking about.
Indeed you should. In particular, your laymans description of the differences between "CISC" and "RISC" isn't particularly good.
Oh, and as another FYI, Intel used to make a RISC chip - the PentiumPro.
The Pentium Pro was not RISC. Just like the P2, P3 and P-M derivatives that have come since - and the P4, even though it was a completely new design - they were "CISC" x86 CPUs with a "RISCish" core (trivia: AMD were actually first to market - by a couple of months - with a "RISC core" x86 design they bought - the K5. Unfortunately every other aspect of it was pretty underwhelming).
(In fact, intel did design a RISC CPU - the i860 and it's successor the i960 (trivia: it was the first CPU Windows NT was developed for). These days about the only place you'll find one of them is on a RAID controller, however. Intel also makes other RISC CPUs - the ARM product line - even though they didn't design them.)
Truth is, that ever since the early 90s, this:
You have two basic types of CPU's in the world. RISC and CISC.
Hasn't really been true - at least not for mainstream computer CPUs. Both philosophies have been borrowing features from each other for a long time - CISC is getting "RISCy" and RISC is getting "CISCy" (as the other post said, just look at Altivec).
Also, while (AFAIK) that poster's definition of "Regular Instruction Set Computing" is not correct, it is probably a better one than "Reduced Instruction Set Computing", since the defining feature of RISC is more the "regularity" of its instruction set rather than any "restricted" aspect of it (again, looking at modern "RISC" CPUs that certainly don't have particularly "reduced" instruction sets).
Something I've always considered incredibly ironic is that the big promise of RISC - why it was the future of CPU design - was how easy it would be to crank up the clock speed with that architecture (as DEC did with the Alpha, back in the day), doing less per cycle. Yet that never eventuated and Apple has spent the last 5 - 7 years on their bogus "Mhz myth" advertising campaign saying the exact opposite about their "RISC CPUs".
Do you have any benchmarks that show CPU-specific compiler optimisations, for OS level code, give any meaningful general performance improvement ?
So MS had to make a choise: ship a binary optimized for every possible mix of hw (being the processor the most important factor, but not the only one), which is impossible, or ship images compatible with any recent x86 processor/hw... without being specially optimised for any. That's why hyperthreading performance suffers.
HT performance is an OS scheduler issue, it has nothing to do with "special" compilation optimisations.
AFAIK the Athlon [MP] didn't have "independent CPU busses".
You really shouldn't mess around with (relatively) low level scheduling behaviour like this. The OS will schedule appropriately and is far more capable of responding to changing system load dynamically to maximise performance than you are.
Its no secret that windows is really bad at multiprocessing.
This sounds like typical anti-Microsoft FUD.
They only introduced multithreading post windows 93 where as these unix gurus have been doing it since the 1970's. At the moment that part of windows is really bad. With luck in the future there will be improvement
Right, because BeOS (that only "introduced multithreading" when it was first written in the early 90s) was renowned for being "really bad at multiprocessing". Clearly not having been around since the 70s was a major problem for them.
Windows NT was built from the start to be heavily multithreaded and work well in multiprocessing environments. It was designed by the same people who built VMS. You'd think they might have a rough idea of how to handle "multiprocessing" reasonably well.