DEC settling doesn't mean that it was legal, anymore than paying for someone's fender and their medical bills makes it legal to smash into their car.
No, but it makes all the subsequent work legal. In other words, all of the development that was done at Microsoft on Windows NT.
You may well believe that everything of any importance in Windows NT was actually code written while Cutler was still at DEC - in which case I doubt I *could* ever convince you otherwise, even with sworn testimony from DEC itself.
The idea that settling means it wasn't theft is very strange, indeed.
So is the idea that copyright and patent infringment is "theft".
And no, I meant the Pentium IV for lots of technical theft by Intel There are allegations of theft for previous technologies such as the Pentium II, due toe DEC's previous policies of being relatively open about its designs in non-disclosure agreeement based meetings.
DEC and Intel settled each others lawsuits (interesting how DEC aren't "thieves", despite intel suing them for patent infringement as well) back around 1998 and came up with a ten-year cross-licensing agreement. I doubt there's any DEC technology intel would _need_ to "steal", because they already had access to it through their existing agreement.
I'm cherry picking examples that are some of the most famous and egregious, leading most directly to DEC's demise.
The mind boggles at how you could consider Windows NT having much to do with it. It's not like it actually competed in the same market space as VMS.
And stop pretending this has anything to do with misuse by open-source developers. That's serious FUD: The GPL and many other open source copyrights are carefully written to avoid this sort of abuse and others.
Right. So it's a legal arrangement like one of those "non-compete" contracts. I guess that means no-one could ever violate it.
If you violate that agreement, as a developer, you can and will have your code ripped out screaming by the roots when the FSF or other open source bodies notice it, and people like the Samba developers and Linux kernel developers have repeatedly shown exactly what lengths they go to to avoid that kind of problem.
Right. So it's like the whole lawsuit/damages thing that happens in the commercial world. But I imagine you think ripping out/rewriting the code is "OK".
1. As far as "more abstracted".. It has nothing to do with the GUI, it has to do with the fact that many aspects of Windows are "off limits". I have the full source to my *nix machines and basic introductory text tend to fully explain how the entire system functions. This empowers me as an adminsitrator to quickly diagnose and correct issues. Windows troubleshooting tends to be largely curing symptoms of issues due to the fact that core problems are less easily uncovered (such as a bug in an application, I have no way to personally go in and analyze the code or have tools at my disposal to easily debug an application to find the root cause.. generaly this requires support calls and waiting around for a solution).
While you certainly don't get the Windows source as a matter of course, the documentation - if you can be bothered to look (and, I'll agree, most cannot) - is quite comprehensive. I think your comment regarding "abstraction" is misguided, because I don't know any other unix admins who consider looking at the source code to their OS as a normal part of their system maintenance. I know *I* certainly wouldn't and would consider even the suggestion that it be considered "normal" or "recommended" to be a serious flaw in the platform. Most unix users - even admins - are using "user friendly" (for unix) tools that are really no different to the GUI tools in Windows. Just 'cause you type it and don't click on it, doesn't mean you're running any closer to the bare metal;).
2. There is more commonality in different variations of *nix than differnet releases of Windows (Windows 3.x vs Windows Vista for example).
This comparison is ridiculous. Even ignoring that Windows 3.1 is ca. 1991 and Vista will be ca. 2007, they are *completely* different OSes. It's impressive they have anything in common at all.
While commands may different, underlying philosophies are largely the same and while it does take some time to become acquanted with a different variety of *nix, a large set of core knowledge about the system is applicable from one to the next (ie hopping between FreeBSD and RedHat or Solaris).
This is silly. There are a similar set of "philosophies" - if you can call them that - that flow through the various versions of Windows as well. Menus, GUI concepts (eg: Control Panel), etc. Sure, the exact implementations differ between the different releases, but the basic principles are all the same (with the concession of measuring from the introduction of Windows 9x, not 3.x).
3. I'll agree with Linux being a patchwork...
It's not just Linux (although it is, by far, the worst offender). The whole unix community is *full* of "solutions" that are ugly messes of hacked together, poorly documented components that only barely work well together, mostly due to luck and brute-force coding, rather than specification and design.
For example, this morning I spent several hours trying to do rolling "upgrades" of some of our ha-linux clusters. It took several hours because I discovered what appeared to be incompatibilities between various minor revisions of the heartbeat software and also problems compiling more recent versions of it on some machines. The documentation wasn't particularly help and neither were the mailing list archives (for a change).
Now, I'll be the first to admit I was being a bit cowboyish by not duplicating the existing infrastructure onto dev servers and simulating the upgrade process first, but it was a minor point update, for gawd's sake...
What *really* magnifies my frustration factor is that the Open Source world is *rife* with these sorts of "solutions" that regularly takes processes touted as quick, easy and painless (as they should be) and turns them into day-long marathons involving mailing list searches, CVS code patches (or, even better, the "mailing list post patch"), specific compiler versions and dependency hell.
More modern drives (250GB+) can sustain 20-25MB/s as long as only one application is touching the spindle (extraneous seeks will usually trash ATA drive performance). Some of the larger 500GB drives are closer to 30-35MB/s for SATA/PATA. I've even seen peaks of 40MB/s when pulling from one spindle and writing to another (40MB/s read and 40MB/s write).
Your numbers sound very low. A newish (160G+, 8M+ cache) 7200RPM SATA drive should be able to sustain 40 - 70M/s (depending on the part of the disk) for streaming reads and writes (ie: dd if=/dev/zero of=/dev/sda kind of thing).
RAID a few of them together and - particularly on the typical PC - you'll probably run out of bus bandwidth before you run out of physical disk speed.
Crikey, even the ~4 year old 40G PATA drive I use for the OS on my fileserver can sustain 40M/s for streaming reads and writes - and that's through a filesystem.
Generally, you want to set up a RAID 1 logical drive for the OS and either RAID 1, 1+0 or 5 logical drives for the various I/O-bound applications running on the system. RAID 1 or 1+0 is typically faster than RAID 5 while RAID 5 offers more usable disk space.
Multiple logical drives over the same physical disks - especially at different RAID levels - usually hurt performance because of the different access patterns to the drives and the way OSes try to optimise the order of (physical) disk operations.
This is not to say that such configurations should never be used, but you should be aware that doing so will probably hurt performance.
Yeah, for all but RAID5. That you need a real controller for. Onboard will suck up way too much CPU.
I don't know why the meme that software (or pseudo-hardware) RAID5 "sucks up" CPU cycles continues to propogate.
A 300Mhz Pentium 2 has a RAID5 checksumming speed (in Linux) of about 800M/s. So at the more realistic speeds of 50 - 75M/s your average PC's RAID5 array can write at before the bus and physical drives hit their limits and on any remotely modern CPU, the processing overhead of checksumming is insignificant.
There *are* valid reasons why a hardwar RAID controller should be faster[0] - particularly for large arrays and/or the typical, bus-starved PC, but they have nothing to do with the "CPU overheads" of RAID5, nor even the "intelligent caching" some cards boast about.
[0]And even though they *should* be faster, they frequently aren't.
It's not just the knowledge, much of which was trade secrets illegal to use elsewhere. It's copyrighted code. You really need to look at the lawsuits, David Cutler and his merry band of pirates stole not just general concepts but wholesale chunks of code. For example, take a good look at the memory management code, if you can get appropriate developer licenses and access to old VMS source code. They signed contracts that forbade exactly this: they took the money and Microsoft and ignored the contracts.
Somehow I think Windows NT had just a little bit more work done to it before it was released. You talk like Windows NT was a copy of the VMS codebase someone had done a quick search and replace through. You and I both know that isn't true.
The rumours say Cutler brought some code with him. DEC sued. DEC settled. After that point, it's irrelevant, because it's _legal_, and can no longer be called "theft". You may not like that they settled for $X. You may think $X was far too low a sum. But it doesn't matter, and you can't say any further "thefts" happened, because after that point they were "purchases".
DEC settled for what turned out to be a pittance their policy was to avoid painful and possibly expensive lawsuits, and they thought they could milk the cow of the NT marketplace by selling Alphas that ran NT. This coupled with the theft of Alpha technologies for the Pentium IV chips by Intel, basically destroyed DEC's highly coupled cash cows by removing much of their competitive advantage and selling cheaper, flakier versions of the technologies for far less money because they could steal them wholesale, rather than having to develop them from scratch.
I think you mean Pentium Pro, not Pentium 4. Not to mention intel sued DEC very soon after for patent infringement as well (which makes DEC "thieves", too). Some time in 1998 (IIRC), they all came to a nice agreement involving large sums of money and technology cross-licensing agreements.
You are cherry picking examples to suit your biases. I'm pretty sure every major technology company has either been targeted by - or made - accusations of patent infringement and other forms of "intellectual property" "theft". Do not try and pretend Microsoft and Intel are the only ones this has happened to.
Talk to old DEC employees of the period: ones who know enough about the details curse the days that DEC settled out of court with both Microsoft and Intel, rather than flensing them to the fiscal bone for their wholesale theft. After that sort of disaster, and that sort of wholesale theft of your work by crooks who get rich stealing it, you're not inclined to stick around and make more good products: a lot of folks left for that kind of reason, and the loss of talented engineers was very detrimental to the company.
Yes, well, the whole thing is really nothing more than hearsay, rumor and speculation. So filling in the blanks can take the "real" story whichever way you want it to.
And don't pretend that OSS written on spare time has the same issues: [...]
But it does, unless you think there's something different about OSS developers to everyone else.
Computing is one of those fields where advancement progresses identically in independent places. As I believe several fairly smart people have said, it'd be damn near impossible to do anything worthwhile these days without violting *someone's* patent.
(This whole discussion is, IMHO, a shining example of why "intellectual property" is a broken concept.)
Sure, for performance reasons it may be advantageous to let a driver have free access to the hardware. But I don't see any logical reason why it has to be that way...
You have answered your own question. The answer is: performance.
Hey if the company who made the OS does not release the source code so the driver company can build a proper driver then the blame falls back to the OS maker.
The driver company doesn't need the source code to the OS to "build a proper driver". Indeed, it's far more likely to end up with a *worse* driver that depends on undocumented features and/or breaks with every minor OS revision if they *do* have the source code.
The drivers are being certified by Microsoft. It is not unreasonable to think that it is Microsoft's responsibility to test and debug third party drivers that Microsoft certifies.
Microsoft can justifiably be expected to certify that a) the driver acts as they are told it should (eg: supports features X, Y and Z, but not P and Q) and b) the driver conforms to the documented specs of their API (ie: isn't making any calls to undocumented functions).
They can not be expected to certify driver stability on arbitrary combinations of hardware and software.
They can not be held responsbile for a driver that behaves differently during the certification process than it does on a user's system.
By being paid by DEC for it and signing a non-compete agreement. He also hired away much of his merry old crew, who participated in the non-compete, trade secret, and copyright violations: [...]
The very idea that you cannot use knowledge gained from prior experiences in your current (and future) job seems... asinine, to say the least. It's difficult to see how such "non-compete agreements" even pass the laugh test, let alone be considered enforcable.
Somehow I think Cutler and his team put in just a little bit more work once they'd moved to Microsoft, than they may have already done.
One wonders if you feel similarly towards OSS programmers who are (by your logic) "stealing" from their employers when they write code in their spare time...
[...] DEC settled out of court for way, way too little money and the promise that NT would always run on Alphas.
Clearly they thought they were getting a reasonable deal, otherwise they wouldn't have agreed to it.
More interesting is whether Vista will be capable of cluster computing: AS the legacies of DOS have fallen out of Microsoft support, and its core more moved towards the NT built by David Cutler with his stolen work from DEC's VMS, it's actually become more of a seriously powerful OS and could conceivably be up to the task.
So what is it? Is it always changing (release to release) or is it not? Seems like you want it both ways.
Please don't be asinine and disingenuous. Those two comments were referring to two different aspects of the OS, and you know it.
I think a big difference is with *nix, administrative tasks tend to happen much closer to the core than in Windows which seems much more abstracted.
You seem to be mistaking "GUI" for "more abstracted". A GUI is no more abstracted than a CLI (well, not in principle anyway - the proclivity of Linux developers for writing GUI wrappers around CLI tools might make some think otherwise).
Its this abstraction that tends to change frequently in Windows.
I assume you're talking about UI. The UI in Windows - particularly on the server side - has not changed markedly since Windows 2000. Certainly there is far more variance between different Linux distributions than there is between different versions of Windows. Start going across unixes and the differences pile up even more.
Just because you can run 'vi somefile' on every unix, doesn't mean adminning them is the same. Plonk someone who has never used anything except RHEL in front of a SCO Openserver machine, for example, and they'll be in for a world of hurt.
The fact that this continues to change and depreciates old methods of accomplishing tasks is generally indicitive of a lower quality
On the contrary, it's indicative of *ever improving* quality.
Just because you do everything in unix by editing text files and have been able to pretty much forever, does not make that method better. Indeed, hand-editing text files is an *atrocious* form of systems management, that sucks in just about every way imaginable. That this is still a commonly accepted method of managing unix machines is a sign of close-minded stagnation, not "higher quality".
Perhaps the technology leaders have had more impact on the modern world than you give credit.
The problem with your alternatives is that they are not conducive to the incredibly rapid growth the "PC" market underwent. In a highly diverse environment, creating and maintaining interoperability, in particular, both slows growth and limits opportunities for new, innovative ideas (so does having a monoculture - as always, the best solution is somewhere in the middle).
find that last part of your comment very interesting. I do agree that Microsoft does have perhaps some of the most brilliant people in the industry working for them. What are these constraints you are referring to? The marketing side of Microsoft? The structured, business centric management style (versus the free flowing, creative style of innovative technical companies)? The constraints of building software to satisfy both short-term and long-term shareholder wealth? I tend to believe that super technical solutions and feature complete designs do not bode well for long-term shareholder wealth.
I was referring mainly to technical constraints - although these are, at a very high level, dictated by the other requirements you mention. Legacy support is, of course, the obvious one.
Again, without an idea of what you consider "technology driven companies", it's difficult to have a discussion about it.
Are we referring to desktop Linux or Windows??
I was referring to Windows, but it applies equally to modern-day Linux distributions.
I'll agree, the Linux core is quite solid.. perhaps a few more GUI config tools might be nice but I think largely the UI is quite impressive (Both the CLI and GUI).
I cannot agree. Linux is a patchwork quilt of different tools, written by different people, to different standards, for different purposes, and it shows. There have been valiant (and ongoing) attempts to try and layer a good UI over the top of it, but they still have a lot of work to do. Even within the realms of free unixes, the BSDs - while still suffering
I don't know about Europe, but I know in comparison to Canada, the 'left' American party (Democrats) is still right of our right party, the Conservatives.
The entire US political spectrum is skewed (significantly) to the right. What the US refers to as "left" (ie: the Democrats) most (if not all) of the rest of the developed world refers to as "centre-right". What the US refers to as "right" (ie: the Republicans) most (if not all) of the rest of the developed world refers to as "far-right, gun-crazy religious nuts".
When an American calls someone "far right wing", you know they're talking about some seriously messed up people. Probably race supremists or "chain the women to the kitchen"-style religious fundies.
Note that this is right and left wing from a (mostly) social perspective. Fiscally - with the exception of favouring big tax cuts for high income earners - even the "right wing" governments are pretty "left wing" in their approach to economic issues, pretty much across the (developed) world.
But depending on your specific needs you might want to just stick with the C3's (which, incidentally, cannot keep gig-e filled, so if you wanted full gig-e bandwidth on each host, you'll want something beefier than the C3).
I'd be looking at the motherboards before the CPUs. What's the bus topology of the motherboards you use ? What SATA & network controllers ? What *motherboard chipset* ?
RAID5? BAARF. If you were to use RAID10 instead, you'd still be around $2.1x per GB which is below the original poster's $3/GB max.
While BAARFers have a point, if your performance profile doesn't involve lots of random writes, then RAID5 (or, preferably, RAID6, if you have a large (~>6 disks) array) is a perfectly valid solution *and* provides [much] better $/GB.
How do you connect the storage in the back-end machines to the front-end? NFS? CIFS? Network Block Devices?
iSCSI. Using the linux-iscsi-utils in CentOS 4.3.
You could also use NBD or AoE (that's ATA over Ethernet, not Age of Empires;) ), but I have found iSCSI to be the fastest, most reliable, most flexible and most supported solution.
You firstly need to assess what the storage is for - in particular, its *requirements* for performance and reliability/availability/uptime.
If you require high levels of performance (=comparable to local direct-attached-disk) or reliability (=must be online "all the time") then stop right now and go out talking to commercial vendors. You will not save enough money doing it yourself to make up for the stress, people-power overheads and losses the first time the whole house of cards falls down.
However, if your performance or reliability requirements are not so high (ie: it's basically being used to archive data and you can tolerate it going down occasionally and unexpectedly) then doing it yourself may be a worthwhile task. I get the impression this is the kind of solution you're after, so you'll be looking at standard 7200rpm SATA drives.
Firstly, decide on a decent motherboard and disk controller combo. CPU speed is basically irrelevant, however, you should pack each node with a good 2G+ of RAM. Make sure your motherboards have at least two 64bit/100Mhz PCI-X buses. I recommend (and use) Intel's single-CPU P4 "server" motherboards and 3ware disk controllers. I believe the Areca controllers are also quite good. You will have trouble on the AMD64 side finding decent "low end" motherboards to use (ie: single CPU boards with lots of I/O bandwidth). Do not skimp on the motherboards and controllers, as they are the single most important building blocks of your arrays.
Secondly, pick some disks. Price out the various available drives and compare their $/GB rates. There will be a sweet spot were you get the best ratio, probably around the 400G or 500G size these days (it's been several months since I last put one of these together).
Thirdly, find a suitable case. I personally don't like to go over 16 drives per chassis, but there are certainly rackmount cases out there with 24 (and probably more) hotswap SATA trays.
Now, put it all together and run some benchmarks. In particular, benchmark hardware RAID vs Linux software RAID and see which is faster for you (it will probably be software RAID, assuming your motherboard is any good). Bear in mind that some hardware RAID controllers do not support RAID6, but only RAID5. Prefer a RAID6 array to a RAID5 + hotspare array.
You now have the first component of your Honkin' Big Array. Install a suitable Linux distribution onto it (either use a dedicated OS hard disk, get some sort of solid-state device or roll a suitable CD-ROM based distro for your needs). Setup iSCSI Enterprise Target.
Finally, you need a front-end device to make it all usable. Get yourself a 1U machine with gobs of network and/or bus bandwidth. I recommend one of Sun's x4100 servers (4xGigE onboard + 2 PCI-X). Throw some version of Linux on it with an iSCSI initiator. Connect to your back-end array node and set it up as an LVM PV, in an LVM VG. Allocate space from this VG to different purposes as you require.
When you start to run out of disk, build another array node, connect to it from the front-end machine and then expand the LVM VG. As you expand, investigate bonding multiple NICs together and additional dual- or quad-port NICs to supplement the onboard ones. I also recommend keeping at least one spare disk in the cupboard at all times for each of your storage nodes, and also a spare motherboard+CPU+RAM combo, to rebuild most of a machine quickly if required. Ideally you'd keep a spare disk controller on hand as well, but these tend to be expensive, and if you're using software RAID, any controller with enough ports will be a suitable replacement for any failures.
We do this where I work and have taken our "array" from a single 1.6T node (12x200G drives) to 10T split amongst 3 nodes. We are planning to add another ~6T node before the end of the year. *If* this is the kind of solution that would meet your needs, I can offer a lot of help, advice and experience to you.
They wrote *all* of Windows NT (ne: OS/2 NT) (and parts of OS/2). That was their role in the partnership.
[...] IBM wrote some.
IBM wrote most of OS/2 (Microsoft did bits of it, like HPFS). AFAIK, they didn't write any of Windows NT.
Windows NT and OS/2 are (and always have been) *completely* different codebases. Windows NT is not in any way, shape or form a derivative of OS/2 - a few minutes of looking at their respective designs should tell you that, even if you haven't read any of the wealth of material covering the subject.
Microsoft claiming it all is not OK, and then using what they obtained to block IBM is DEFINITELY not OK.
Discussion is about software vulnerabilities, about microsoft having so poor security that need so much patching, and if this is a microsoft trait or if once linux rises similar sitution will be observed.
Your assumption (that I am disputing) is that Microsoft has "poor security" because they need patching, when the vast majority of Windows exploits are not made via software vulnerabilities.
Of course, I know, there are some annoyance that aren't software dependent, like phishing, spam, spoofing and similar scam that aren't software dependant (and in fact even computer dependant and could also work with smartphone or even faxes) but wetware dependent.
These are not "annoyances", they are the primary vectors for the vast majority of malware and other exploits.
This applies to all platforms, by the way, not just Windows. Software exploits are relatively uncommon. Remote exploits, even rarer. By *far* the most common way for any system to be exploited is via a user.
But you still have to sit in front of it, first place, or find another way to have access to the machine.
This is not especially difficult. Offer the user a candy bar, porn or a free iPod in exchange for access to their machine.
A well designed machine is supposed to be un-accessible from the internet. closed to the outside world, everything that enters (webpages and emails) should be sand-boxed, and any remaining door (remote ssh login) should be encrypted and secured.
I am not disputing this, however, I am saying that properly secured machines are both a) exceptionally uncommon and b) much harder to use.
To break into such a box, you go either thrue social engeneering (like trying to obtain password) or you count on the fact that this secure design is flawed at some place that you can abuse to break inside.
Most attacks (and subsequent exploits) are social engineering variants.
To believe what I wrote implied that there have not been any advancement on *nix over 30 years (or even 10 years) is stupid. There are many commands and tools that are very much in use today that would be found on either of those systems.
That wasn't what I meant. Unixes have changed a lot in the last 30 - hell, even the last 10 - years. Many of those "same" commands on older systems will not behave in the same way. Many tools you are probably used to on a modern unix system (like bash) didn't exist.
Windows has certainly change _more_, but that's to be expected from a platform that's only 10 - 15 years old, vs 30. The claim that Windows is *always changing* is, IMHO, greatly exaggerated.
It could very well be that network centric computing could have prevailed and as a result, networks were maintained by professional system administrators and their expertise in knowing all the pros/cons of various software solutions would have played a much bigger role in corporate technology meetings resulting in glossy sales pitches from inferior software vendors being dismissed.
I would argue such an outcome is incompatible with the prevalence of computing in the modern world. It's an inherently slow-growth scenario.
The bottom line is Microsoft is a marketing company. It is not a company that prides itself on building superior technical solutions.
Interesting you say that, because my observations (and interactions) with pretty much everyone involved with Microsoft is that they *do* pride themselves on building "superior technical solutions" - within the constraints they have to work with.
I'm guessing the problem here is different definitions of "superior technical solutions" - and yours doesn't allow operating within the constraints of an existing system.
Check out Vista for example -- development on a flashy new interface took presidence over fundamental archtecture that would have made Vista technically superior (but harder to sell).
Ignoring that Vista has *substantial* (relatively speaking) "under the hood" modifications and improvements, there's not a lot about the "fundamental architecture" of NT that _needed_ changing. It's the technical equal of - and in many cases superior to - its contemporaries.
I'll also point out that for 90% of users, the UI is one of the most important aspects of an Operating System. Particularly when the underlying core is already quite solid, there really isn't anywhere else where significant improvements are noticable or justified.
A technology driven company would have put preference on the technically superior solution and side-lined the flashy graphics.
What is your example of such a "technology driven company" ? What would the "technically superior" solution have been ?
Slashdot Mirror
No, but it makes all the subsequent work legal. In other words, all of the development that was done at Microsoft on Windows NT.
You may well believe that everything of any importance in Windows NT was actually code written while Cutler was still at DEC - in which case I doubt I *could* ever convince you otherwise, even with sworn testimony from DEC itself.
The idea that settling means it wasn't theft is very strange, indeed.
So is the idea that copyright and patent infringment is "theft".
And no, I meant the Pentium IV for lots of technical theft by Intel There are allegations of theft for previous technologies such as the Pentium II, due toe DEC's previous policies of being relatively open about its designs in non-disclosure agreeement based meetings.
DEC and Intel settled each others lawsuits (interesting how DEC aren't "thieves", despite intel suing them for patent infringement as well) back around 1998 and came up with a ten-year cross-licensing agreement. I doubt there's any DEC technology intel would _need_ to "steal", because they already had access to it through their existing agreement.
I'm cherry picking examples that are some of the most famous and egregious, leading most directly to DEC's demise.
The mind boggles at how you could consider Windows NT having much to do with it. It's not like it actually competed in the same market space as VMS.
And stop pretending this has anything to do with misuse by open-source developers. That's serious FUD: The GPL and many other open source copyrights are carefully written to avoid this sort of abuse and others.
Right. So it's a legal arrangement like one of those "non-compete" contracts. I guess that means no-one could ever violate it.
If you violate that agreement, as a developer, you can and will have your code ripped out screaming by the roots when the FSF or other open source bodies notice it, and people like the Samba developers and Linux kernel developers have repeatedly shown exactly what lengths they go to to avoid that kind of problem.
Right. So it's like the whole lawsuit/damages thing that happens in the commercial world. But I imagine you think ripping out/rewriting the code is "OK".
While you certainly don't get the Windows source as a matter of course, the documentation - if you can be bothered to look (and, I'll agree, most cannot) - is quite comprehensive. I think your comment regarding "abstraction" is misguided, because I don't know any other unix admins who consider looking at the source code to their OS as a normal part of their system maintenance. I know *I* certainly wouldn't and would consider even the suggestion that it be considered "normal" or "recommended" to be a serious flaw in the platform. Most unix users - even admins - are using "user friendly" (for unix) tools that are really no different to the GUI tools in Windows. Just 'cause you type it and don't click on it, doesn't mean you're running any closer to the bare metal ;).
2. There is more commonality in different variations of *nix than differnet releases of Windows (Windows 3.x vs Windows Vista for example).
This comparison is ridiculous. Even ignoring that Windows 3.1 is ca. 1991 and Vista will be ca. 2007, they are *completely* different OSes. It's impressive they have anything in common at all.
While commands may different, underlying philosophies are largely the same and while it does take some time to become acquanted with a different variety of *nix, a large set of core knowledge about the system is applicable from one to the next (ie hopping between FreeBSD and RedHat or Solaris).
This is silly. There are a similar set of "philosophies" - if you can call them that - that flow through the various versions of Windows as well. Menus, GUI concepts (eg: Control Panel), etc. Sure, the exact implementations differ between the different releases, but the basic principles are all the same (with the concession of measuring from the introduction of Windows 9x, not 3.x).
3. I'll agree with Linux being a patchwork...
It's not just Linux (although it is, by far, the worst offender). The whole unix community is *full* of "solutions" that are ugly messes of hacked together, poorly documented components that only barely work well together, mostly due to luck and brute-force coding, rather than specification and design.
For example, this morning I spent several hours trying to do rolling "upgrades" of some of our ha-linux clusters. It took several hours because I discovered what appeared to be incompatibilities between various minor revisions of the heartbeat software and also problems compiling more recent versions of it on some machines. The documentation wasn't particularly help and neither were the mailing list archives (for a change).
Now, I'll be the first to admit I was being a bit cowboyish by not duplicating the existing infrastructure onto dev servers and simulating the upgrade process first, but it was a minor point update, for gawd's sake...
What *really* magnifies my frustration factor is that the Open Source world is *rife* with these sorts of "solutions" that regularly takes processes touted as quick, easy and painless (as they should be) and turns them into day-long marathons involving mailing list searches, CVS code patches (or, even better, the "mailing list post patch"), specific compiler versions and dependency hell.
4. When I originally started using
Most Adaptec controllers I've used can do it.
Your numbers sound very low. A newish (160G+, 8M+ cache) 7200RPM SATA drive should be able to sustain 40 - 70M/s (depending on the part of the disk) for streaming reads and writes (ie: dd if=/dev/zero of=/dev/sda kind of thing).
RAID a few of them together and - particularly on the typical PC - you'll probably run out of bus bandwidth before you run out of physical disk speed.
Crikey, even the ~4 year old 40G PATA drive I use for the OS on my fileserver can sustain 40M/s for streaming reads and writes - and that's through a filesystem.
Multiple logical drives over the same physical disks - especially at different RAID levels - usually hurt performance because of the different access patterns to the drives and the way OSes try to optimise the order of (physical) disk operations.
This is not to say that such configurations should never be used, but you should be aware that doing so will probably hurt performance.
He means if you define multiple RAID arrays on the card ("logical drives") can you delete them individually.
I don't know why the meme that software (or pseudo-hardware) RAID5 "sucks up" CPU cycles continues to propogate.
A 300Mhz Pentium 2 has a RAID5 checksumming speed (in Linux) of about 800M/s. So at the more realistic speeds of 50 - 75M/s your average PC's RAID5 array can write at before the bus and physical drives hit their limits and on any remotely modern CPU, the processing overhead of checksumming is insignificant.
There *are* valid reasons why a hardwar RAID controller should be faster[0] - particularly for large arrays and/or the typical, bus-starved PC, but they have nothing to do with the "CPU overheads" of RAID5, nor even the "intelligent caching" some cards boast about.
[0]And even though they *should* be faster, they frequently aren't.
Somehow I think Windows NT had just a little bit more work done to it before it was released. You talk like Windows NT was a copy of the VMS codebase someone had done a quick search and replace through. You and I both know that isn't true.
The rumours say Cutler brought some code with him. DEC sued. DEC settled. After that point, it's irrelevant, because it's _legal_, and can no longer be called "theft". You may not like that they settled for $X. You may think $X was far too low a sum. But it doesn't matter, and you can't say any further "thefts" happened, because after that point they were "purchases".
DEC settled for what turned out to be a pittance their policy was to avoid painful and possibly expensive lawsuits, and they thought they could milk the cow of the NT marketplace by selling Alphas that ran NT. This coupled with the theft of Alpha technologies for the Pentium IV chips by Intel, basically destroyed DEC's highly coupled cash cows by removing much of their competitive advantage and selling cheaper, flakier versions of the technologies for far less money because they could steal them wholesale, rather than having to develop them from scratch.
I think you mean Pentium Pro, not Pentium 4. Not to mention intel sued DEC very soon after for patent infringement as well (which makes DEC "thieves", too). Some time in 1998 (IIRC), they all came to a nice agreement involving large sums of money and technology cross-licensing agreements.
You are cherry picking examples to suit your biases. I'm pretty sure every major technology company has either been targeted by - or made - accusations of patent infringement and other forms of "intellectual property" "theft". Do not try and pretend Microsoft and Intel are the only ones this has happened to.
Talk to old DEC employees of the period: ones who know enough about the details curse the days that DEC settled out of court with both Microsoft and Intel, rather than flensing them to the fiscal bone for their wholesale theft. After that sort of disaster, and that sort of wholesale theft of your work by crooks who get rich stealing it, you're not inclined to stick around and make more good products: a lot of folks left for that kind of reason, and the loss of talented engineers was very detrimental to the company.
Yes, well, the whole thing is really nothing more than hearsay, rumor and speculation. So filling in the blanks can take the "real" story whichever way you want it to.
And don't pretend that OSS written on spare time has the same issues: [...]
But it does, unless you think there's something different about OSS developers to everyone else.
Computing is one of those fields where advancement progresses identically in independent places. As I believe several fairly smart people have said, it'd be damn near impossible to do anything worthwhile these days without violting *someone's* patent.
(This whole discussion is, IMHO, a shining example of why "intellectual property" is a broken concept.)
You have answered your own question. The answer is: performance.
The driver company doesn't need the source code to the OS to "build a proper driver". Indeed, it's far more likely to end up with a *worse* driver that depends on undocumented features and/or breaks with every minor OS revision if they *do* have the source code.
Microsoft can justifiably be expected to certify that a) the driver acts as they are told it should (eg: supports features X, Y and Z, but not P and Q) and b) the driver conforms to the documented specs of their API (ie: isn't making any calls to undocumented functions).
They can not be expected to certify driver stability on arbitrary combinations of hardware and software.
They can not be held responsbile for a driver that behaves differently during the certification process than it does on a user's system.
The very idea that you cannot use knowledge gained from prior experiences in your current (and future) job seems ... asinine, to say the least. It's difficult to see how such "non-compete agreements" even pass the laugh test, let alone be considered enforcable.
Somehow I think Cutler and his team put in just a little bit more work once they'd moved to Microsoft, than they may have already done.
One wonders if you feel similarly towards OSS programmers who are (by your logic) "stealing" from their employers when they write code in their spare time...
[...] DEC settled out of court for way, way too little money and the promise that NT would always run on Alphas.
Clearly they thought they were getting a reasonable deal, otherwise they wouldn't have agreed to it.
I just don't have to reboot anymore.
Sounds like my Windows experience for nearly a decade now.
Because every time they do, conversations at their competitors go along the lines of:
"Hah ! Microsoft is teh suxx0r ! Remember DOS ? They'll never be able to write a decent $SOME_PROGRAM. We have nothing to worry about".
How do you steal something you invented ?
Please don't be asinine and disingenuous. Those two comments were referring to two different aspects of the OS, and you know it.
I think a big difference is with *nix, administrative tasks tend to happen much closer to the core than in Windows which seems much more abstracted.
You seem to be mistaking "GUI" for "more abstracted". A GUI is no more abstracted than a CLI (well, not in principle anyway - the proclivity of Linux developers for writing GUI wrappers around CLI tools might make some think otherwise).
Its this abstraction that tends to change frequently in Windows.
I assume you're talking about UI. The UI in Windows - particularly on the server side - has not changed markedly since Windows 2000. Certainly there is far more variance between different Linux distributions than there is between different versions of Windows. Start going across unixes and the differences pile up even more.
Just because you can run 'vi somefile' on every unix, doesn't mean adminning them is the same. Plonk someone who has never used anything except RHEL in front of a SCO Openserver machine, for example, and they'll be in for a world of hurt.
The fact that this continues to change and depreciates old methods of accomplishing tasks is generally indicitive of a lower quality
On the contrary, it's indicative of *ever improving* quality.
Just because you do everything in unix by editing text files and have been able to pretty much forever, does not make that method better. Indeed, hand-editing text files is an *atrocious* form of systems management, that sucks in just about every way imaginable. That this is still a commonly accepted method of managing unix machines is a sign of close-minded stagnation, not "higher quality".
Perhaps the technology leaders have had more impact on the modern world than you give credit.
The problem with your alternatives is that they are not conducive to the incredibly rapid growth the "PC" market underwent. In a highly diverse environment, creating and maintaining interoperability, in particular, both slows growth and limits opportunities for new, innovative ideas (so does having a monoculture - as always, the best solution is somewhere in the middle).
find that last part of your comment very interesting. I do agree that Microsoft does have perhaps some of the most brilliant people in the industry working for them. What are these constraints you are referring to? The marketing side of Microsoft? The structured, business centric management style (versus the free flowing, creative style of innovative technical companies)? The constraints of building software to satisfy both short-term and long-term shareholder wealth? I tend to believe that super technical solutions and feature complete designs do not bode well for long-term shareholder wealth.
I was referring mainly to technical constraints - although these are, at a very high level, dictated by the other requirements you mention. Legacy support is, of course, the obvious one.
Again, without an idea of what you consider "technology driven companies", it's difficult to have a discussion about it.
Are we referring to desktop Linux or Windows??
I was referring to Windows, but it applies equally to modern-day Linux distributions.
I'll agree, the Linux core is quite solid .. perhaps a few more GUI config tools might be nice but I think largely the UI is quite impressive (Both the CLI and GUI).
I cannot agree. Linux is a patchwork quilt of different tools, written by different people, to different standards, for different purposes, and it shows. There have been valiant (and ongoing) attempts to try and layer a good UI over the top of it, but they still have a lot of work to do. Even within the realms of free unixes, the BSDs - while still suffering
At "casual" end of the market, a Windows version of XGrid - there's a hell of a lot of mostly-idle Windows machines out there.
The entire US political spectrum is skewed (significantly) to the right. What the US refers to as "left" (ie: the Democrats) most (if not all) of the rest of the developed world refers to as "centre-right". What the US refers to as "right" (ie: the Republicans) most (if not all) of the rest of the developed world refers to as "far-right, gun-crazy religious nuts".
When an American calls someone "far right wing", you know they're talking about some seriously messed up people. Probably race supremists or "chain the women to the kitchen"-style religious fundies.
Note that this is right and left wing from a (mostly) social perspective. Fiscally - with the exception of favouring big tax cuts for high income earners - even the "right wing" governments are pretty "left wing" in their approach to economic issues, pretty much across the (developed) world.
I'd be looking at the motherboards before the CPUs. What's the bus topology of the motherboards you use ? What SATA & network controllers ? What *motherboard chipset* ?
While BAARFers have a point, if your performance profile doesn't involve lots of random writes, then RAID5 (or, preferably, RAID6, if you have a large (~>6 disks) array) is a perfectly valid solution *and* provides [much] better $/GB.
iSCSI. Using the linux-iscsi-utils in CentOS 4.3.
You could also use NBD or AoE (that's ATA over Ethernet, not Age of Empires ;) ), but I have found iSCSI to be the fastest, most reliable, most flexible and most supported solution.
If you require high levels of performance (=comparable to local direct-attached-disk) or reliability (=must be online "all the time") then stop right now and go out talking to commercial vendors. You will not save enough money doing it yourself to make up for the stress, people-power overheads and losses the first time the whole house of cards falls down.
However, if your performance or reliability requirements are not so high (ie: it's basically being used to archive data and you can tolerate it going down occasionally and unexpectedly) then doing it yourself may be a worthwhile task. I get the impression this is the kind of solution you're after, so you'll be looking at standard 7200rpm SATA drives.
Firstly, decide on a decent motherboard and disk controller combo. CPU speed is basically irrelevant, however, you should pack each node with a good 2G+ of RAM. Make sure your motherboards have at least two 64bit/100Mhz PCI-X buses. I recommend (and use) Intel's single-CPU P4 "server" motherboards and 3ware disk controllers. I believe the Areca controllers are also quite good. You will have trouble on the AMD64 side finding decent "low end" motherboards to use (ie: single CPU boards with lots of I/O bandwidth). Do not skimp on the motherboards and controllers, as they are the single most important building blocks of your arrays.
Secondly, pick some disks. Price out the various available drives and compare their $/GB rates. There will be a sweet spot were you get the best ratio, probably around the 400G or 500G size these days (it's been several months since I last put one of these together).
Thirdly, find a suitable case. I personally don't like to go over 16 drives per chassis, but there are certainly rackmount cases out there with 24 (and probably more) hotswap SATA trays.
Now, put it all together and run some benchmarks. In particular, benchmark hardware RAID vs Linux software RAID and see which is faster for you (it will probably be software RAID, assuming your motherboard is any good). Bear in mind that some hardware RAID controllers do not support RAID6, but only RAID5. Prefer a RAID6 array to a RAID5 + hotspare array.
You now have the first component of your Honkin' Big Array. Install a suitable Linux distribution onto it (either use a dedicated OS hard disk, get some sort of solid-state device or roll a suitable CD-ROM based distro for your needs). Setup iSCSI Enterprise Target.
Finally, you need a front-end device to make it all usable. Get yourself a 1U machine with gobs of network and/or bus bandwidth. I recommend one of Sun's x4100 servers (4xGigE onboard + 2 PCI-X). Throw some version of Linux on it with an iSCSI initiator. Connect to your back-end array node and set it up as an LVM PV, in an LVM VG. Allocate space from this VG to different purposes as you require.
When you start to run out of disk, build another array node, connect to it from the front-end machine and then expand the LVM VG. As you expand, investigate bonding multiple NICs together and additional dual- or quad-port NICs to supplement the onboard ones. I also recommend keeping at least one spare disk in the cupboard at all times for each of your storage nodes, and also a spare motherboard+CPU+RAM combo, to rebuild most of a machine quickly if required. Ideally you'd keep a spare disk controller on hand as well, but these tend to be expensive, and if you're using software RAID, any controller with enough ports will be a suitable replacement for any failures.
We do this where I work and have taken our "array" from a single 1.6T node (12x200G drives) to 10T split amongst 3 nodes. We are planning to add another ~6T node before the end of the year. *If* this is the kind of solution that would meet your needs, I can offer a lot of help, advice and experience to you.
However, our "array" has neither high perfo
They wrote *all* of Windows NT (ne: OS/2 NT) (and parts of OS/2). That was their role in the partnership.
[...] IBM wrote some.
IBM wrote most of OS/2 (Microsoft did bits of it, like HPFS). AFAIK, they didn't write any of Windows NT.
Windows NT and OS/2 are (and always have been) *completely* different codebases. Windows NT is not in any way, shape or form a derivative of OS/2 - a few minutes of looking at their respective designs should tell you that, even if you haven't read any of the wealth of material covering the subject.
Microsoft claiming it all is not OK, and then using what they obtained to block IBM is DEFINITELY not OK.
"Block IBM" ?
Your assumption (that I am disputing) is that Microsoft has "poor security" because they need patching, when the vast majority of Windows exploits are not made via software vulnerabilities.
Of course, I know, there are some annoyance that aren't software dependent, like phishing, spam, spoofing and similar scam that aren't software dependant (and in fact even computer dependant and could also work with smartphone or even faxes) but wetware dependent.
These are not "annoyances", they are the primary vectors for the vast majority of malware and other exploits.
This applies to all platforms, by the way, not just Windows. Software exploits are relatively uncommon. Remote exploits, even rarer. By *far* the most common way for any system to be exploited is via a user.
But you still have to sit in front of it, first place, or find another way to have access to the machine.
This is not especially difficult. Offer the user a candy bar, porn or a free iPod in exchange for access to their machine.
A well designed machine is supposed to be un-accessible from the internet. closed to the outside world, everything that enters (webpages and emails) should be sand-boxed, and any remaining door (remote ssh login) should be encrypted and secured.
I am not disputing this, however, I am saying that properly secured machines are both a) exceptionally uncommon and b) much harder to use.
To break into such a box, you go either thrue social engeneering (like trying to obtain password) or you count on the fact that this secure design is flawed at some place that you can abuse to break inside.
Most attacks (and subsequent exploits) are social engineering variants.
That wasn't what I meant. Unixes have changed a lot in the last 30 - hell, even the last 10 - years. Many of those "same" commands on older systems will not behave in the same way. Many tools you are probably used to on a modern unix system (like bash) didn't exist.
Windows has certainly change _more_, but that's to be expected from a platform that's only 10 - 15 years old, vs 30. The claim that Windows is *always changing* is, IMHO, greatly exaggerated.
It could very well be that network centric computing could have prevailed and as a result, networks were maintained by professional system administrators and their expertise in knowing all the pros/cons of various software solutions would have played a much bigger role in corporate technology meetings resulting in glossy sales pitches from inferior software vendors being dismissed.
I would argue such an outcome is incompatible with the prevalence of computing in the modern world. It's an inherently slow-growth scenario.
The bottom line is Microsoft is a marketing company. It is not a company that prides itself on building superior technical solutions.
Interesting you say that, because my observations (and interactions) with pretty much everyone involved with Microsoft is that they *do* pride themselves on building "superior technical solutions" - within the constraints they have to work with.
I'm guessing the problem here is different definitions of "superior technical solutions" - and yours doesn't allow operating within the constraints of an existing system.
Check out Vista for example -- development on a flashy new interface took presidence over fundamental archtecture that would have made Vista technically superior (but harder to sell).
Ignoring that Vista has *substantial* (relatively speaking) "under the hood" modifications and improvements, there's not a lot about the "fundamental architecture" of NT that _needed_ changing. It's the technical equal of - and in many cases superior to - its contemporaries.
I'll also point out that for 90% of users, the UI is one of the most important aspects of an Operating System. Particularly when the underlying core is already quite solid, there really isn't anywhere else where significant improvements are noticable or justified.
A technology driven company would have put preference on the technically superior solution and side-lined the flashy graphics.
What is your example of such a "technology driven company" ? What would the "technically superior" solution have been ?