Well, that is the point where Microsoft copied X Windows wrongly. There is no need to run the windowing GUI on the remote machine if the local machine is already running a windowing GUI.
No, it's where they implemented a solution with a different goal. In particular, the ability to disconnect from, and reconnect to, a session.
In the US you've managed to make "liberal" mean "socialist" [...]
No, "liberal" in the US refers (or seems to, based on its usage) to people who are socially liberal (ok with abortion, sex outside of marriage, gays getting married, etc, etc). *Generally* this will align with left-ish political leanings, but it's not a given (and, as you note, "left" in the US generally translates to "somewhat right of centre" everywhere else).
Nuclear weapons are unquestionably safer and more reliable than biological weapons. They are also an effective deterrent against biological attack, or rather they were until the moron at 1600 Penn Ave announced that we wouldn't use them in response to one.
Right. Because it's not like "pledge" would change as soon as is necessary.
BZZZTTT, WRONG! Australians also have to pay income tax to the Aaustralian tax office even though the don't live there or use any of the services that income tax provides.
No we don't. Foreign income affects your tax _brackets_, but you still only have to pay tax on the income earned in Australia.
Ticket prices were barely more than 1st class going subsonic.
Note, however, that the cabin seating (if not the service) was roughly the equivalent of current US long-haul, domestic "first class", and not even remotely close to the first class cabins you'd find on a contemporary BA or Singapore Airlines 747.
And your veracity suffers even more. NT 4 was more stable in the beta cycle? Really?
Absolutely. I was happy to get a week out of OS/2 before something (usually related to the good old SIQ) necessitated a reboot to recover. NT4 would run happily for weeks (though my reboots were usually planned). Heck, for the whole ~4 years I ran it I think I had less than half a dozen BSODs, and most of those were caused by hardware failures or bad drivers.
You weren't affected by the 42 day timer bug? Or the 20/32 bit page counter pointer bug that wasn't fixed until SP1?
Not that I know of, and after some googling around I can't even find anything resembling the bugs you're talking about. Can you link me to a KB article ?
Did you even run either of these systems?
I ran OS/2 for about 3 years - mostly Warp 3, but I had also messed around with 2.0 and 2.1. I ran NT4 for about 4 years. I briefly tried Warp 4, but by then I was sold on NT4 and didn't see any reason to switch back to what was clearly a dying platform.
How about the ever present guaranteed fragmentation problem that MS refused to acknowledge with NTFS until XP?
The "fragmentation problem" in NTFS is grossly overstated for all but corner cases. I did (and subsequently have done again) numerous benchmarks, both with software tools and with a stopwatch, and could never detect any meaningful difference in performance between drives purportedly having 50% or more fragmentation, and drives having less than 10% fragmentation.
BTW, MS's recommendation was weekly reboots, circa 97/98.
Where is this recommendation ?
You're not getting the picture. Due to NT's kernel architecture, basically any arbitrary code can be forced to be run by SYSTEM from any process and even AV can't stop it. All your sarcasm can't change the fact that this is a major security hole.
That's not what the article described. Can you link to some material elaborating on this "architectural" flaw ?
I did that on purpose.
I'm sure. Doesn't make it any less wrong. There's no justifiable reason for including XP or 7, but not including 2003/XP64.
Almost no one used XP64 which actually was released across 2 years with Server 2003 being released in between.
However, a helluva lot of people are using Windows 2003.
The interesting part is that the 32 bit and 64 bit versions of 2003 were released a year apart. There was also the Server 2003 R2 release which I'm not sure what the status is compared to Server 2008 R2 which is really a new release with a different core than 2008 and requires a license upgrade.
Server 2008R2 is NT 6.1. Server 2003 R2 was a relatively minor update, most of its "improvements" basically just a collection of userspace tools.
It stands to reason that people who aren't wealthy, like myself, are in that situation due to the choices they made, which were influenced by their genetics.
No, it doesn't. Many - I'd go so far as to say most - people who have money, inherited it.
Guess it depends on what your needs are. I'm sure some could have run a 12MB system and been happy.
My needs are a stable, responsive, easy to use system. NT4 was that.
Linux and OS/2 both provided far more functionality while requiring fewer resources. Solaris was a different story.
Please. OS/2 was (relatively) unstable, barely supported and not even multiuser, though it did have a nice GUI. Linux was a PITA to setup, use and maintain, and its cutting edge GUI of the time was fvwm95. I switched FROM OS/2 to NT4 in the beta cycle (early 1996) precisely because it was so much better than OS/2 even then.
Seriously, XP to be semi functional and secure requires serious configuration.
You mean like turning on the firewall and not running trojans ?
MS provided some of this OOB with SP2. If you removed a bunch of the extraneous crap XP runs by default, you can actually get down to a pretty slim system that's quite responsive and functional, albeit not in the "MS way". I got a VM down to 4or 5 processes and less than 50MB RAM. My standard install of XP with SP3 runs about 12 processes and under 70MB RAM IIRC. It's been a while since I loaded either one.
The original XP release is quite responsive and functional on a P2 class system with 128MB of RAM. 256 and it's flying.
I did, above, where I stated but did not link to the AV bypass story posted here just a few days ago.
You didn't mention any about that story.
The short story is that thanks to DLL code injection, you can execute arbitrary code at SYSTEM privs and even the AV won't find it. DLL code injection was actually the one way that a third party can achieve true privilege escalation in Server 2008 R2, as all token manipulation APIs are now "broken".
Oh wow. A local-execution-only privilege escalation bug in third party software. Now there's a fundamental design flaw if ever I've seen one.</SARCASM>
Extremely common issue from NT 4 all the way through XP SP 3. Very noticeable when opening a 10MB attachment through a VPN link that's been choked down to 56Kbps. Once clicked, no Office app will respond in and of those systems. I have not tried this in Vista or Win 7.
Can't be that common if I've never even heard of it. Though as described it's clearly an application level problem, not an OS-level problem.
It may be distributed with, but that doesn't make it "part of" Vista. That's like saying iTunes is part of OSX, when it's clearly it's own product.
Actually, no, it's like saying Cocoa is part of OS X, which is pretty much exactly what.NET is to Windows.
Let me fix that for you and put it in proper perspective regarding major releases as we know them of the core OS:
You left out Windows 2003/XP64/NT 5.2. That's at least as significant a release as XP or Windows 7, and quite arguably more so since it became the base from which Vista was built after the development "reset" in 2004.
As per Microsoft's support lifecycle, Vista will enter "extended support" in 2012 and close out support in 2017. Note that the timeline is set by policies that were created before it was even released, so trying to argue it's being retired any earlier than expected is flat out false.
And TBBA (Truth by Blatant Assertion) destroys any credibility you might have. These were Gateway 486DX2-66 EISA systems loaded with 64MB of RAM and 2 1GB SCSI-I disks that came in for about 10K each, I bought 7 of them. You really need to get off your high horse.
I said unlikely, not impossible.
I spent about 3 weeks using it on the 486. A 486-33 was the minimum, pentium was recommended. Likewise, 16MB RAM was the minimum, 32MB RAM recommended, 64MB was the minimum usable amount for anything.
32MB of RAM was quite a usable configuration for NT4, and at 2.5x the minimum (which was actually 12MB) that's to be expected.
I also ran a Pentium Pro 180 w 128MB RAM with NT 4 in multi-boot mode for 4 years, and it was still the biggest dog out of the OSes I ran on that one. If it hadn't been for work, I doubt I would have run it at all.
Compared to what, providing the same functionality ? Heck, XP would have been ok with that sort of horsepower.
and your backing data would be?
The millions of people who managed to use Windows XP without having to resort to hacking around disabling services.
This change did break the security model completely since now a single thread ran all code through a single set of DLLs that was shared by all processes, and hence code here has full privileges.
Can you elaborate on this ?
There are also other problems with this design. Does opening a 10MB email in Outlook over a slow connection essentially stop all other user interaction with other Office apps until it's completed the task? (I don't know - I don't run MS apps if I can avoid it these days)
No, and I don't recall it ever doing so.
As I recall, NT 4.0 added a completely new display system and windows manager, new driver model, new display arhcitecture, new audio stack, new printing stack, and significant overhauls to memory, scheduling and IO.
Then you recall incorrectly. Probably the next biggest change to NT after Vista would have been NT 4.0 to NT 5.0.
In many way ways far greater compared to the previous systems than Vista to XP.
Which ways ?
And.NET is not part of Vista.
Vista is the first version of Windows to be distributed with.NET.
Considering the recent validation of the DLL injection problem, I'd say NT required a rewrite about the time it compiled the first time. It's security model is upside down and fundamentally flawed. It cannot be fixed. It's a completely backwards system that requires a highest privs model compared to every other system out there that works off of a lowest privs model.
Can you elaborate ?
It was roughly 2.7 years old when Win 7 replaced it. So yes, older than 2 years, but not 3 when they shoved its still warm carcass out the back door.
Which is quite close to the average:
3.1 - July 1993
3.5 - September 1994: +14 months
3.51 - May 1995: +10 months
4.0 - July 1996: +11 months
5.0 (2000) - February 2000: +42 months
5.1 (XP) - October 2001: +18 months
5.2 (2003/XP64) - March 2003: +18 months
6.0 (Vista) - January 2007: +46 months
6.1 (Win7/2008R2) - October 2009: +30 months
Average time between releases is ~20 months, though more importantly, the time between subsequent minor releases after a major one, tends to be <2 years. If anything, at 2.5 years after Vista, Windows 7 was somewhat behind schedule.
Given the low cost compared to commercial solution, why would you make the assumption that there isn't already a full copy on another one?
One copy ? Given such an unreliable hardware base I'd expect *at least* four to five copies, half of which reside on systems with completely separate physical infrastructure (and ideally geographical locations).
They even say they have multiple copies running around. So you are assuming something you don't have enough information to fully evaluate and assuming it's the worst possible case. I reject all such assumptions unless someone at least acknowledges they are assuming the worst case in direct contradiction to the available information.
They make no indication of what they do. *My job* is to assume the worst, because anything less is professional (and personal) negligence.
What's the failure rate you see on power supplies? Does it matter if you go for cheap commodity PSUs vs name-brand commodity ones?
The failure rate of individual PSUs is not my concern. The consequences of a power circuit blip that can take out dozens of pods - with an above average probability of data loss (or, worse, silent corruption) - is.
Backblaze have built a system that cannot handle power supply issues. That means even relatively routine datacentre maintenance is, for them, a downtime scenario, and a genuine disaster has a real possibility of causing complete data loss. Given the trivial additional expense of protecting against this, I cannot see any justifiable reason for their design decision and therefore must assume they have shown similar disregard in every other aspect of their system design.
Perhaps it comes down to a business decision that trumps the technical ones. Such as the decision to keep a second copy around no matter how reliable the hardware was, then the reliability was less important. Sure, they'll have a lower rate of transfer for moving things around after the failure of one copy, but what's that really cost in terms of extra hardware?
Even *if* they had reliable hardware, I'd expect them to keep three - if not four - copies of any hosted data. Given their hardware is not reliable, I would want at least twice that number of copies hanging around. I don't see evidence of this, and must therefore assume they're simply not doing it.
Yes, an operating company running multiple petabytes of data should increase their costs because you think their performance and reliability is too low. You realize that people get there over the Internet, so "performance" could be horrible and still beat the fastest someone can access the server?
Getting data to and from it over the internet is a minor concern. How quickly their RAIDs can scrub (assuming they even scrub - I certainly wouldn't want to bet on it) and rebuild, and how quickly they can duplicate all the data from one pod to another when pods fail (I would hope any given chunk of data is contained on at least 4-6 pods that share no common infrastructure) are vastly more important - and with the hardware they have, it will be atrociously slow (multiple days, even in ideal conditions).
But nope, you know more than they do about how to make these work, and if only they'd listened to you, then they'd be 10 times their current size because of all the people who ask about RAID rebuild times in the server or are concerned that the servers run only at 1000 times the speeds they'll be accessing them on.
I've only made a technical judgement on their hardware, not their business model. My personal belief is that due to the weaknesses in their hardware choices, they're almost certainly going to suffer a significant data-loss event at some point (if they haven't already) and for that reason I'd never entrust any of my data to them. The deceptive and dishonest comparison to the cost of similar amounts of storage from vendors whose solutions are massively more reliable and performant is another key factor in that opinion.
And I saw your name on a number of other posts, so I may have missed it, but the "I see someone put out an easy and cheap part list to make something almost exactly what is being asked about, but I'll state it's crap without actually stating the equivelent parts list for what I'd do." So, if you did post that somewhere, I'll have to track it down.
I've done it before, with the first Backblaze story here, but the basic gist is:
* Redundant PSUs (even this alone would dramatically improve the reliability situation)
* Disk controllers using x4 or x8 PCIe and SAS expanders instead of port multipliers (3-5x increase in RAID scrub and rebuild performance)
* Multiple GbE links (and with dropping prices, that will probably change to 10GbE in the next 12 months) (roughly linear increase in pod-to-pod transfer speeds, connectivity redundancy during failures and maintenance)
These changes would significantly improve both reliability and performance, while probably only adding 15-20% to the cost of the hardware - which, in the context of what it would cost to actually make said hardware useful, is a pittance, especially since it would mean they'd need less hardware in the first place.
(To say nothing of the grotesque inefficiency from a power and resources perspective of using massive amounts of duplication in an effort to produce reliability when you could just build reliability in from the start.)
If not, then you are the most useless kind of armchair quarterback. You whine about what someone else does, but don't bother to let anyone know what you'd do differently.
I've built these kinds of systems numerous times before, both for personal and business use. You can certainly assemble something that reaches probably 80-90% of the reliability and performance of a low-end to mid-range name brand storage system with COTS parts, but the patchwork quilt that Backblaze threw together isn't anywhere close to that.
Fundamentally, these guys either have to be using several times more hardware than they actually need to store the real amount of data they have (and the associated costs of building, maintaining and housing that hardware), or they're not protecting the data they have properly.
It doesn't really matter anyways as the ultimate bottleneck here will be the network at 1Gbps. Five drives evenly using a 3 Gbps channel would still be allowed 62.5 MB/s each, and that's still pretty good for network transfer.
It's not just about getting the data off. High throughput also means when you inevitably lose a disk, the rebuild will take (potentially much) less time.
The creators of that kit use RAID-6 so there are two parity disks for every four data disks. That way they can lose two drives out of a set of six and still not lose any data.
Such a shame, then, that they proceed to hang half the drives in the array off one power supply, and the other half of the second power supply.
To say nothing of what the rebuild times must be like on those things with their use of regular old 32 bit PCI and port multipliers - days, possibly even weeks if it was actually in use.
Sure, there is redundancy on top of this, but ISTM those pods are probably pretty reliable.
The build details about those pods was enough to convince me never to trust data to that company - they could have so dramatically increased both reliability and performance with only marginally more cost, but chose not to.
Because sadly, that is probably speculative on your part. Certain file systems, even with tons of free space, will fragment files that are in the low megabyte range. I suspect fragmentation gets even worse on the large files the OP is asking about.
The impact of "fragmentation" on NTFS performance is grossly overstated. Even with "high fragmentation" a multi-disk RAID array will be able to trivially saturate a GbE link for a sequential read of a large file. Heck, it will saturate multiple GbE links.
Having run NT 4 in beta onward it used about the same resources to run well as 2K or XP. I can say that NT 4.0 running on a 486DX2-66 with 64MB of RAM was barely serviceable.
Sorry, but utter rubbish like this destroys your credibility. Ignoring for a minute how unlikely it would be to find a 486 with 64MB of RAM, NT4 was quite usable - and I spent over a year using it - on a Pentium ~75Mhz with 32MB. To say nothing of the 486DX2/66 being a 4-year old, 2 generation old CPU at NT4's release - you wouldn't expect blistering performance out of it in the first place.
I should mention that XP out of the box is dog slow. Removing services is required both for performance and some semblance of security.
More rubbish.
Actually - the biggest update to NT was the 3.1->3.5 release, where biggest change was that the GDI layer was inserted and essentially all separation of the kernel/user space was tossed out the door for the sake of a semi usable UI.
This is flat-out false. Moving GDI into kernel space - a change which, incidentally, happened with NT 3.51 to 4.0, not 3.1 to 3.5 - didn't "essentially toss out all separation of the kernel/user space".
WIn 2K added the new modular driver framework, among other things. What exactly did Vista add? (It certainly wasn't the promised rewrite, but it did add the TPM and DRM pieces. Hooray!)
Vista added much more than any revision before it.
A completely new display system and window manager, new audio stack, new printing stack, new networking stack, new driver model, significant overhauls to memory management, scheduling and IO,.NET...
Vista was as close to a "rewrite" as NT is likely to get (and probably need) for another 15 years.
Windows 7 has some fixes that will never show up in VIsta, primarily to separate the 2 products because Vista is viewed so negatively. Note that Vista is only 2 years old, and already is being shoved out the door.
Vista is 3 years old, as of January 2010. Further, if you look back at the history of Windows NT releases, if anything it was a bit later than expected - this is especially true if you consider things that probably should have been.1 releases but weren't for marketing and political reasons (like XP SP2 and Windows 2003 R2).
Check again: you're almost certainly comparing 1TB 7200RPM drives to 2TB 5900RPM drives. And Hitachi drives don't count, being the cheap pieces of garbage they are.
When it's going to be used by only a handful of people, nearly always in a sequential access pattern, on the other end of a 1GbE link, why would you want hotter, noisier, 7200rpm drives ?
Officially it isn't. But look at the iPad, and then look at the lack of a 10" MacBook when major PC makers are making 10" laptops with Atom CPUs.
Apple are never going to compete in that market. They're just not interested in bottom-of-the-barrel, how-cheap-can-we-make-it stuff. It's not The Steve's way.
Slashdot Mirror
I wonder how many installations of Linux have SELinux disabled because it broke something.
The overwhelming majority, in my experience.
Well, that is the point where Microsoft copied X Windows wrongly. There is no need to run the windowing GUI on the remote machine if the local machine is already running a windowing GUI.
No, it's where they implemented a solution with a different goal. In particular, the ability to disconnect from, and reconnect to, a session.
In the US you've managed to make "liberal" mean "socialist" [...]
No, "liberal" in the US refers (or seems to, based on its usage) to people who are socially liberal (ok with abortion, sex outside of marriage, gays getting married, etc, etc). *Generally* this will align with left-ish political leanings, but it's not a given (and, as you note, "left" in the US generally translates to "somewhat right of centre" everywhere else).
Nuclear weapons are unquestionably safer and more reliable than biological weapons. They are also an effective deterrent against biological attack, or rather they were until the moron at 1600 Penn Ave announced that we wouldn't use them in response to one.
Right. Because it's not like "pledge" would change as soon as is necessary.
BZZZTTT, WRONG! Australians also have to pay income tax to the Aaustralian tax office even though the don't live there or use any of the services that income tax provides.
No we don't. Foreign income affects your tax _brackets_, but you still only have to pay tax on the income earned in Australia.
Ticket prices were barely more than 1st class going subsonic.
Note, however, that the cabin seating (if not the service) was roughly the equivalent of current US long-haul, domestic "first class", and not even remotely close to the first class cabins you'd find on a contemporary BA or Singapore Airlines 747.
And your veracity suffers even more. NT 4 was more stable in the beta cycle? Really?
Absolutely. I was happy to get a week out of OS/2 before something (usually related to the good old SIQ) necessitated a reboot to recover. NT4 would run happily for weeks (though my reboots were usually planned). Heck, for the whole ~4 years I ran it I think I had less than half a dozen BSODs, and most of those were caused by hardware failures or bad drivers.
You weren't affected by the 42 day timer bug? Or the 20/32 bit page counter pointer bug that wasn't fixed until SP1?
Not that I know of, and after some googling around I can't even find anything resembling the bugs you're talking about. Can you link me to a KB article ?
Did you even run either of these systems?
I ran OS/2 for about 3 years - mostly Warp 3, but I had also messed around with 2.0 and 2.1. I ran NT4 for about 4 years. I briefly tried Warp 4, but by then I was sold on NT4 and didn't see any reason to switch back to what was clearly a dying platform.
How about the ever present guaranteed fragmentation problem that MS refused to acknowledge with NTFS until XP?
The "fragmentation problem" in NTFS is grossly overstated for all but corner cases. I did (and subsequently have done again) numerous benchmarks, both with software tools and with a stopwatch, and could never detect any meaningful difference in performance between drives purportedly having 50% or more fragmentation, and drives having less than 10% fragmentation.
BTW, MS's recommendation was weekly reboots, circa 97/98.
Where is this recommendation ?
You're not getting the picture. Due to NT's kernel architecture, basically any arbitrary code can be forced to be run by SYSTEM from any process and even AV can't stop it. All your sarcasm can't change the fact that this is a major security hole.
That's not what the article described. Can you link to some material elaborating on this "architectural" flaw ?
I did that on purpose.
I'm sure. Doesn't make it any less wrong. There's no justifiable reason for including XP or 7, but not including 2003/XP64.
Almost no one used XP64 which actually was released across 2 years with Server 2003 being released in between.
However, a helluva lot of people are using Windows 2003.
The interesting part is that the 32 bit and 64 bit versions of 2003 were released a year apart. There was also the Server 2003 R2 release which I'm not sure what the status is compared to Server 2008 R2 which is really a new release with a different core than 2008 and requires a license upgrade.
Server 2008R2 is NT 6.1. Server 2003 R2 was a relatively minor update, most of its "improvements" basically just a collection of userspace tools.
It stands to reason that people who aren't wealthy, like myself, are in that situation due to the choices they made, which were influenced by their genetics.
No, it doesn't. Many - I'd go so far as to say most - people who have money, inherited it.
Virtualization is supposed to CUT costs, not incur new hardware costs.
It's not even remotely uncommon for overall cost-cutting to require additional up front expenses.
Atheists have not demonstrated an adequate method for instilling the necessary values on as wide a scale as Christianity.
What method is that ? "Do what the book says or you'll burn in hell" ? Morality by terror is no sort of morality at all.
Guess it depends on what your needs are. I'm sure some could have run a 12MB system and been happy.
My needs are a stable, responsive, easy to use system. NT4 was that.
Linux and OS/2 both provided far more functionality while requiring fewer resources. Solaris was a different story.
Please. OS/2 was (relatively) unstable, barely supported and not even multiuser, though it did have a nice GUI. Linux was a PITA to setup, use and maintain, and its cutting edge GUI of the time was fvwm95. I switched FROM OS/2 to NT4 in the beta cycle (early 1996) precisely because it was so much better than OS/2 even then.
Seriously, XP to be semi functional and secure requires serious configuration.
You mean like turning on the firewall and not running trojans ?
MS provided some of this OOB with SP2. If you removed a bunch of the extraneous crap XP runs by default, you can actually get down to a pretty slim system that's quite responsive and functional, albeit not in the "MS way". I got a VM down to 4or 5 processes and less than 50MB RAM. My standard install of XP with SP3 runs about 12 processes and under 70MB RAM IIRC. It's been a while since I loaded either one.
The original XP release is quite responsive and functional on a P2 class system with 128MB of RAM. 256 and it's flying.
I did, above, where I stated but did not link to the AV bypass story posted here just a few days ago.
You didn't mention any about that story.
The short story is that thanks to DLL code injection, you can execute arbitrary code at SYSTEM privs and even the AV won't find it. DLL code injection was actually the one way that a third party can achieve true privilege escalation in Server 2008 R2, as all token manipulation APIs are now "broken".
Oh wow. A local-execution-only privilege escalation bug in third party software. Now there's a fundamental design flaw if ever I've seen one .</SARCASM>
Extremely common issue from NT 4 all the way through XP SP 3. Very noticeable when opening a 10MB attachment through a VPN link that's been choked down to 56Kbps. Once clicked, no Office app will respond in and of those systems. I have not tried this in Vista or Win 7.
Can't be that common if I've never even heard of it. Though as described it's clearly an application level problem, not an OS-level problem.
It may be distributed with, but that doesn't make it "part of" Vista. That's like saying iTunes is part of OSX, when it's clearly it's own product.
Actually, no, it's like saying Cocoa is part of OS X, which is pretty much exactly what .NET is to Windows.
Let me fix that for you and put it in proper perspective regarding major releases as we know them of the core OS:
You left out Windows 2003/XP64/NT 5.2. That's at least as significant a release as XP or Windows 7, and quite arguably more so since it became the base from which Vista was built after the development "reset" in 2004.
As per Microsoft's support lifecycle, Vista will enter "extended support" in 2012 and close out support in 2017. Note that the timeline is set by policies that were created before it was even released, so trying to argue it's being retired any earlier than expected is flat out false.
And TBBA (Truth by Blatant Assertion) destroys any credibility you might have. These were Gateway 486DX2-66 EISA systems loaded with 64MB of RAM and 2 1GB SCSI-I disks that came in for about 10K each, I bought 7 of them. You really need to get off your high horse.
I said unlikely, not impossible.
I spent about 3 weeks using it on the 486. A 486-33 was the minimum, pentium was recommended. Likewise, 16MB RAM was the minimum, 32MB RAM recommended, 64MB was the minimum usable amount for anything.
32MB of RAM was quite a usable configuration for NT4, and at 2.5x the minimum (which was actually 12MB) that's to be expected.
I also ran a Pentium Pro 180 w 128MB RAM with NT 4 in multi-boot mode for 4 years, and it was still the biggest dog out of the OSes I ran on that one. If it hadn't been for work, I doubt I would have run it at all.
Compared to what, providing the same functionality ? Heck, XP would have been ok with that sort of horsepower.
and your backing data would be?
The millions of people who managed to use Windows XP without having to resort to hacking around disabling services.
This change did break the security model completely since now a single thread ran all code through a single set of DLLs that was shared by all processes, and hence code here has full privileges.
Can you elaborate on this ?
There are also other problems with this design. Does opening a 10MB email in Outlook over a slow connection essentially stop all other user interaction with other Office apps until it's completed the task? (I don't know - I don't run MS apps if I can avoid it these days)
No, and I don't recall it ever doing so.
As I recall, NT 4.0 added a completely new display system and windows manager, new driver model, new display arhcitecture, new audio stack, new printing stack, and significant overhauls to memory, scheduling and IO.
Then you recall incorrectly. Probably the next biggest change to NT after Vista would have been NT 4.0 to NT 5.0.
In many way ways far greater compared to the previous systems than Vista to XP.
Which ways ?
And .NET is not part of Vista.
Vista is the first version of Windows to be distributed with .NET.
Considering the recent validation of the DLL injection problem, I'd say NT required a rewrite about the time it compiled the first time. It's security model is upside down and fundamentally flawed. It cannot be fixed. It's a completely backwards system that requires a highest privs model compared to every other system out there that works off of a lowest privs model.
Can you elaborate ?
It was roughly 2.7 years old when Win 7 replaced it. So yes, older than 2 years, but not 3 when they shoved its still warm carcass out the back door.
Which is quite close to the average:
3.1 - July 1993
3.5 - September 1994: +14 months
3.51 - May 1995: +10 months
4.0 - July 1996: +11 months
5.0 (2000) - February 2000: +42 months
5.1 (XP) - October 2001: +18 months
5.2 (2003/XP64) - March 2003: +18 months
6.0 (Vista) - January 2007: +46 months
6.1 (Win7/2008R2) - October 2009: +30 months
Average time between releases is ~20 months, though more importantly, the time between subsequent minor releases after a major one, tends to be <2 years. If anything, at 2.5 years after Vista, Windows 7 was somewhat behind schedule.
Having the "best" integrated graphics is like having the "best" lame horse.
In an mpg race...
Given the low cost compared to commercial solution, why would you make the assumption that there isn't already a full copy on another one?
One copy ? Given such an unreliable hardware base I'd expect *at least* four to five copies, half of which reside on systems with completely separate physical infrastructure (and ideally geographical locations).
They even say they have multiple copies running around. So you are assuming something you don't have enough information to fully evaluate and assuming it's the worst possible case. I reject all such assumptions unless someone at least acknowledges they are assuming the worst case in direct contradiction to the available information.
They make no indication of what they do. *My job* is to assume the worst, because anything less is professional (and personal) negligence.
What's the failure rate you see on power supplies? Does it matter if you go for cheap commodity PSUs vs name-brand commodity ones?
The failure rate of individual PSUs is not my concern. The consequences of a power circuit blip that can take out dozens of pods - with an above average probability of data loss (or, worse, silent corruption) - is.
Backblaze have built a system that cannot handle power supply issues. That means even relatively routine datacentre maintenance is, for them, a downtime scenario, and a genuine disaster has a real possibility of causing complete data loss. Given the trivial additional expense of protecting against this, I cannot see any justifiable reason for their design decision and therefore must assume they have shown similar disregard in every other aspect of their system design.
Perhaps it comes down to a business decision that trumps the technical ones. Such as the decision to keep a second copy around no matter how reliable the hardware was, then the reliability was less important. Sure, they'll have a lower rate of transfer for moving things around after the failure of one copy, but what's that really cost in terms of extra hardware?
Even *if* they had reliable hardware, I'd expect them to keep three - if not four - copies of any hosted data. Given their hardware is not reliable, I would want at least twice that number of copies hanging around. I don't see evidence of this, and must therefore assume they're simply not doing it.
Because a 1Gb link can transfer data faster than a 7200rpm drive can provide it?
No it can't. Even a (modern) 5400rpm drive will hit the ~90MB/sec GigE tops out at in a sequential read. Several of them in a RAID will easily do it.
And that's assuming that the system on the other end will need to, or be capable of, accepting the data that fast - it probably won't.
Copying the footage to a backup drive (due to fragmentation when the files were originally written) took almost a day.
I'm curious as to how you isolated the problem to fragmentation.
Yes, an operating company running multiple petabytes of data should increase their costs because you think their performance and reliability is too low. You realize that people get there over the Internet, so "performance" could be horrible and still beat the fastest someone can access the server?
Getting data to and from it over the internet is a minor concern. How quickly their RAIDs can scrub (assuming they even scrub - I certainly wouldn't want to bet on it) and rebuild, and how quickly they can duplicate all the data from one pod to another when pods fail (I would hope any given chunk of data is contained on at least 4-6 pods that share no common infrastructure) are vastly more important - and with the hardware they have, it will be atrociously slow (multiple days, even in ideal conditions).
But nope, you know more than they do about how to make these work, and if only they'd listened to you, then they'd be 10 times their current size because of all the people who ask about RAID rebuild times in the server or are concerned that the servers run only at 1000 times the speeds they'll be accessing them on.
I've only made a technical judgement on their hardware, not their business model. My personal belief is that due to the weaknesses in their hardware choices, they're almost certainly going to suffer a significant data-loss event at some point (if they haven't already) and for that reason I'd never entrust any of my data to them. The deceptive and dishonest comparison to the cost of similar amounts of storage from vendors whose solutions are massively more reliable and performant is another key factor in that opinion.
And I saw your name on a number of other posts, so I may have missed it, but the "I see someone put out an easy and cheap part list to make something almost exactly what is being asked about, but I'll state it's crap without actually stating the equivelent parts list for what I'd do." So, if you did post that somewhere, I'll have to track it down.
I've done it before, with the first Backblaze story here, but the basic gist is:
* Redundant PSUs (even this alone would dramatically improve the reliability situation)
* Disk controllers using x4 or x8 PCIe and SAS expanders instead of port multipliers (3-5x increase in RAID scrub and rebuild performance)
* Multiple GbE links (and with dropping prices, that will probably change to 10GbE in the next 12 months) (roughly linear increase in pod-to-pod transfer speeds, connectivity redundancy during failures and maintenance)
These changes would significantly improve both reliability and performance, while probably only adding 15-20% to the cost of the hardware - which, in the context of what it would cost to actually make said hardware useful, is a pittance, especially since it would mean they'd need less hardware in the first place.
(To say nothing of the grotesque inefficiency from a power and resources perspective of using massive amounts of duplication in an effort to produce reliability when you could just build reliability in from the start.)
If not, then you are the most useless kind of armchair quarterback. You whine about what someone else does, but don't bother to let anyone know what you'd do differently.
I've built these kinds of systems numerous times before, both for personal and business use. You can certainly assemble something that reaches probably 80-90% of the reliability and performance of a low-end to mid-range name brand storage system with COTS parts, but the patchwork quilt that Backblaze threw together isn't anywhere close to that.
Fundamentally, these guys either have to be using several times more hardware than they actually need to store the real amount of data they have (and the associated costs of building, maintaining and housing that hardware), or they're not protecting the data they have properly.
Now I'm seriously considering 6x2TB for a 10TB RAID for my next server replacement.
You're a braver man than me putting that much data on a RAID5 of 2TB SATA disks.
It doesn't really matter anyways as the ultimate bottleneck here will be the network at 1Gbps. Five drives evenly using a 3 Gbps channel would still be allowed 62.5 MB/s each, and that's still pretty good for network transfer.
It's not just about getting the data off. High throughput also means when you inevitably lose a disk, the rebuild will take (potentially much) less time.
The creators of that kit use RAID-6 so there are two parity disks for every four data disks. That way they can lose two drives out of a set of six and still not lose any data.
Such a shame, then, that they proceed to hang half the drives in the array off one power supply, and the other half of the second power supply.
To say nothing of what the rebuild times must be like on those things with their use of regular old 32 bit PCI and port multipliers - days, possibly even weeks if it was actually in use.
Sure, there is redundancy on top of this, but ISTM those pods are probably pretty reliable.
The build details about those pods was enough to convince me never to trust data to that company - they could have so dramatically increased both reliability and performance with only marginally more cost, but chose not to.
Because sadly, that is probably speculative on your part. Certain file systems, even with tons of free space, will fragment files that are in the low megabyte range. I suspect fragmentation gets even worse on the large files the OP is asking about.
The impact of "fragmentation" on NTFS performance is grossly overstated. Even with "high fragmentation" a multi-disk RAID array will be able to trivially saturate a GbE link for a sequential read of a large file. Heck, it will saturate multiple GbE links.
Having run NT 4 in beta onward it used about the same resources to run well as 2K or XP. I can say that NT 4.0 running on a 486DX2-66 with 64MB of RAM was barely serviceable.
Sorry, but utter rubbish like this destroys your credibility. Ignoring for a minute how unlikely it would be to find a 486 with 64MB of RAM, NT4 was quite usable - and I spent over a year using it - on a Pentium ~75Mhz with 32MB. To say nothing of the 486DX2/66 being a 4-year old, 2 generation old CPU at NT4's release - you wouldn't expect blistering performance out of it in the first place.
I should mention that XP out of the box is dog slow. Removing services is required both for performance and some semblance of security.
More rubbish.
Actually - the biggest update to NT was the 3.1->3.5 release, where biggest change was that the GDI layer was inserted and essentially all separation of the kernel/user space was tossed out the door for the sake of a semi usable UI.
This is flat-out false. Moving GDI into kernel space - a change which, incidentally, happened with NT 3.51 to 4.0, not 3.1 to 3.5 - didn't "essentially toss out all separation of the kernel/user space".
WIn 2K added the new modular driver framework, among other things. What exactly did Vista add? (It certainly wasn't the promised rewrite, but it did add the TPM and DRM pieces. Hooray!)
Vista added much more than any revision before it.
A completely new display system and window manager, new audio stack, new printing stack, new networking stack, new driver model, significant overhauls to memory management, scheduling and IO, .NET...
Vista was as close to a "rewrite" as NT is likely to get (and probably need) for another 15 years.
Windows 7 has some fixes that will never show up in VIsta, primarily to separate the 2 products because Vista is viewed so negatively. Note that Vista is only 2 years old, and already is being shoved out the door.
Vista is 3 years old, as of January 2010. Further, if you look back at the history of Windows NT releases, if anything it was a bit later than expected - this is especially true if you consider things that probably should have been .1 releases but weren't for marketing and political reasons (like XP SP2 and Windows 2003 R2).
Check again: you're almost certainly comparing 1TB 7200RPM drives to 2TB 5900RPM drives. And Hitachi drives don't count, being the cheap pieces of garbage they are.
When it's going to be used by only a handful of people, nearly always in a sequential access pattern, on the other end of a 1GbE link, why would you want hotter, noisier, 7200rpm drives ?
No. Don't do anything like that. Their system is a recipe for unreliability and data loss without specialised software.
Officially it isn't. But look at the iPad, and then look at the lack of a 10" MacBook when major PC makers are making 10" laptops with Atom CPUs.
Apple are never going to compete in that market. They're just not interested in bottom-of-the-barrel, how-cheap-can-we-make-it stuff. It's not The Steve's way.