I've seen a few third party drivers. You need to look in the other categories; they aren't critical updates so don't get pushed out. It may also be HW-specific. But I think at various times I've seen video, sound, and network drivers on Windows Update.
Well, I do have 1.5 GB of RAM, so I think I'll be set there. (The processor is an Athlon XP 2000+.)
How difficult is it to tune? Is this something that will take me 30 minutes, or something that will require lots of experimentation over days? (I don't know much about ZFS, and essentially nothing about the utilities that you use to interface with it.)
On extended attributes, you are going to have the same problem as you have with Emacs with *any* program that tries to copy a file and does not know about the attributes.
Copying a file shouldn't have to know about the attributes... systems should just issue the "copy" system call. It's only if they open the file, read the contents, then write the contents out that you have a problem. And if you copy command is doing that, I would say it's broken. Both because of the attribute thing but also because it deprives the file system the ability to optimize a lot. For instance, the file system may want to implement copy on write. Or maybe you have a networked file system, and it can issue a remote copy command and avoid transferring all that data.
As for the extended attributes problem, I did indeed get things wrong on the emacs point; it is also broken on Windows. That said, there are other programs that will be broken on Unix but not windows. The problem (which I consider a severe bug) is that when you save "foo.txt" in Emacs, it issues a "rename foo.txt foo.txt~" command, a "open O_CREAT foo.txt" command, and then several writes to the new foo.txt. In other words, foo.txt is a new file.
Now, Windows has a capability they call file system tunneling, which I thought I had tested and found that it would keep extended attributes, but I guess I'm wrong, because it doesn't.
Now I'm just even more annoyed at Emacs.;-)
I would prefer to see a system where the attributes are embedded into the single stream of text that is in the file, so they are always copied and can be stored on any device.
But then every program would have to be modified to know about these. Want to add metadata to your photo? Oops, you broke the file format.
You need either something external to the file (extended attributes), to change a large portion of current code so that it doesn't break, or not use a unified way of storing the information. (Comments for source code, EXIF comments for photos,...)
Also, I don't really WANT to see all the metadata when I'm editing, say, a text file, tough I guess this could be added as a editor feature to turn it off.
Biggest problem I see with Windows is the use of "wide characters" in the filenames. They need to replace this with utf-8 asap and remove all the triplicated interfaces (old, a, and w) that it has now.
As someone who has only recently been reading about Unicode and text encodings and such, what are the problems with wide characters? The only one I know of is wasted space for western alphabets, but utf-8 wastes space for east Asian alphabets.
And I don't think it's terribly fair to say that there are three interfaces when the old interface is just a thin layer on top of one of the two others.
And start using forward slash and make "/A/" mean the same as "A:/".
I do like this idea. (Actually, I would make/A:/ mean the same thing, which would probably ease porting quite a bit. And people who start deliberately using the new root would probably not use directory names like/A/,/D/, etc. anyway.)
Secondly, ZFS runs better on 64bit - so using the 32-bit i386 release is not recommended.
This is quite disappointing to me, as I was going to run FreeBSD on my old box as a file server, and have been anxiously awaiting its release. (I want ZFS's snapshots.)
Is the caution against 32-bit of the form "it's slow and can't handle dozens, hundreds, or thousands of users", or of the form "it's poorly tested, unstable, and may eat your data"?
I guess I didn't do a good job of wrapping up my argument in my original post, and then never finished it in this one. My point is that, because everything that you might want to do to affect the execution environment of the child process you have to be able to do at the CreateProcess call, the complexity is there whether you need it or not. Even though probably most of the time you're not going to redirect standard input or output, change security permissions, or change the working directory, you have to deal with those options whenever you make a call to CreateProcess, whether you care or not.
I disagree, and elaborated in another post in this story. It suffers from a bit of a false dichotomy fallacy (i.e. it may be possible to do better process creation than either the Windows method or fork/exec), and there are good arguments for why the Windows-way of doing things is right (fork, especially not the vfork variant, is expensive), but of those that I have heard and those I can think of, I think a well-implemented fork-exec API would be better to have than a CreateProcess API. (Of course, you/could/ have both, but I don't know if that's worth the complexity.) To wit:
Windows seems to have complexity a lot of places Linux doesn't, and for no good reason. Other places, it is for backwards compatibility, which is a good reason in spite of the fact that maintaining it at almost any cost is already starting to bite MS a bit. As an example of the first case, I trot out my example of process creation.
The API on Unix seems really weird when you first see it. (Or at least it did to me.) Why do I have two calls -- fork then exec? Why not just have one that creates a new process? (And doesn't block like system(3) does.) Then you learn that there are uses of fork alone -- e.g. the Apache model. But then the big one hits: you can do things between the fork and exec. Want to remap your standard input and output so they go to a pipe? Do fork, dup2 or whatever (I'm too lazy to look it up), then exec. Running as root and want to drop privileges? Do fork, setuid, then exec. Want to run the child process in another directory? Do fork, chdir or whatever, exec. fork has zero parameters. Depending on the version of exec you use, it may have as few as two.
On Windows, you get CreateProcess. (This isn't a wrapper over a better syscall API either, from what I know; see NtCreateProcess [ntinternals.net].) Any of those things that I said above you have to do in the call to CreateProcess, which means that is a horridly complicated function. Look at the API docs; it takes 10 parameters. (Though for comparison purposes it's better to assume it takes 9. One of them is an out parameter used for the PID and other information.) Not only that, but one of the parameters takes a STARTUPINFO struct, which has 18 fields (three of which must be zero (?!)). Want to redirect standard input and output? You fill in fields in the STARTUPINFO, then set a flag. Want to drop permissions? You create a new SECURITY_ATTRIBUTES struct and pass it to CreateProcess. Want to start it in another working dir? That's a parameter to CreateProcess.
Get rid of single letter drive names (you know, the eighties called,...)
The current situation isn't perfect, but it's not horrible. You can mount drives at paths, just like in Unix. (You do have to do it on NTFS; the functionality is provided by the file system itself rather than at a higher level. This is probably a mistake.) Things work a little funky if you mount removable drives, but it can be done.
The directory separator is '/', As Seen On Unix and URLs.
You already can use '/' in many places, including directly in calls to fopen. Again not perfect support; for instance CMD (very annoyingly) won't tab-complete through them.
Reorganize the file system more like Unix/Linux, and maybe rename 'Program Files' to 'Applications', have a/usr directory tree, etc
I like the Program Files -> Applications rename idea. Vista renames Documents and Settings to Users, which is sometimes nice for programs that don't like spaces in paths.
(Speaking of which, here's a suggestion: make your command line parsing like Unix. Passing the command line, uninterpreted, has some occasional nice benefits, but the drawbacks that parsing is not always done consistently or very predictably.)
There are so many developers making their products and living based on the Windows API that to move to something GNU "compatible" would simply be catastrophic in so many ways that I'd prefer not to put brain power into imagining the details. It would be ugly though... very ugly.
You are making a critical error, which is to assume that they would have to abandon the Windows API. There are two possible approaches: 1. Do something like Cygwin, and build this hypothetical UNG on top of Win32. 2. Expand SUA a bit.
The second approach is the more interesting one. See, the Windows NT system call interface is NOT the Windows API. Translation from the Windows API to the (half-undocumented) system call interface is done by a set of DLLs that together comprise the Windows Subsystem. Other subsystems could provide different translations. For a while there was an OS/2 subsystem, which provided an OS/2 API. SUA is a subsystem that provides a POSIX.2 API. In fact, if you run a 16-bit program, that is running in a different subsystem than 32-bit programs. (Likewise if you run 32-bit programs on 64-bit Windows.)
One of the very nice things about NT is that it is extremely amenable to putting a new API on top, because it was designed that way from the beginning.
A GUI-less Windows.. Isn't that called DOS?? Or have I missed something..
Um, maybe Windows NT?
Hell, the connections between Windows 9x and DOS are often overstated: "Among other things those drivers did [during the loading of Win95] was 'suck the brains out of MS-DOS,' transfer all that state to the 32-bit file system manager, and then shut off MS-DOS."
I think the fork the OP is talking about is for forking processes, not alternate data streams.
(The latter is actually starting to see use BTW. For instance, if you download a file with IE, it will add a stream that states that it came from the internet, and if you run it, it will display a confirmation dialog that the program came from an untrusted source. (This is starting with XP SP2; I don't know how it interacts with UAC in Vista.) I think it's actually a reasonably spiffy technique, at least if it works, which I don't know if it does.)
Windows NT has had a POSIX layer since the beginning. At any point Microsoft could have extended this and ported over GNU tools if they had wanted. The whole thing smells of bullshit, and Powershell is not bash.
And actually they've done that. The POSIX subsystem has been extended to POSIX.2, and you can get a small library of pre-compiled programs for it. Including, yes, a port of Bash.
Out of all of the objections you could take of CMD, you choose autocompletion?
I have about one real complaint... it won't complete through / used as a directory separator. (Even though they usually actually work for commands... cd foo/bar works fine for instance.)
It definitely works differently than the Unix approach, but I would say it's a 50/50 chance as to which works better in any given situation. (Though admittedly the CMD model sometimes falls on its face when it doesn't do as well, while the Unix method never is actively destructive.)
Windows NT did have a POSIX environment that sat above the NT kernel....and it still does, and it's been kept up to date. It's not included and has changed names a couple times (it's now called SUA -- Subsystem for Unix-based Applications), but it's a free download.
You can't even do networking without WIN32.
This hasn't been true for a while... You can get an implementation of SSH for instance. It also provides an NFS server and client (IIRC).
In short, it was just enough POSIX for Microsoft to claim it was POSIX.1 compliant...
It's now just enough for MS to claim it is POSIX.2 compliant.
It's not great -- you can still not do GUIs and stuff from a program running in SUA, the compatibility isn't great, and I think that one way or the other (running SUA programs from cmd.exe or Win32 programs from SUA Bash) requires that you invoke the program through another command, but it is still rather better than it used to be.
My impression is that the POSIX subsystem was neglected for a few years and then MS brought it back and updated it to POSIX.2. Between that and the release of PowerShell, I'm not terribly surprised to see something like this story. Could it be a hoax? Maybe. And concerns about "embrace, extend, extinguish" are probably worth having. But for my take, don't be surprised to see increased interoperability attempts at least in the short term, whatever MS's longer term goals are.
[Whew, long post. If your reaction is 'TL;DR' I don't feel bad.]
The NT kernel... is an interesting beast. There are a lot of things I really like about the architecture it presents. In many ways it has a lot of things that are more modern and better-designed than Unix-descendents (including Linux). At the same time MS seems to have made it more complicated than it "needs" to be, in part to satisfy backwards compatibility and in part because they just seemed to make some decisions I don't agree with.
Some of the good points:
1. Security. Yes, security. This is often brought up as a Windows problem, but that is largely because of policy decisions such as running as admin. (There are also a number of bugs caused by just plain bad coding that lead to buffer overflows. The biggest problem here in some sense is some of the abilities such as sending messages to other processes, which are probably too ingrained to pull out without some very clever modifications.) The security manager in NT provides a lot of very fine-grained control. Related, you don't need explicit file system support and a separate mechanism to do more than RWX on files. (ACLs are absolutely vital in some environments, and things like an "append only" or "create files but no delete" are useful for some applications.) In Unix, sometimes you use chmod, sometimes you use fsacl or whatever it is; the framework isn't unified.
2. Flexibility, in some sense. MS (in theory) can change the system calls that the NT kernel accepts on a whim. This is because all programs are dynamically linked to the Windows subsystem DLLs. These DLLs translate Windows API calls into whatever actual system calls they need. (One API call may generate zero, one, or more syscalls.) It's only the rare, "misbehaving" program that uses the syscall interface directly, and MS doesn't mind breaking them too much. (There are some mostly-legitimate reasons why you need to do this.) By contrast, statically linking code is a bigger tradition in Unix. (Then again, so is having source, so you can recompile if you change your syscall interface.) The idea of having various subsystems that provide different API views is pretty neat, though it's not a fundamental idea. (It's hard to say how it differs from just dynamically linking against just some shared lib.)
3. Not really a good advantage, but interesting and one of the rare examples of where Windows is actually simpler is in the read/write interface. In Unix, my impression is that if you are writing a driver, you "have" to implement to entry points for each: synchronous and asynchronous read, and synchronous and asynchronous write. In Windows, you only implement the asynchronous interface. If a synchronous request is issued, it is handled at a higher level and translated to an async call. (Upside: simpler driver code. Downside: inability to implement just the synchronous version.)
4. It's actually possible to use extended attributes on Windows, though admittedly only because of a huge hack introduced for a related but not-quite-the-same reason. (In Unix, opening a file with an extended attribute in Vi or Emacs, modifying it, and saving it is enough to kill the extended attributes. This makes them next to useless, when I at least can imagine a TON of very useful and neat things you could do with them if you could use them reliably.)
5. The registry gets a lot of hate, but I think a modified version could be better. There are a lot of very nice things it provides over config files. (Transactional access, fine-grained access controls (often nice for a corporate environment, at least in some sense),
6. Diversity. Yes, diversity. People often talk about the "Windows monoculture" on/. and other places. And yes, this is a big problem. But there is another kind of diversity, which is that Windows is the only major OS that isn't Unixy. Solaris is Unix. BSD is Unix. Linux is Unixy. It's only when you start talking about either research OSes (Mach, L4, Singularity) and old Oses (OS/2, BeOS
The point is that I don't have control of the DHCP server, which is provided by the ISP, so I can't set up a reservation.
Now, I could probably fake it by getting a DHCP license then setting up a static IP to match, but this could cause problems if the ISP decides that I get a new IP.
Now, I could put an insulating layer in there, where I set up another box with a DHCP server, but if you just have one box, that's a lot of work to work around your ISP being dickish.
Okay, great. So now I have to use a half-DHCP-configured, half-statically-configured setup?
I don't even know if that's possible to set up under Windows; I certainly don't know how to do it. I think it's more likely to be possible in Linux, but I still don't know how to do it.
And, at least as the summary describes it (the link is broken), you get control from your ISP now: "RoadRunner users can disable this function."
Though I'd be a little surprised if OpenDNS didn't give you a way to disable the guide, I don't see anything on the page your parent linked that says you can.
Seems like the "processor hours" metric needs some adjustment to account for multi-core. Otherwise I could build one of these with 15,744 single-core processors and claim the same performance.
Why are you associating processor-hours with performance anyway? You could hook up 15,744 286s and get the same number of processor-hours too. So why don't you complain about that?
Not just that, but graphics drivers are a significant piece of tech in their own right anymore.
Know about shader programs? Those are compiled by a JIT compiler in the driver, at runtime. If nVidia or ATi believes that they have a better compiler that implements some optimizations that the other's doesn't, that could make them very reluctant to release the code.
There's also a copyright issue. If the noscript people start distributing Google's gmail scripts, they leave themselves open to a cease & desist letter or a lawsuit. Distributing just a hash makes it easier to argue that.
If it didn't come with a whitelist it would be much better, but then even fewer people would use it.
Sure, some websites will take steps to make every bit of client-side scripting unique for every connection. They'll obfuscate their code, randomize the variable names on a per-session basis, mess with the structure... and now you KNOW those websites are hostile and malicious and should be treated as such.
It does seem likely, but it's not completely given that dynamically-generated scripts are malicious. You could think of putting some identifying information (a session ID) into the script somewhere, or something like that. (Google uses generated scripts (variable names replaced by a single letter and stuff like that) to save bandwidth, though I bet they do that offline then serve it statically.)
(That said, the hash-based version is subject to the same problem.)
For things like Slashdot and other dumb web forums? Yes. The convenience trumps the security risk. For my bank and school email accounts? No. But I didn't do that before anyway.
If you're asking "does anyone still think that it's a good idea to have the browser be able to store your passwords", the answer is definitely yes.
WTF is it with Microsoft and shift-click doing something useful?
Ever want an image of an Excel chart? For a long time, I would do it by hitting printscreen, pasting it into Paint, then cropping it. But there is a better way: select the chart, shift-click the edit menu, then choose the option "Copy Picture." I'm not sure I know what exactly the options do in the dialog that pops up, but that's a minor inconvenience compared to the old way.
"There are other ways to do this that don't require specific hardware. Google "Vista breadcrumbs". It takes 30 seconds to get used to it, but it's perfectly effective."
They aren't perfectly effective. I personally think most of this review is stupid, but the complaint that "With a directory that has a long name like that, the higher-level directories aren't visible in the address bar, so I had to locate it manually in the left-hand tree view panel" is something that I know he's not the only one to have experienced, because I have too. [That said, note to reviewer: see that triangle between the paths? Click it. It's still more annoying than just hitting 'up', but probably less than using the treeview.]
It also requires a little more locating. I know where 'up' is in XP relative to the Window, but in vista you have to read.
It seems to me the licensing prohibits you from including the OS when giving the PC away anyway
Huh? Where on earth did you get that idea? From the XP EULA: "Transfer to Third Party. The initial user of the Software may make a one-time permanent transfer of this EULA and Software to another end user, provided the initial user retains no copies of the Software. This transfer must include all of the Software (including all component parts, the media and printed materials, any upgrades, this EULA, and, if applicable, the Certificate of Authenticity)."
Slashdot Mirror
I've seen a few third party drivers. You need to look in the other categories; they aren't critical updates so don't get pushed out. It may also be HW-specific. But I think at various times I've seen video, sound, and network drivers on Windows Update.
Well, I do have 1.5 GB of RAM, so I think I'll be set there. (The processor is an Athlon XP 2000+.)
How difficult is it to tune? Is this something that will take me 30 minutes, or something that will require lots of experimentation over days? (I don't know much about ZFS, and essentially nothing about the utilities that you use to interface with it.)
Thanks for your answers BTW.
On extended attributes, you are going to have the same problem as you have with Emacs with *any* program that tries to copy a file and does not know about the attributes.
;-)
...)
/A:/ mean the same thing, which would probably ease porting quite a bit. And people who start deliberately using the new root would probably not use directory names like /A/, /D/, etc. anyway.)
Copying a file shouldn't have to know about the attributes... systems should just issue the "copy" system call. It's only if they open the file, read the contents, then write the contents out that you have a problem. And if you copy command is doing that, I would say it's broken. Both because of the attribute thing but also because it deprives the file system the ability to optimize a lot. For instance, the file system may want to implement copy on write. Or maybe you have a networked file system, and it can issue a remote copy command and avoid transferring all that data.
As for the extended attributes problem, I did indeed get things wrong on the emacs point; it is also broken on Windows. That said, there are other programs that will be broken on Unix but not windows. The problem (which I consider a severe bug) is that when you save "foo.txt" in Emacs, it issues a "rename foo.txt foo.txt~" command, a "open O_CREAT foo.txt" command, and then several writes to the new foo.txt. In other words, foo.txt is a new file.
Now, Windows has a capability they call file system tunneling, which I thought I had tested and found that it would keep extended attributes, but I guess I'm wrong, because it doesn't.
Now I'm just even more annoyed at Emacs.
I would prefer to see a system where the attributes are embedded into the single stream of text that is in the file, so they are always copied and can be stored on any device.
But then every program would have to be modified to know about these. Want to add metadata to your photo? Oops, you broke the file format.
You need either something external to the file (extended attributes), to change a large portion of current code so that it doesn't break, or not use a unified way of storing the information. (Comments for source code, EXIF comments for photos,
Also, I don't really WANT to see all the metadata when I'm editing, say, a text file, tough I guess this could be added as a editor feature to turn it off.
Biggest problem I see with Windows is the use of "wide characters" in the filenames. They need to replace this with utf-8 asap and remove all the triplicated interfaces (old, a, and w) that it has now.
As someone who has only recently been reading about Unicode and text encodings and such, what are the problems with wide characters? The only one I know of is wasted space for western alphabets, but utf-8 wastes space for east Asian alphabets.
And I don't think it's terribly fair to say that there are three interfaces when the old interface is just a thin layer on top of one of the two others.
And start using forward slash and make "/A/" mean the same as "A:/".
I do like this idea. (Actually, I would make
Secondly, ZFS runs better on 64bit - so using the 32-bit i386 release is not recommended.
This is quite disappointing to me, as I was going to run FreeBSD on my old box as a file server, and have been anxiously awaiting its release. (I want ZFS's snapshots.)
Is the caution against 32-bit of the form "it's slow and can't handle dozens, hundreds, or thousands of users", or of the form "it's poorly tested, unstable, and may eat your data"?
And the way 2/23/08 was a Friday.
I guess I didn't do a good job of wrapping up my argument in my original post, and then never finished it in this one. My point is that, because everything that you might want to do to affect the execution environment of the child process you have to be able to do at the CreateProcess call, the complexity is there whether you need it or not. Even though probably most of the time you're not going to redirect standard input or output, change security permissions, or change the working directory, you have to deal with those options whenever you make a call to CreateProcess, whether you care or not.
Get rid of single letter drive names (you know, the eighties called, ...)
/usr directory tree, etc
The current situation isn't perfect, but it's not horrible. You can mount drives at paths, just like in Unix. (You do have to do it on NTFS; the functionality is provided by the file system itself rather than at a higher level. This is probably a mistake.) Things work a little funky if you mount removable drives, but it can be done.
The directory separator is '/', As Seen On Unix and URLs.
You already can use '/' in many places, including directly in calls to fopen. Again not perfect support; for instance CMD (very annoyingly) won't tab-complete through them.
Reorganize the file system more like Unix/Linux, and maybe rename 'Program Files' to 'Applications', have a
I like the Program Files -> Applications rename idea. Vista renames Documents and Settings to Users, which is sometimes nice for programs that don't like spaces in paths.
(Speaking of which, here's a suggestion: make your command line parsing like Unix. Passing the command line, uninterpreted, has some occasional nice benefits, but the drawbacks that parsing is not always done consistently or very predictably.)
There are so many developers making their products and living based on the Windows API that to move to something GNU "compatible" would simply be catastrophic in so many ways that I'd prefer not to put brain power into imagining the details. It would be ugly though... very ugly.
You are making a critical error, which is to assume that they would have to abandon the Windows API. There are two possible approaches:
1. Do something like Cygwin, and build this hypothetical UNG on top of Win32.
2. Expand SUA a bit.
The second approach is the more interesting one. See, the Windows NT system call interface is NOT the Windows API. Translation from the Windows API to the (half-undocumented) system call interface is done by a set of DLLs that together comprise the Windows Subsystem. Other subsystems could provide different translations. For a while there was an OS/2 subsystem, which provided an OS/2 API. SUA is a subsystem that provides a POSIX.2 API. In fact, if you run a 16-bit program, that is running in a different subsystem than 32-bit programs. (Likewise if you run 32-bit programs on 64-bit Windows.)
One of the very nice things about NT is that it is extremely amenable to putting a new API on top, because it was designed that way from the beginning.
A GUI-less Windows.. Isn't that called DOS?? Or have I missed something..
Um, maybe Windows NT?
Hell, the connections between Windows 9x and DOS are often overstated:
"Among other things those drivers did [during the loading of Win95] was 'suck the brains out of MS-DOS,' transfer all that state to the 32-bit file system manager, and then shut off MS-DOS."
I think the fork the OP is talking about is for forking processes, not alternate data streams.
(The latter is actually starting to see use BTW. For instance, if you download a file with IE, it will add a stream that states that it came from the internet, and if you run it, it will display a confirmation dialog that the program came from an untrusted source. (This is starting with XP SP2; I don't know how it interacts with UAC in Vista.) I think it's actually a reasonably spiffy technique, at least if it works, which I don't know if it does.)
Windows NT has had a POSIX layer since the beginning. At any point Microsoft could have extended this and ported over GNU tools if they had wanted. The whole thing smells of bullshit, and Powershell is not bash.
And actually they've done that. The POSIX subsystem has been extended to POSIX.2, and you can get a small library of pre-compiled programs for it. Including, yes, a port of Bash.
Out of all of the objections you could take of CMD, you choose autocompletion?
I have about one real complaint... it won't complete through / used as a directory separator. (Even though they usually actually work for commands... cd foo/bar works fine for instance.)
It definitely works differently than the Unix approach, but I would say it's a 50/50 chance as to which works better in any given situation. (Though admittedly the CMD model sometimes falls on its face when it doesn't do as well, while the Unix method never is actively destructive.)
Windows NT did have a POSIX environment that sat above the NT kernel. ...and it still does, and it's been kept up to date. It's not included and has changed names a couple times (it's now called SUA -- Subsystem for Unix-based Applications), but it's a free download.
You can't even do networking without WIN32.
This hasn't been true for a while... You can get an implementation of SSH for instance. It also provides an NFS server and client (IIRC).
In short, it was just enough POSIX for Microsoft to claim it was POSIX.1 compliant...
It's now just enough for MS to claim it is POSIX.2 compliant.
It's not great -- you can still not do GUIs and stuff from a program running in SUA, the compatibility isn't great, and I think that one way or the other (running SUA programs from cmd.exe or Win32 programs from SUA Bash) requires that you invoke the program through another command, but it is still rather better than it used to be.
My impression is that the POSIX subsystem was neglected for a few years and then MS brought it back and updated it to POSIX.2. Between that and the release of PowerShell, I'm not terribly surprised to see something like this story. Could it be a hoax? Maybe. And concerns about "embrace, extend, extinguish" are probably worth having. But for my take, don't be surprised to see increased interoperability attempts at least in the short term, whatever MS's longer term goals are.
[Whew, long post. If your reaction is 'TL;DR' I don't feel bad.]
/. and other places. And yes, this is a big problem. But there is another kind of diversity, which is that Windows is the only major OS that isn't Unixy. Solaris is Unix. BSD is Unix. Linux is Unixy. It's only when you start talking about either research OSes (Mach, L4, Singularity) and old Oses (OS/2, BeOS
The NT kernel... is an interesting beast. There are a lot of things I really like about the architecture it presents. In many ways it has a lot of things that are more modern and better-designed than Unix-descendents (including Linux). At the same time MS seems to have made it more complicated than it "needs" to be, in part to satisfy backwards compatibility and in part because they just seemed to make some decisions I don't agree with.
Some of the good points:
1. Security. Yes, security. This is often brought up as a Windows problem, but that is largely because of policy decisions such as running as admin. (There are also a number of bugs caused by just plain bad coding that lead to buffer overflows. The biggest problem here in some sense is some of the abilities such as sending messages to other processes, which are probably too ingrained to pull out without some very clever modifications.) The security manager in NT provides a lot of very fine-grained control. Related, you don't need explicit file system support and a separate mechanism to do more than RWX on files. (ACLs are absolutely vital in some environments, and things like an "append only" or "create files but no delete" are useful for some applications.) In Unix, sometimes you use chmod, sometimes you use fsacl or whatever it is; the framework isn't unified.
2. Flexibility, in some sense. MS (in theory) can change the system calls that the NT kernel accepts on a whim. This is because all programs are dynamically linked to the Windows subsystem DLLs. These DLLs translate Windows API calls into whatever actual system calls they need. (One API call may generate zero, one, or more syscalls.) It's only the rare, "misbehaving" program that uses the syscall interface directly, and MS doesn't mind breaking them too much. (There are some mostly-legitimate reasons why you need to do this.) By contrast, statically linking code is a bigger tradition in Unix. (Then again, so is having source, so you can recompile if you change your syscall interface.) The idea of having various subsystems that provide different API views is pretty neat, though it's not a fundamental idea. (It's hard to say how it differs from just dynamically linking against just some shared lib.)
3. Not really a good advantage, but interesting and one of the rare examples of where Windows is actually simpler is in the read/write interface. In Unix, my impression is that if you are writing a driver, you "have" to implement to entry points for each: synchronous and asynchronous read, and synchronous and asynchronous write. In Windows, you only implement the asynchronous interface. If a synchronous request is issued, it is handled at a higher level and translated to an async call. (Upside: simpler driver code. Downside: inability to implement just the synchronous version.)
4. It's actually possible to use extended attributes on Windows, though admittedly only because of a huge hack introduced for a related but not-quite-the-same reason. (In Unix, opening a file with an extended attribute in Vi or Emacs, modifying it, and saving it is enough to kill the extended attributes. This makes them next to useless, when I at least can imagine a TON of very useful and neat things you could do with them if you could use them reliably.)
5. The registry gets a lot of hate, but I think a modified version could be better. There are a lot of very nice things it provides over config files. (Transactional access, fine-grained access controls (often nice for a corporate environment, at least in some sense),
6. Diversity. Yes, diversity. People often talk about the "Windows monoculture" on
MS has kept it up to date too. (I think there was some time when it was neglected, but it was then restored a bit ago.)
They've got several programs (though not that many) including Bash, SSH, and GCC.
The integration with the rest of Windows isn't great.
With a real DHCP server it is trivially easy.
The point is that I don't have control of the DHCP server, which is provided by the ISP, so I can't set up a reservation.
Now, I could probably fake it by getting a DHCP license then setting up a static IP to match, but this could cause problems if the ISP decides that I get a new IP.
Now, I could put an insulating layer in there, where I set up another box with a DHCP server, but if you just have one box, that's a lot of work to work around your ISP being dickish.
Okay, great. So now I have to use a half-DHCP-configured, half-statically-configured setup?
I don't even know if that's possible to set up under Windows; I certainly don't know how to do it. I think it's more likely to be possible in Linux, but I still don't know how to do it.
And, at least as the summary describes it (the link is broken), you get control from your ISP now: "RoadRunner users can disable this function."
Though I'd be a little surprised if OpenDNS didn't give you a way to disable the guide, I don't see anything on the page your parent linked that says you can.
Seems like the "processor hours" metric needs some adjustment to account for multi-core. Otherwise I could build one of these with 15,744 single-core processors and claim the same performance.
Why are you associating processor-hours with performance anyway? You could hook up 15,744 286s and get the same number of processor-hours too. So why don't you complain about that?
Not just that, but graphics drivers are a significant piece of tech in their own right anymore.
Know about shader programs? Those are compiled by a JIT compiler in the driver, at runtime. If nVidia or ATi believes that they have a better compiler that implements some optimizations that the other's doesn't, that could make them very reluctant to release the code.
Why is everyone in love with checksums?
Disk is cheap
But bandwidth, less so.
There's also a copyright issue. If the noscript people start distributing Google's gmail scripts, they leave themselves open to a cease & desist letter or a lawsuit. Distributing just a hash makes it easier to argue that.
If it didn't come with a whitelist it would be much better, but then even fewer people would use it.
Sure, some websites will take steps to make every bit of client-side scripting unique for every connection. They'll obfuscate their code, randomize the variable names on a per-session basis, mess with the structure... and now you KNOW those websites are hostile and malicious and should be treated as such.
It does seem likely, but it's not completely given that dynamically-generated scripts are malicious. You could think of putting some identifying information (a session ID) into the script somewhere, or something like that. (Google uses generated scripts (variable names replaced by a single letter and stuff like that) to save bandwidth, though I bet they do that offline then serve it statically.)
(That said, the hash-based version is subject to the same problem.)
For things like Slashdot and other dumb web forums? Yes. The convenience trumps the security risk. For my bank and school email accounts? No. But I didn't do that before anyway.
If you're asking "does anyone still think that it's a good idea to have the browser be able to store your passwords", the answer is definitely yes.
WTF is it with Microsoft and shift-click doing something useful?
Ever want an image of an Excel chart? For a long time, I would do it by hitting printscreen, pasting it into Paint, then cropping it. But there is a better way: select the chart, shift-click the edit menu, then choose the option "Copy Picture." I'm not sure I know what exactly the options do in the dialog that pops up, but that's a minor inconvenience compared to the old way.
Shift-delete immediately deletes a file instead of sending it to the recycle bin. In Vista, shift-right-click apparently adds a "command prompt here" option to the context menu.
"There are other ways to do this that don't require specific hardware. Google "Vista breadcrumbs". It takes 30 seconds to get used to it, but it's perfectly effective."
They aren't perfectly effective. I personally think most of this review is stupid, but the complaint that "With a directory that has a long name like that, the higher-level directories aren't visible in the address bar, so I had to locate it manually in the left-hand tree view panel" is something that I know he's not the only one to have experienced, because I have too. [That said, note to reviewer: see that triangle between the paths? Click it. It's still more annoying than just hitting 'up', but probably less than using the treeview.]
It also requires a little more locating. I know where 'up' is in XP relative to the Window, but in vista you have to read.
It seems to me the licensing prohibits you from including the OS when giving the PC away anyway
Huh? Where on earth did you get that idea? From the XP EULA:
"Transfer to Third Party. The initial user of the Software may make a one-time permanent transfer of this EULA and Software to another end user, provided the initial user retains no copies of the Software. This transfer must include all of the Software (including all component parts, the media and printed materials, any upgrades, this EULA, and, if applicable, the Certificate of Authenticity)."