Corrections: 6.0 was branded Vista, 6.1 was branded 7. (And 6.2 will be branded 8, or maybe something else, we'll have to wait and see.) That's right, "Windows 7" and "Windows 8" are still just marketing names, and don't in any way indicate the OS version number.
Actually, m->a is part of ROT14, which is a relatively recent advancement in encryption. ROT14 is widely considered to be more secure than ROT13, in that it has suffered fewer known attacks, I consider this to be more due to "security by obscurity" than any genuine improvement.
There is a fairly large developer community that can't tell good software from bad so they just rely on the originating vendor to make their determination. MS - Bad, Apple - Good, OS - Excellent.
This developer community would be... the open source developer community?
What is this "F11" of which you speak? I first used WP 5.1 on a PC keyboard that had only 10 function keys (two rows of 5, on the left side of the keyboard). Reveal Codes was Alt-F3.
Office for Macs exists solely to (i) reduce issues with anti-trust, and (ii) to get people on Office and then move them to Windows.
Office for Mac exists because it makes a profit, otherwise MS would stop making it. It doesn't reduce anti-trust problems; if anything it furthers the Office monopoly by strengthening Office document format dominance. It doesn't get people to move to Windows; if anything it allows them to avoid moving to Windows and stay on Mac.
Unix Services for Windows and the POSIX layer (posix.dll) only exist to get people to migrate their applications to Windows. It's heavily outdated and does not, by design, get the same performance as the native Win32 API - even though both are just wrappers around the NT kernel itself.
Firstly it's not the "native Win32 API". The native API is underneath the Win32 API. The Posix and Win32 APIs are on top of the native API, like you said, so both are equally "native". Secondly, do you have any hard data showing that one is more performant than the other? They should be fairly equivalent performance-wise. Some differences could arise due to specific semantics that are imposed by one subsystem or the other; to not adhere to the semantics would lead to incorrectness. Thirdly, you do have the option of using the native APIs directly, although they are harder to use and sparingly documented; feel free to try to implement your own Posix layer without the gross inefficiencies you allude to. Fourthly, to turn this around, can you say that WINE apps on Linux offers equivalent performance to native Linux apps?
MS has changed the CIFS/SMB protocol on nearly every release of Windows to force people to upgrade
These protocol changes have brought new features and massive performance improvements (particularly with SMB 2.0 in Vista). That's a good reason to continue developing the protocol. The new releases do not force you to upgrade, since if you have two different versions talking to each other they will negotiate down to a protocol version that both understand (ex: 2.0 talking to 1.1 will negotiate to 1.1). Also, NFS has also introduced several new versions over the years, currently on version 4.1. SMB and NFS are in ongoing competition.
Actually, under 64-bit Windows, 32-bit processes get a full 4GB of address space. Devices and kernel-mode drivers use addresses > 4GB. That's a nice benefit of 64-bit Windows even if most of your apps are still 32-bit.
SMB: We have reverse engineered it for a while. It's simple, just open it or give the specs to the Samba team and stop changing crap between Windows versions so it keeps working.
You say "We have reverse engineered it for a while"... Who's "we"? Do you speak for the Samba team? The Samba team not only has access to the above specs, but they also receive some special treatment. They periodically meet with MS devs face to face or over voice conference. One of the Samba team members (Chris Hertel) is actually working for Microsoft on contract right now. The Samba team's challenges keeping pace with Windows SMB are not because of lack of access to information, they are because there is simply a lot of work and limited resources. In fact they have even more work than the Windows SMB team because they have to build some additional layers (e.g. creation timestamps, security ACLs, user ID mappings) owing to differences between UNIX and Windows.
Microsoft publishes specs for all their proprietary protocols used in Windows, including Active Directory. They are required to as part of the consent decree. You can find them all here:
Windows Server Protocols: http://msdn.microsoft.com/en-us/library/cc964399(PROT.13).aspx
Turkey bacon is also lean, and i have never seen a fat turk.(have seen fat canadians)
You may not have seen a fat turk, but have you seen a Big Turk? It's something enjoyed by us fat Canadians.:) They're actually pretty low in fat, so they're probably not what made us fat.
It's not a question of sanity. No one cluster size is best for all cases; it really depends on your file set. In general, if I had tons and tons of tiny files, I'd prefer the smaller cluster size, to minimize the amount of space wasted internally by not filling the last cluster of every file. On the other hand, if I had nothing but huge files, I'd prefer the larger cluster size, because the savings in metadata (smaller cluster bitmaps, smaller extent mappings) would outweigh internal wastage.
For the record, NTFS supports cluster sizes of 512, 1024, 2048, 4096, 8192, 16384, 32768, and 65536. You can choose the cluster size at format time. The default is 4096, which is in the middle and aims for general utility. It's actually a very good choice considering a couple of extra factors: 1) the page size on x86/x64 is 4K; 2) the sector size the industry is moving toward is 4K. There are great synergies when these are all the same.
Slashdot Mirror
And you forgot one: Server 2003 / Windows XP 64-bit.
That makes sense. Now what if you want to run dark workloads?
Corrections: 6.0 was branded Vista, 6.1 was branded 7. (And 6.2 will be branded 8, or maybe something else, we'll have to wait and see.) That's right, "Windows 7" and "Windows 8" are still just marketing names, and don't in any way indicate the OS version number.
Could you expand on why you object to Seagate's use of temp workers? Is it for philosophical reasons, or do you think it impacts quality?
FYI the exchange rate you just quoted (1 USD = 0.9582 AUD) means that the US dollar is less valuable than the AU dollar. D'oh!
I found your post to be an interesting read. Unfortunately I don't have mod points right now.
What?!? So I've been hoarding .css files for nothing?
If it's using the IE6 engine and claiming to be IE6, isn't it more like a sheep in sheep's clothing?
Actually, m->a is part of ROT14, which is a relatively recent advancement in encryption. ROT14 is widely considered to be more secure than ROT13, in that it has suffered fewer known attacks, I consider this to be more due to "security by obscurity" than any genuine improvement.
He can't move to Cuba. The US government won't let him fly there! Oh how the noose tightens.
This developer community would be... the open source developer community?
So if the sun does indeed miss its next cycle entirely, can we look forward to one or two new smaller suns joining our solar family?
What is this "F11" of which you speak? I first used WP 5.1 on a PC keyboard that had only 10 function keys (two rows of 5, on the left side of the keyboard). Reveal Codes was Alt-F3.
Excuse me, they have "Foundation" in their name. They are damn well respectable.
The english language is the french language, got it. :)
Office for Mac exists because it makes a profit, otherwise MS would stop making it. It doesn't reduce anti-trust problems; if anything it furthers the Office monopoly by strengthening Office document format dominance. It doesn't get people to move to Windows; if anything it allows them to avoid moving to Windows and stay on Mac.
Firstly it's not the "native Win32 API". The native API is underneath the Win32 API. The Posix and Win32 APIs are on top of the native API, like you said, so both are equally "native". Secondly, do you have any hard data showing that one is more performant than the other? They should be fairly equivalent performance-wise. Some differences could arise due to specific semantics that are imposed by one subsystem or the other; to not adhere to the semantics would lead to incorrectness. Thirdly, you do have the option of using the native APIs directly, although they are harder to use and sparingly documented; feel free to try to implement your own Posix layer without the gross inefficiencies you allude to. Fourthly, to turn this around, can you say that WINE apps on Linux offers equivalent performance to native Linux apps?
These protocol changes have brought new features and massive performance improvements (particularly with SMB 2.0 in Vista). That's a good reason to continue developing the protocol. The new releases do not force you to upgrade, since if you have two different versions talking to each other they will negotiate down to a protocol version that both understand (ex: 2.0 talking to 1.1 will negotiate to 1.1). Also, NFS has also introduced several new versions over the years, currently on version 4.1. SMB and NFS are in ongoing competition.
How could the sharks pass up that Fillet-O-Fish goodness?
Brown. Out.
You just put three paragraphs of text into one Slashdot post. Do you expect me to read all that? Please summarize into bullet points. Thanks!
Actually, under 64-bit Windows, 32-bit processes get a full 4GB of address space. Devices and kernel-mode drivers use addresses > 4GB. That's a nice benefit of 64-bit Windows even if most of your apps are still 32-bit.
What offset are you looking at? If you delve just a bit further into /dev/null, you'll find some very revealing stuff.
The specs are published here:
SMB: http://msdn.microsoft.com/en-us/library/cc246231(PROT.13).aspx
SMB2: http://msdn.microsoft.com/en-us/library/cc246482(PROT.13).aspx
You say "We have reverse engineered it for a while"... Who's "we"? Do you speak for the Samba team? The Samba team not only has access to the above specs, but they also receive some special treatment. They periodically meet with MS devs face to face or over voice conference. One of the Samba team members (Chris Hertel) is actually working for Microsoft on contract right now. The Samba team's challenges keeping pace with Windows SMB are not because of lack of access to information, they are because there is simply a lot of work and limited resources. In fact they have even more work than the Windows SMB team because they have to build some additional layers (e.g. creation timestamps, security ACLs, user ID mappings) owing to differences between UNIX and Windows.
Microsoft publishes specs for all their proprietary protocols used in Windows, including Active Directory. They are required to as part of the consent decree. You can find them all here:
Windows Server Protocols: http://msdn.microsoft.com/en-us/library/cc964399(PROT.13).aspx
You had bitmaps! I only had her in ASCII art.
You may not have seen a fat turk, but have you seen a Big Turk? It's something enjoyed by us fat Canadians. :) They're actually pretty low in fat, so they're probably not what made us fat.
It's not a question of sanity. No one cluster size is best for all cases; it really depends on your file set. In general, if I had tons and tons of tiny files, I'd prefer the smaller cluster size, to minimize the amount of space wasted internally by not filling the last cluster of every file. On the other hand, if I had nothing but huge files, I'd prefer the larger cluster size, because the savings in metadata (smaller cluster bitmaps, smaller extent mappings) would outweigh internal wastage.
For the record, NTFS supports cluster sizes of 512, 1024, 2048, 4096, 8192, 16384, 32768, and 65536. You can choose the cluster size at format time. The default is 4096, which is in the middle and aims for general utility. It's actually a very good choice considering a couple of extra factors: 1) the page size on x86/x64 is 4K; 2) the sector size the industry is moving toward is 4K. There are great synergies when these are all the same.