A lot of what you say I agree with. I think MS needs more coherence and better leadership. But...
For 30 years, people have understood file directory trees. That's why so many users can use windows explorer so seemlessly.
I'm not sure how true this is for the masses. It'd be an interesting experiment.
Vista's menu sucked. Extra clicks to get to the directory tree...
But added search, which cut out 98% of needing to get to the tree, for me. (I also liked the XP menu better than the 95-2K because of the recent applications.)
I hate the things that got worse from XP to Vista as much as the next person, but the addition of the search made up for it -- and more, by a longshot. (And besides, I'm not sure what "extra clicks" you refer to unless you're talking about the scrolling.)
kept recent documents there (I do NOT want the next user to know I was looking a text file called "Debbie does Dallas"
Even Windows 95 kept recent documents in the start menu. Unless you're turning around from complaining about extra clicks to now complaining about fewer clicks.
Then came 7. Even worse. Libraries? Totally screwed up.
I don't even get what the libraries are doing, really. I just ignore them.
ACPI has the soft-off: if you press the button, what happens. That's definitely up to the OS, and you can choose what you want it to do (shut down, sleep, hibernate, nothing) on every OS I've seen.
However, usually there's a hard-off: hold down the button for a few seconds (I think usually 3-5) and it will turn off immediately. I'm 99% sure that is a BIOS thing (if even that gives you a choice) even given what Viewsonic said. With no offense to him, I'd be more inclined to think that he's wrong about his inference, or that his laptop is strange.
And on that note, Space Monger is fantastic for managing files. I use it quite frequently. Scrolling, zooming, and visually shows the size of files.
You might want to check out Windirstat if you don't know about it. I haven't used Space Monger, but they look relatively similar in concept, and I have similar superlatives about Windirstat as you for Space Monger.
There's a Linux version (actually I think this came first) called KDirStat.
(You seem to describe Space Monger as a "file manager" which is not how I would describe Windirstat, so it's possible that it does something else. I'm not sure though.)
...except that the initial pane is now most recently used programs or programs you pin there, while a sticky menu item allows to to expand the same old, reliable Xp-style start menu that is actually still there... in a way that is utterly infuriating to navigate in comparison. I strongly prefer the Vista/7 start menu because of the search (see above), but for a while I wanted to strangle someone every time I had to actually drop into the 'all programs' portion. It turns a very fast operation -- scanning over the list with your eyes, or perhaps even going right for what you want -- into a far slower operation -- scrolling.
I no longer get the urge to commit homicide, but I still get annoyed.
I don't care what you call it, but you can pry that key out of my dead fingers. I hit the Windows key 10 times more per unit time on Linux than I do on Windows.
I have a nice rule I adhere to: keyboard shortcuts not involving the Windows key are for programs. Keyboard shortcuts with the Windows key are for the window manager (switching desktops, opening a run dialog, reordering windows, etc.). Works really really well for me. I have too many WM shortcuts to use just ctrl or alt with them, and I use the WM shortcuts enough that having to do ctrl-alt or something like that would get really annoying really fast.
I think KDE had something similar since 4.x, though.
I have done some investigation into who had the idea first in the past. Vista was released late 2006, KDE 4 in late 2008. However, I traced the search box back a bit before then; I think Suse had it in their build of KDE for quite some time before then.
I don't really remember what the conclusion was, but I think it was that I couldn't come up with anything conclusively. In terms of determining who had the idea first, it was reasonably similar in time.
But yeah, anyone who says it's just tab completion hasn't used one or the other.
Other than search and a few other minor things, the XP start menu is better.
I'm a CLI person to some extent*, so I'm sure that biases my opinions, but to me that's like saying "except for the fact that IPS panels have way better colors and viewing angles, cheap TN monitors are better than IPS."
IMO the search ability adds a world of different; I like the Vista/7 start menu way better than the XP menu solely on account of that. Sure, navigating through the menu sucks in comparison to XP, but the search feature not just closes that gap but blows past it.
* I actually hate most current CLIs, but they're the best we have at a lot of things, so I use them a lot of the time.
That's a pretty weak notion of double-dipping. After all, both ends take resources.
Imagine a hypothetical world where you could be called without any sender. You would be paying but the sender wouldn't (because there isn't one). So they'd be getting half the income. But they're also doing half the work, since there's no sending.
You can argue that service is too costly or should be billed differently (e.g. caller pays like Europe), but I would not say what they're doing really fits the definition of "double dipping".
It's not Cygwin. It's an implementation of the POSIX APIs that goes directly to the NT APIs instead of through Win32.
I can't comment much on the tradeoffs except to say that I think it solves the problem of Cygwin's fork() being terrible. (SUA also provides a route to get multiple files with the same case-folded name but different case-sensitive names, which I don't think you can do with Cygwin since it goes through the Win32 API.)
A computer can translate text to binary easily; the programming to do so is trivial.
If it's so easy, why do people so often get it wrong? How many shell scripts or commands break if you have even spaces in your file names, let alone weirder characters. (For example, if you've used xargs without the non-standard -0 flag, it was almost certainly wrong.)
I don't see how it's any more intuitive to recognize whether every component in a pipe chain is backed by a win32 exe or a cmdlet versus memorizing some commands strip out color codes when piped
I'm not saying it's more intuitive, I'm saying it's possible. If you don't remember whether something is an exe or a cmdlet, you can find that out easily. If you want to know whether a program behaves differently when piping or attached to a console, there's no way to figure that out. Maybe it says in the man page. Maybe you can test it (but will one test be representative, or will that very depending on your command line flags and environment variables?). The only real way to know is go look at the code.
I can't think of an example that does something more drastic than stripping color codes
Personally I think that ls displaying columns (dir/w style) or not is more drastic, but that's just me. I actually have aliases that force color codes on for ls and grep so that they aren't stripped out and I can pass them around, so having to work around commands that do this mode switching isn't just some theoretical problem for me. (I also have less aliased to less -R and a decolor script to strip the escapes when I don't want them.)
Even the most recent PowerShell terminal is restricted in silly ways (won't let me make it wider than a certain bound, and I have no idea why).
Because the Windows terminal is an awful piece of software. You might take a look at PoshConsole. In a quick experiment, that seems to behave better on that front. I haven't used it enough to thoroughly evaulate though, but it seems to have some features that I think should be picked up my more terminals. (I like some of the thinking that went into this, though I'm not sure if I agree with many of the specific choices he made.)
(You do know that you can actually change the screen buffer size in preferences though, right? I am still limited to 210 characters, but it's better than 80.)
Re:BSODs are very often hardware related
on
Windows 8 Roundup
·
· Score: 1
The problem so they say is that drivers live below the kernel/user land divide. So when things go screwy with the driver it is a kernel level fault and often knocks the whole OS down. It was a poor design, but sadly as with a lot of Windows warts it stuck around because of compatibility reasons.
Well, for a long time it wasn't a bad design, because of performance reasons. The same design is shared by basically all of the other remotely-popular OSes as well. In fact, my impression is MS is trying to move away from that model more than anyone else is. The driver model in Vista already pushed several kinds of drivers into userspace.
Hmm, so now that I remember more about what he said (I read that article about a month ago), it may not be as big of a problem as I was thinking. As long as opening a file would work with both spaces and NBSPs, I think it would be fine.
(Though again I would slightly refine the idea and suggest doing a translation on both sides: on open translate NBSP to 0x20, and store it as 0x20 on disk, then on readdir and such translate 0x20 to NBSP. This would go a long way to preserving compatibilities with other systems.)
And conversely, binary is program-readable and text is not. If you're piping from one program to another, this can often matter -- because now your second program will have to reparse the output. And that's often obnoxious at best and wrong at worst. (I debate more about this below.)
yet I have to reboot every few days because something needed updating.
What are you doing to your poor computer? I only need to update after each patch Tuesday. Sure, that's really annoying (and to be honest I usually leave it sitting there pleading to shut down and install updates for a few weeks), but it's far from "every few days".
And, of course, regarding awk; it's still usually easier to remember that, e.g., ls will give you the mtime in the LastWriteTime field as opposed to fields 6-8.
I am sure, however, that there will be cases where this will not do what you want e.g. if you need to change the delimiter or something to that effect
Or if your column can have spaces.:-)
Agreed, though the article points out an easy solution to that also: a nonbreaking space should be the default for filenames that have spaces
Actually, I kind of like that solution (especially paired with a kernel modification to translate between nonbreaking spaces being presented to the outside world and normal spaces on disk -- to promote interoperability), but it's only "easy" in a pretty strange sense of that word considering that it isn't backwards compatible and there's not a good way to type a NBSP.
My point was not that I never saw a table, it is that you are exaggerating when you claim that it is a matter of remember which of nearly 50 columns has the data one is looking for.
Oh, I see. No, when I said "column 50" I was referring to character column numbers, which you'd pass to cut -c##. I haven't had much luck with -f specifiers for typical output. Maybe I'm just stupid or something, but I can't figure out how to make it treat several spaces in a row (there so columns line up visually) as a single separator.
as the article points out, simply forbidding files with malformed names would go a long way toward solving the problem, and there is no good reason for a filename to contain things like control characters or to have a hyphen as its first character.
Sure, but a lot of present solutions even break if you have spaces in file names -- and prohibiting that is, in my strong opinion, neither desirable nor realistic.
The point is in Unix, what you see is what you get. If ps did output binary, the user would see binary and an app downstream of a pipe would see binary.
Well, that's only sort of true. What about the programs that autodetect whether they are running on a terminal? Why is the output from ls different from ls | cat? You could easily have a situation where you run some command, look at the output, then pipe it into awk '{print $4}', and have it not do what you expect.
Granted, this in some sense a lot less extreme, but in another sense it's even worse. I can tell if the PS example is going to "malfunction" by looking at whether each command is a PowerShell command or not; you can only tell whether the ls | cat-like example is going to malfunction by looking at the code to ls (or by trying it).
(That being said, I tried ps | cat in the probably-old version of PowerShell I have installed on my laptop (2.0) and it basically crashed the console. I'd like to see more smarts here.)
You have chmod for traditional permissions, and setfacl/getfacl for advanced permissions (ACLs), you can use these same commands/functions for files, configuration (which are also files) and device drivers (which have files in/dev). On windows you only have advanced permissions, and no simple option. You then have a set of functions for filesystem permissions, a different set for registry permissions and another set for driver permissions.
I agree that this is a problem, but at the same time, it's just inconsistency on a different axis.
If unix permissions don't provide what you need, then chances are your needs are quite advanced and you are in a tiny niche, in which case you can learn how to use ACLs because modern unixes have these too.
Maybe I'm biased because of my position in academia (as a grad student), but it seems to me that the need to be able to manage your own groups and use them for file system permissions is reasonably common (a-couple-times-a-semester common), and that this need is shared from undergrads through professors. Undergrads would need to do it more common, professors less (at least if you can assume that groups like "the members of my class" are administered formally).
May not be the common case overall, but I wouldn't exactly tall that a "tiny niche".
If you're using any OS permissions system just to set up access for one or two users, then you're doing it wrong. I've literally seen guys who have set up server shares where folders and files have permissions for individual users.
Um, so what exactly should I have done?
Oh, and we've had POSIX ACLs for how long now?
Sorry, I didn't mean to imply that *nix is still deficient in this matter, just address the insinuation that because they aren't used all that much means they aren't important.
Slashdot Mirror
A lot of what you say I agree with. I think MS needs more coherence and better leadership. But...
For 30 years, people have understood file directory trees. That's why so many users can use windows explorer so seemlessly.
I'm not sure how true this is for the masses. It'd be an interesting experiment.
Vista's menu sucked. Extra clicks to get to the directory tree...
But added search, which cut out 98% of needing to get to the tree, for me. (I also liked the XP menu better than the 95-2K because of the recent applications.)
I hate the things that got worse from XP to Vista as much as the next person, but the addition of the search made up for it -- and more, by a longshot. (And besides, I'm not sure what "extra clicks" you refer to unless you're talking about the scrolling.)
kept recent documents there (I do NOT want the next user to know I was looking a text file called "Debbie does Dallas"
Even Windows 95 kept recent documents in the start menu. Unless you're turning around from complaining about extra clicks to now complaining about fewer clicks.
Then came 7. Even worse. Libraries? Totally screwed up.
I don't even get what the libraries are doing, really. I just ignore them.
ACPI has the soft-off: if you press the button, what happens. That's definitely up to the OS, and you can choose what you want it to do (shut down, sleep, hibernate, nothing) on every OS I've seen.
However, usually there's a hard-off: hold down the button for a few seconds (I think usually 3-5) and it will turn off immediately. I'm 99% sure that is a BIOS thing (if even that gives you a choice) even given what Viewsonic said. With no offense to him, I'd be more inclined to think that he's wrong about his inference, or that his laptop is strange.
And on that note, Space Monger is fantastic for managing files. I use it quite frequently. Scrolling, zooming, and visually shows the size of files.
You might want to check out Windirstat if you don't know about it. I haven't used Space Monger, but they look relatively similar in concept, and I have similar superlatives about Windirstat as you for Space Monger.
There's a Linux version (actually I think this came first) called KDirStat.
(You seem to describe Space Monger as a "file manager" which is not how I would describe Windirstat, so it's possible that it does something else. I'm not sure though.)
lt+F2 on KDE4 works basically like launchy. (with many additional features, like calculator)
I can't compare the two completely (I use Xmonad on Linux, not KDE), but.. if only Launchy came with such a feature.
...except that the initial pane is now most recently used programs or programs you pin there, while a sticky menu item allows to to expand the same old, reliable Xp-style start menu that is actually still there ... in a way that is utterly infuriating to navigate in comparison. I strongly prefer the Vista/7 start menu because of the search (see above), but for a while I wanted to strangle someone every time I had to actually drop into the 'all programs' portion. It turns a very fast operation -- scanning over the list with your eyes, or perhaps even going right for what you want -- into a far slower operation -- scrolling.
I no longer get the urge to commit homicide, but I still get annoyed.
Everyone in their usability tests.
I don't care what you call it, but you can pry that key out of my dead fingers. I hit the Windows key 10 times more per unit time on Linux than I do on Windows.
I have a nice rule I adhere to: keyboard shortcuts not involving the Windows key are for programs. Keyboard shortcuts with the Windows key are for the window manager (switching desktops, opening a run dialog, reordering windows, etc.). Works really really well for me. I have too many WM shortcuts to use just ctrl or alt with them, and I use the WM shortcuts enough that having to do ctrl-alt or something like that would get really annoying really fast.
I think KDE had something similar since 4.x, though.
I have done some investigation into who had the idea first in the past. Vista was released late 2006, KDE 4 in late 2008. However, I traced the search box back a bit before then; I think Suse had it in their build of KDE for quite some time before then.
I don't really remember what the conclusion was, but I think it was that I couldn't come up with anything conclusively. In terms of determining who had the idea first, it was reasonably similar in time.
But yeah, anyone who says it's just tab completion hasn't used one or the other.
Other than search and a few other minor things, the XP start menu is better.
I'm a CLI person to some extent*, so I'm sure that biases my opinions, but to me that's like saying "except for the fact that IPS panels have way better colors and viewing angles, cheap TN monitors are better than IPS."
IMO the search ability adds a world of different; I like the Vista/7 start menu way better than the XP menu solely on account of that. Sure, navigating through the menu sucks in comparison to XP, but the search feature not just closes that gap but blows past it.
* I actually hate most current CLIs, but they're the best we have at a lot of things, so I use them a lot of the time.
That's a pretty weak notion of double-dipping. After all, both ends take resources.
Imagine a hypothetical world where you could be called without any sender. You would be paying but the sender wouldn't (because there isn't one). So they'd be getting half the income. But they're also doing half the work, since there's no sending.
You can argue that service is too costly or should be billed differently (e.g. caller pays like Europe), but I would not say what they're doing really fits the definition of "double dipping".
It's not Cygwin. It's an implementation of the POSIX APIs that goes directly to the NT APIs instead of through Win32.
I can't comment much on the tradeoffs except to say that I think it solves the problem of Cygwin's fork() being terrible. (SUA also provides a route to get multiple files with the same case-folded name but different case-sensitive names, which I don't think you can do with Cygwin since it goes through the Win32 API.)
Microsoft are a disgusting, disgraceful and unethical company.
In other words... they're a company?
A computer can translate text to binary easily; the programming to do so is trivial.
If it's so easy, why do people so often get it wrong? How many shell scripts or commands break if you have even spaces in your file names, let alone weirder characters. (For example, if you've used xargs without the non-standard -0 flag, it was almost certainly wrong.)
I don't see how it's any more intuitive to recognize whether every component in a pipe chain is backed by a win32 exe or a cmdlet versus memorizing some commands strip out color codes when piped
I'm not saying it's more intuitive, I'm saying it's possible. If you don't remember whether something is an exe or a cmdlet, you can find that out easily. If you want to know whether a program behaves differently when piping or attached to a console, there's no way to figure that out. Maybe it says in the man page. Maybe you can test it (but will one test be representative, or will that very depending on your command line flags and environment variables?). The only real way to know is go look at the code.
I can't think of an example that does something more drastic than stripping color codes
Personally I think that ls displaying columns (dir /w style) or not is more drastic, but that's just me. I actually have aliases that force color codes on for ls and grep so that they aren't stripped out and I can pass them around, so having to work around commands that do this mode switching isn't just some theoretical problem for me. (I also have less aliased to less -R and a decolor script to strip the escapes when I don't want them.)
Even the most recent PowerShell terminal is restricted in silly ways (won't let me make it wider than a certain bound, and I have no idea why).
Because the Windows terminal is an awful piece of software. You might take a look at PoshConsole. In a quick experiment, that seems to behave better on that front. I haven't used it enough to thoroughly evaulate though, but it seems to have some features that I think should be picked up my more terminals. (I like some of the thinking that went into this, though I'm not sure if I agree with many of the specific choices he made.)
(You do know that you can actually change the screen buffer size in preferences though, right? I am still limited to 210 characters, but it's better than 80.)
The problem so they say is that drivers live below the kernel/user land divide. So when things go screwy with the driver it is a kernel level fault and often knocks the whole OS down. It was a poor design, but sadly as with a lot of Windows warts it stuck around because of compatibility reasons.
Well, for a long time it wasn't a bad design, because of performance reasons. The same design is shared by basically all of the other remotely-popular OSes as well. In fact, my impression is MS is trying to move away from that model more than anyone else is. The driver model in Vista already pushed several kinds of drivers into userspace.
Hmm, so now that I remember more about what he said (I read that article about a month ago), it may not be as big of a problem as I was thinking. As long as opening a file would work with both spaces and NBSPs, I think it would be fine.
(Though again I would slightly refine the idea and suggest doing a translation on both sides: on open translate NBSP to 0x20, and store it as 0x20 on disk, then on readdir and such translate 0x20 to NBSP. This would go a long way to preserving compatibilities with other systems.)
I'd be surprised if we go extinct. I wouldn't be surprised if there's a famine sometime in the next century with casualties in the billions.
PowerShell (and it's "cmdlets") is one of those places where I wish Linux looked more like Windows...
Text is human-readable, binary is not.
And conversely, binary is program-readable and text is not. If you're piping from one program to another, this can often matter -- because now your second program will have to reparse the output. And that's often obnoxious at best and wrong at worst. (I debate more about this below.)
yet I have to reboot every few days because something needed updating.
What are you doing to your poor computer? I only need to update after each patch Tuesday. Sure, that's really annoying (and to be honest I usually leave it sitting there pleading to shut down and install updates for a few weeks), but it's far from "every few days".
And, of course, regarding awk; it's still usually easier to remember that, e.g., ls will give you the mtime in the LastWriteTime field as opposed to fields 6-8.
I am sure, however, that there will be cases where this will not do what you want e.g. if you need to change the delimiter or something to that effect
Or if your column can have spaces. :-)
Agreed, though the article points out an easy solution to that also: a nonbreaking space should be the default for filenames that have spaces
Actually, I kind of like that solution (especially paired with a kernel modification to translate between nonbreaking spaces being presented to the outside world and normal spaces on disk -- to promote interoperability), but it's only "easy" in a pretty strange sense of that word considering that it isn't backwards compatible and there's not a good way to type a NBSP.
My point was not that I never saw a table, it is that you are exaggerating when you claim that it is a matter of remember which of nearly 50 columns has the data one is looking for.
Oh, I see. No, when I said "column 50" I was referring to character column numbers, which you'd pass to cut -c##. I haven't had much luck with -f specifiers for typical output. Maybe I'm just stupid or something, but I can't figure out how to make it treat several spaces in a row (there so columns line up visually) as a single separator.
as the article points out, simply forbidding files with malformed names would go a long way toward solving the problem, and there is no good reason for a filename to contain things like control characters or to have a hyphen as its first character.
Sure, but a lot of present solutions even break if you have spaces in file names -- and prohibiting that is, in my strong opinion, neither desirable nor realistic.
The point is in Unix, what you see is what you get. If ps did output binary, the user would see binary and an app downstream of a pipe would see binary.
Well, that's only sort of true. What about the programs that autodetect whether they are running on a terminal? Why is the output from ls different from ls | cat? You could easily have a situation where you run some command, look at the output, then pipe it into awk '{print $4}', and have it not do what you expect.
Granted, this in some sense a lot less extreme, but in another sense it's even worse. I can tell if the PS example is going to "malfunction" by looking at whether each command is a PowerShell command or not; you can only tell whether the ls | cat-like example is going to malfunction by looking at the code to ls (or by trying it).
(That being said, I tried ps | cat in the probably-old version of PowerShell I have installed on my laptop (2.0) and it basically crashed the console. I'd like to see more smarts here.)
You have chmod for traditional permissions, and setfacl/getfacl for advanced permissions (ACLs), you can use these same commands/functions for files, configuration (which are also files) and device drivers (which have files in /dev). On windows you only have advanced permissions, and no simple option. You then have a set of functions for filesystem permissions, a different set for registry permissions and another set for driver permissions.
I agree that this is a problem, but at the same time, it's just inconsistency on a different axis.
If unix permissions don't provide what you need, then chances are your needs are quite advanced and you are in a tiny niche, in which case you can learn how to use ACLs because modern unixes have these too.
Maybe I'm biased because of my position in academia (as a grad student), but it seems to me that the need to be able to manage your own groups and use them for file system permissions is reasonably common (a-couple-times-a-semester common), and that this need is shared from undergrads through professors. Undergrads would need to do it more common, professors less (at least if you can assume that groups like "the members of my class" are administered formally).
May not be the common case overall, but I wouldn't exactly tall that a "tiny niche".
If you're using any OS permissions system just to set up access for one or two users, then you're doing it wrong. I've literally seen guys who have set up server shares where folders and files have permissions for individual users.
Um, so what exactly should I have done?
Oh, and we've had POSIX ACLs for how long now?
Sorry, I didn't mean to imply that *nix is still deficient in this matter, just address the insinuation that because they aren't used all that much means they aren't important.