Are you really proposing a solution where only people with a driver's license can vote?
Personally I don't see why US citizens are making a big deal about a national ID. You bunch are already abusing stuff like "driver's license" or SSN as a unique National ID when they are not designed for that (apparently SSNs aren't unique).
If you don't like the sound of "national ID", then call it a state ID or something;).
Isn't is too late to effectively shape incoming traffic by the time it reaches your modem/router?
For connectionless stuff it's too late. But in practice it works for TCP connections since if you start dropping/delaying packets the affected TCP connections will slow down.
And while most UDP stuff might be connectionless, there might be connection-like behaviour at the application level.
If that were truly the bottleneck, couldn't you get a faster connection just by buying a faster modem?
Whatever is the bottleneck affects the traffic the most. So if the ISP is the one limiting the speed of your connection, the ISP is the one controlling it.
So essentially what you are saying is that if he restricts his bandwidth so that he never buffers packets at the ISP (eliminates the bufferbloat), he won't have any problems? Wouldn't getting rid of the bufferbloat have the same effect without artificially restricting his bandwidth?
Not necessarily the same effect. Say he saturates his pipe and the ISP has small buffers, and starts dropping packets, the decision of which packets to drop will be done by devices under the ISP's control.
This decision may not be the same as the decision made by the device under his control. The ISP might just do the simple thing and treat all packets equally.
The ISP of course could do a good job and decide well enough that most users get good enough performance (low priority for bulk traffic, and low latency for latency sensitive traffic). But so far I doubt normal ISPs would do that sort of thing soon;). If they did, big buffers might not even be a problem at all.
But it still seems to me reducing buffer size is the wrong way to solve the latency problem.
How about routers that still have large buffers but also keep track of how long packets have been sitting around and drop those that are older than a few milliseconds (routers already do something similar but it's in seconds which is too long nowadays).
Thing is I'm not even sure he knows what he is talking about.
Does he or anybody still see the problem if he downloads at lower speeds? I If he doesn't then his ISP is buffering up his packets because he is saturating his connection, and there isn't any "bufferbloat" problem, at least in the way he is claiming. I personally don't experience the problem (I have other problems with my ISP[2] but "bufferbloat" isn't it;) ).
The fix is for him to do what me and others do: limit his download and upload speeds to something a bit below what the ISP actually provides to him (which may not be what he paid for - but that's a different story/gripe!;) ), and be the one that decides which packets he wants to drop rather than leave it to the ISP[1].
Basically the narrowest part of the pipe controls the speed of the flow.
Example: say he has a full-duplex 10Mbps connection. If he limits his downloads and uploads to 9.5Mbps and the ISP really provides 10Mbps to him there will be no buffering by the ISPs. Any buffering will be done by his system (assuming TCP traffic). A single slow website might only be able to give him 1Mbps, but that doesn't affect his other traffic - so no buffering there either.
He can then configure his system so that when his traffic goes past 9.5Mbps, it drops the packets he feels are less important.
[1] Yes in theory the ISP can guess what packets are latency sensitive and what aren't and do this for users (maybe even allow an opt out for advanced users), but most ISPs can barely keep their systems running and their priorities don't seem to be giving users better service so go figure;).
Note: the actual percentage may not be 95%, what you have to do is take into account the initial TCP bursts you will receive (or send).
[2] Sometimes my ISP gives me a 3% packet loss - believe me 3% packet loss screws up TCP more than whatever buffering currently exists. My ISP also doesn't give me 100% of what I paid for either - it gives me less than 48/53 of it (it's PPPoE over ATM over ADSL, ATM uses 53 byte cells with 48 byte payloads).
I don't think buffering is the real problem. Buffering can help with throughput especially TCP throughput.
For example if there is a brief burst of packets higher than a router's outbound connection bandwidth supports, the router has two options:
a) buffering or queuing up the packets (assuming enough buffer space), till the output queue empties. b) dropping the packets.
UDP latency doesn't go up if UDP packets are dropped - since there are no retransmissions.
But if TCP packets are dropped too often just because of bursts (from other connections), the speed drops significantly and the latency goes up a lot too - because the relevant parties have to wait for acks and retransmissions and the TCP window size also decreases. If the TCP packets are buffered, the TCP transmitter won't slow it's transmission rate drastically (it will still slow a bit when waiting for acks), but there would be a brief increase in latency for the period the packets are being buffered.
Trouble is if it's not a brief burst, it means you're just delaying the inevitable packet drops, meanwhile the sustained delay becomes more noticeable.
What the author doesn't seem to realize is the upstream network providers should buffer (within reason - even up to a few seconds worth) - because they usually don't know which of your packets are more important to you, and thus which packets to drop first.
The solution is for the network providers to have enough internal bandwidth so that THEIR buffers rarely start to fill up, and there is minimal packet loss, AND for the user to do traffic shaping and policying at their connection (and the servers too).
Say you have a 10Mbps connection, and the ISP actually does give you a full 10Mbps. If you download from a fast site, the packets queue up when they reach your 10Mbps connection before dropping and finally reaching and equilibrium at 10Mbps. But meanwhile your interactive ssh or game connections suffer from increased latency since they share the queue - as mentioned before the ISP doesn't know which packets/connections are more important to you (it can guess of course and favour small packets, ACKs, DNS; or you can give QOS hints, but most ISPs don't bother).
To prevent this, you get your modem/firewall to "shape" your traffic at say 9.5Mbps (leave enough headroom for the initial TCP connection bursts) and choose which packets you want to drop when it goes past 9.5Mbps (for instance drop http packets first instead of your interactive or VOIP stuff, or the other way round if http traffic is more important to you for some reason). This way you control what happens AND the buffers never fill up at the ISP end since the traffic doesn't even hit 10Mbps (if their buffers don't fill up, there is no increase in latency). This also applies to your outbound connections - if your upload bandwidth is 5Mbps, shape it at 4.5Mbps or so.
The narrowest part of the straw controls the flow. If the ISP is the narrowest part of the straw - the buffering and shaping is up to them. If your system is the narrowest part of the straw - it controls the flow.
If there's something wrong and somehow there's a 1Mbps bottleneck in the ISP for ALL your traffic, that bottleneck will control the flow - since it will drop packets before it reaches 9.5Mbps point where you start dropping packets - in which case the ISP is cheating you and giving you a 1Mbps connection (note though that if the 1Mbps bottleneck is only for some of the traffic your other traffic will be fine ).
Note: I'm assuming the case of sustained TCP connections, and lower UDP traffic speeds. This all doesn't work if some site is blasting UDP packets at 100Mbps to you[1].
[1] The UDP blasting could actually be a way of bypassing certain ISP throttling methods - sending lots of packets, and coping with packet loss by using forward error correction and some feedback. Fortunately not many are doing this yet:).
When's the last time you had a GPS "break" (not including things like running out of batteries and not having extras)?
You HAVE to include things like running out of batteries. That's the point of having the compass (and a physical map).
When it gets very cold, batteries often don't work so well, and the humans often stop working so well too. Not a good combination.
A decent compass and map will continue working even if it's cold enough to freeze your GPS screen.
If you're wandering about in a big dense city a GPS+map is better than a compass. If you're wandering around in the "wilds", you better have a compass and "hard copy map" as backup.
The other difference between mass vaccines and most "normal" drugs is, these vaccines are given to very large numbers of people who aren't sick.
So even if the vaccine (whether the preservatives, fillers, active ingredients or contaminants) only harms a tiny proportion of people who somehow don't deal with it well, and so doesn't show up in tests of say 1000 subjects, it can still cause problems when millions get it.
If you inject something into millions of people, why should we be surprised if some people actually have a bad reaction to it, or even deny the possibility of it?
But if the affected are few then it can be considered "collateral damage". It's only not collateral damage if the numbers harmed are greater than the numbers harmed by the disease itself - in which case it becomes a self-inflicted "pandemic".
Basically the safety standards for mass vaccines have to be higher than for "normal" drugs.
However, when I observe PCs stall with no significant cpu activity and no disk activity... if it were thrashing ram there should be disk activity. No, those stalls have got to be something else.
Checking for online updates? Or commands from the bot master?:p
Another thing is most timeouts are set on a human scale: e.g. seconds or even minutes.
Sometimes there are good reasons for this. Whatever they are, in many cases it means that if there is an exception you have to wait for a human scale interval, in some cases you have to wait even if there are no exceptions ( pauses just in case a human wants to override something, or to show stuff to the human - splashpage or eyecandy UI animation).
Thanks for the tip! Wonder if it'll work with my Win 7 setup - currently I ungroup all the windows, so that I only need to "one click" directly on the task button I want.
Imagine what a concert pianist will think if the piano keyboard did "key personalization". Or grouped keys together so you have to hover over a key first for a few hundred milliseconds to be able to press the key you want;).
Sadly from what I see the GNOME and KDE bunch aren't better. OS X's Expose isn't for me either (have a Macbook on my work desktop, and I mostly use it via ssh;) ) - unnecessary steps just to get to the window I want.
So much of what UI designers are doing nowadays seem to be like the fancy cutscenes in games. The ones that look cool the first few times, but after that gamers want to skip to get to the "real stuff" ASAP. If those idiots designed guns, there'll be some unnecessary fancy animation and sound after you pull the trigger, before the gun actually fires. In games those fancy animations are often "handicaps" for game balance - they're not an advantage:).
They can also post orders AND cancel them before others can go through with the transaction. So if you have a simple automated system - they can figure out what your minimum/maximums/rules are.
Quote first link: "High-frequency traders often confound other investors by issuing and then canceling orders almost simultaneously. Loopholes in market rules give high-speed investors an early glance at how others are trading. And their computers can essentially bully slower investors into giving up profits -- and then disappear before anyone even knows they were there. "
Yeah agree with you on most stuff. I have my Win XP classic menu set up similar to your scheme too. So Winkey, 1, 1 = "1 Explore Desktop". Been doing that since Win95 (Win 98 had a bug where if you press winkey too early while booting, stuff breaks:) ).
I've got quicklaunch on Win 7, I think I did that by switching to a "classic" mode. Don't recall doing much "hacking".
The Win 7 start menu search is non-deterministic so if you don't want to make mistakes you have to wait to see what actually pops up before pressing enter. Non-deterministic stuff like these and "Personalized Menus" don't help as much as a good deterministic UI.
I dislike some of the new Win 7 UI stuff, for example the "Network and Sharing Center".To me it doesn't help the noobs nor the expert users. The noobs don't normally do such stuff on their own so you might as well design it to make it easier for someone to talk them through stuff over the phone. The experts? They don't need graphics targeted at noobs. If there are graphics it should tell them something useful in a concise and deterministic manner.
Same goes for the much of the flashy window management stuff: The preview of thumbnailed windows in Win 7 and OS X might be nice if you have a few windows, but pretty much useless if you have > 20 windows open.
In my opinion if you only have a few windows open, you don't really need previews to tell you which windows are which;). Where the UI makes the diff is in helping a user manage many tasks/windows.
An OS should help new users, but it should also have ways to augment users who bother to learn the shortcuts or are trained.
Analogy: any crappy OS can handle one or two processes. A good OS handles dozens or hundreds of processes well.
Example: Windows 7 allows you to switch among apps by pressing winkey+number. However it raises the first window of the relevant app, not the most recently used window. This is fine if you only have one window open per app. But doing MRU would help in both the "few windows" case and the many windows case.
FWIW, I wrote "LinkKey" to do stuff like link alt+number to arbitrary windows- which is nice if I need to work with more than two windows at the same time (for two windows - alt-tab works). For example, say I have to refer to one or two windows (reference docs) and then work with two other windows based on the reference docs.
I could do lots of clicking, but the GUI should help if it can. It's sad if "unix screen" beats a "modern" GUI in task management.
You can't drag&drop a file from explorer to cmd to get there full pathname.
I just checked. I can do it.
There are times when that doesn't work, for example when the cmd shell is running as a different user from the explorer.
The stuff I like about Windows 7: - task buttons are grouped by apps - per app volume control - the search thingy when it works. - filesystem is 4KB aligned by default.
The stuff I don't like about windows 7: - Lots of stuff changed for no apparent good reason - Lots of stuff more cluttered: for example the Network Sharing Center is a mess, it doesn't really help the noobs, nor does it help the experts. - Windows Explorer often insists on "calculating" stuff rather than actually doing stuff. - the search thingy when it doesn't work:). I often have to type the entire name out. - the search thingy prevents me from using the start menu short cut system I've been using for Win 95/2K/XP (create folders/shortcuts and subfolders in the start menu that start with a number or letter, then use winkey, letter/number to launch the stuff).
Slashdot Mirror
Are you really proposing a solution where only people with a driver's license can vote?
;).
Personally I don't see why US citizens are making a big deal about a national ID. You bunch are already abusing stuff like "driver's license" or SSN as a unique National ID when they are not designed for that (apparently SSNs aren't unique).
If you don't like the sound of "national ID", then call it a state ID or something
Many people often come up with great things to do just to procrastinate...
Isn't is too late to effectively shape incoming traffic by the time it reaches your modem/router?
For connectionless stuff it's too late. But in practice it works for TCP connections since if you start dropping/delaying packets the affected TCP connections will slow down.
And while most UDP stuff might be connectionless, there might be connection-like behaviour at the application level.
If that were truly the bottleneck, couldn't you get a faster connection just by buying a faster modem?
Whatever is the bottleneck affects the traffic the most. So if the ISP is the one limiting the speed of your connection, the ISP is the one controlling it.
So essentially what you are saying is that if he restricts his bandwidth so that he never buffers packets at the ISP (eliminates the bufferbloat), he won't have any problems? Wouldn't getting rid of the bufferbloat have the same effect without artificially restricting his bandwidth?
Not necessarily the same effect. Say he saturates his pipe and the ISP has small buffers, and starts dropping packets, the decision of which packets to drop will be done by devices under the ISP's control.
This decision may not be the same as the decision made by the device under his control. The ISP might just do the simple thing and treat all packets equally.
The ISP of course could do a good job and decide well enough that most users get good enough performance (low priority for bulk traffic, and low latency for latency sensitive traffic). But so far I doubt normal ISPs would do that sort of thing soon ;). If they did, big buffers might not even be a problem at all.
Because Intel can laugh at Lenovo if Lenovo said that today.
Intel couldn't laugh at the "two source" requirement back then.
But it still seems to me reducing buffer size is the wrong way to solve the latency problem.
How about routers that still have large buffers but also keep track of how long packets have been sitting around and drop those that are older than a few milliseconds (routers already do something similar but it's in seconds which is too long nowadays).
Thing is I'm not even sure he knows what he is talking about.
;) ).
;) ), and be the one that decides which packets he wants to drop rather than leave it to the ISP[1].
;).
Does he or anybody still see the problem if he downloads at lower speeds? I If he doesn't then his ISP is buffering up his packets because he is saturating his connection, and there isn't any "bufferbloat" problem, at least in the way he is claiming. I personally don't experience the problem (I have other problems with my ISP[2] but "bufferbloat" isn't it
The fix is for him to do what me and others do: limit his download and upload speeds to something a bit below what the ISP actually provides to him (which may not be what he paid for - but that's a different story/gripe!
Basically the narrowest part of the pipe controls the speed of the flow.
Example: say he has a full-duplex 10Mbps connection. If he limits his downloads and uploads to 9.5Mbps and the ISP really provides 10Mbps to him there will be no buffering by the ISPs. Any buffering will be done by his system (assuming TCP traffic). A single slow website might only be able to give him 1Mbps, but that doesn't affect his other traffic - so no buffering there either.
He can then configure his system so that when his traffic goes past 9.5Mbps, it drops the packets he feels are less important.
[1] Yes in theory the ISP can guess what packets are latency sensitive and what aren't and do this for users (maybe even allow an opt out for advanced users), but most ISPs can barely keep their systems running and their priorities don't seem to be giving users better service so go figure
Note: the actual percentage may not be 95%, what you have to do is take into account the initial TCP bursts you will receive (or send).
[2] Sometimes my ISP gives me a 3% packet loss - believe me 3% packet loss screws up TCP more than whatever buffering currently exists. My ISP also doesn't give me 100% of what I paid for either - it gives me less than 48/53 of it (it's PPPoE over ATM over ADSL, ATM uses 53 byte cells with 48 byte payloads).
I don't think buffering is the real problem. Buffering can help with throughput especially TCP throughput.
:).
For example if there is a brief burst of packets higher than a router's outbound connection bandwidth supports, the router has two options:
a) buffering or queuing up the packets (assuming enough buffer space), till the output queue empties.
b) dropping the packets.
UDP latency doesn't go up if UDP packets are dropped - since there are no retransmissions.
But if TCP packets are dropped too often just because of bursts (from other connections), the speed drops significantly and the latency goes up a lot too - because the relevant parties have to wait for acks and retransmissions and the TCP window size also decreases. If the TCP packets are buffered, the TCP transmitter won't slow it's transmission rate drastically (it will still slow a bit when waiting for acks), but there would be a brief increase in latency for the period the packets are being buffered.
Trouble is if it's not a brief burst, it means you're just delaying the inevitable packet drops, meanwhile the sustained delay becomes more noticeable.
What the author doesn't seem to realize is the upstream network providers should buffer (within reason - even up to a few seconds worth) - because they usually don't know which of your packets are more important to you, and thus which packets to drop first.
The solution is for the network providers to have enough internal bandwidth so that THEIR buffers rarely start to fill up, and there is minimal packet loss, AND for the user to do traffic shaping and policying at their connection (and the servers too).
Say you have a 10Mbps connection, and the ISP actually does give you a full 10Mbps. If you download from a fast site, the packets queue up when they reach your 10Mbps connection before dropping and finally reaching and equilibrium at 10Mbps. But meanwhile your interactive ssh or game connections suffer from increased latency since they share the queue - as mentioned before the ISP doesn't know which packets/connections are more important to you (it can guess of course and favour small packets, ACKs, DNS; or you can give QOS hints, but most ISPs don't bother).
To prevent this, you get your modem/firewall to "shape" your traffic at say 9.5Mbps (leave enough headroom for the initial TCP connection bursts) and choose which packets you want to drop when it goes past 9.5Mbps (for instance drop http packets first instead of your interactive or VOIP stuff, or the other way round if http traffic is more important to you for some reason). This way you control what happens AND the buffers never fill up at the ISP end since the traffic doesn't even hit 10Mbps (if their buffers don't fill up, there is no increase in latency). This also applies to your outbound connections - if your upload bandwidth is 5Mbps, shape it at 4.5Mbps or so.
The narrowest part of the straw controls the flow. If the ISP is the narrowest part of the straw - the buffering and shaping is up to them. If your system is the narrowest part of the straw - it controls the flow.
If there's something wrong and somehow there's a 1Mbps bottleneck in the ISP for ALL your traffic, that bottleneck will control the flow - since it will drop packets before it reaches 9.5Mbps point where you start dropping packets - in which case the ISP is cheating you and giving you a 1Mbps connection (note though that if the 1Mbps bottleneck is only for some of the traffic your other traffic will be fine ).
Note: I'm assuming the case of sustained TCP connections, and lower UDP traffic speeds. This all doesn't work if some site is blasting UDP packets at 100Mbps to you[1].
[1] The UDP blasting could actually be a way of bypassing certain ISP throttling methods - sending lots of packets, and coping with packet loss by using forward error correction and some feedback. Fortunately not many are doing this yet
Yes. Sharing files that are too big to be emailed.
When's the last time you had a GPS "break" (not including things like running out of batteries and not having extras)?
You HAVE to include things like running out of batteries. That's the point of having the compass (and a physical map).
When it gets very cold, batteries often don't work so well, and the humans often stop working so well too. Not a good combination.
A decent compass and map will continue working even if it's cold enough to freeze your GPS screen.
If you're wandering about in a big dense city a GPS+map is better than a compass. If you're wandering around in the "wilds", you better have a compass and "hard copy map" as backup.
When flying, you use English because every pilot can talk to every other pilot and every controller across the planet.
But when crashing you use French :).
http://en.wikipedia.org/wiki/Mayday_(distress_signal)#History
I vaguely remember Sundog... My cousin used to play it on his computer decades ago.
I'm curious: how do you feel about the emulator versions of Sundog being easily downloadable on the Internet?
You don't make any sense with your whole injection vs digestion argument
If you still think there is no difference between eating something and injecting it, then you're either stupid or ignorant.
Don't blame me if you can't understand simple stuff. The last I checked it says "news for nerds" not "news for retards".
Maybe you've been exposed to too much mercury and are now suffering a neurological deficit.
p.s. in case your feeble mind can't keep track: you started the hostility first.
You get more mercury from a tuna sandwich than you do from vaccines.
Injecting something in a few seconds is quite different from ingesting and digesting over more than a few minutes.
People don't normally inject tuna sandwiches into their bodies. So even if there are 85 micrograms of mercury in the sandwich it's not the same as 25 micrograms of mercury in a vaccine ( http://www.fda.gov/BiologicsBloodVaccines/SafetyAvailability/VaccineSafety/UCM096228 ). And that's assuming a tuna sandwich with 100 grams of tuna at the max mercury levels stated in: http://www.fda.gov/food/foodsafety/product-specificinformation/seafood/foodbornepathogenscontaminants/methylmercury/ucm115644.htm
Note: I'm assuming that a PPM value of 0.118 (the average level) would mean that 100g of tuna will contain 11.8 micrograms of mercury.
The other difference between mass vaccines and most "normal" drugs is, these vaccines are given to very large numbers of people who aren't sick.
So even if the vaccine (whether the preservatives, fillers, active ingredients or contaminants) only harms a tiny proportion of people who somehow don't deal with it well, and so doesn't show up in tests of say 1000 subjects, it can still cause problems when millions get it.
If you inject something into millions of people, why should we be surprised if some people actually have a bad reaction to it, or even deny the possibility of it?
But if the affected are few then it can be considered "collateral damage". It's only not collateral damage if the numbers harmed are greater than the numbers harmed by the disease itself - in which case it becomes a self-inflicted "pandemic".
Basically the safety standards for mass vaccines have to be higher than for "normal" drugs.
The world just exists in 4 dimensions; it doesn't change.
What's the evidence for this?
see page 4 for btrfs random write performance, which blows away both zfs and ext4 on hdds.
I'd rather have data integrity and SSD wear leveling and free read-only snapshots instead of maximum speed.
1) There are SSDs with decent random write performance now.
2) Shouldn't the SSD wear leveling be done by the SSDs themselves?
In terms of performance and everything else that matters, the removal of the BKL has absolutely no impact.
How about reliability and stability? So they've reached the stage where stuff _definitely_ doesn't need the BKL?
The local guy has the edge on figuring out what donuts the local people like? :)
Absolutely true considering we ARE running out of money
I dunno, when I last checked there's lots more where it's coming from...
However, when I observe PCs stall with no significant cpu activity and no disk activity... if it were thrashing ram there should be disk activity. No, those stalls have got to be something else.
Checking for online updates? Or commands from the bot master? :p
Another thing is most timeouts are set on a human scale: e.g. seconds or even minutes.
Sometimes there are good reasons for this. Whatever they are, in many cases it means that if there is an exception you have to wait for a human scale interval, in some cases you have to wait even if there are no exceptions ( pauses just in case a human wants to override something, or to show stuff to the human - splashpage or eyecandy UI animation).
Thanks for the tip! Wonder if it'll work with my Win 7 setup - currently I ungroup all the windows, so that I only need to "one click" directly on the task button I want.
;).
;) ) - unnecessary steps just to get to the window I want.
:).
Imagine what a concert pianist will think if the piano keyboard did "key personalization". Or grouped keys together so you have to hover over a key first for a few hundred milliseconds to be able to press the key you want
Sadly from what I see the GNOME and KDE bunch aren't better. OS X's Expose isn't for me either (have a Macbook on my work desktop, and I mostly use it via ssh
So much of what UI designers are doing nowadays seem to be like the fancy cutscenes in games. The ones that look cool the first few times, but after that gamers want to skip to get to the "real stuff" ASAP. If those idiots designed guns, there'll be some unnecessary fancy animation and sound after you pull the trigger, before the gun actually fires. In games those fancy animations are often "handicaps" for game balance - they're not an advantage
That reminds me- check out the new task scheduler UI. Microsoft's UI bunch seem to have lost their way.
There must be a better way... As the (perl?) saying goes: "easy things easy, hard things possible".
So they should make "popular/common tasks easy and advanced stuff possible".
What do you mean by this? The market enforces rules as to which orders are first in the queue.
Unfair rules in this context. They get to be 30 milliseconds ahead of everyone:
http://www.nytimes.com/2009/07/24/business/24trading.html
http://www.nytimes.com/imagepages/2009/07/24/business/0724-webBIZ-trading.ready.html
They can also post orders AND cancel them before others can go through with the transaction. So if you have a simple automated system - they can figure out what your minimum/maximums/rules are.
Quote first link: "High-frequency traders often confound other investors by issuing and then canceling orders almost simultaneously. Loopholes in market rules give high-speed investors an early glance at how others are trading. And their computers can essentially bully slower investors into giving up profits -- and then disappear before anyone even knows they were there. "
Yeah agree with you on most stuff. I have my Win XP classic menu set up similar to your scheme too. So Winkey, 1, 1 = "1 Explore Desktop". Been doing that since Win95 (Win 98 had a bug where if you press winkey too early while booting, stuff breaks :) ).
;). Where the UI makes the diff is in helping a user manage many tasks/windows.
I've got quicklaunch on Win 7, I think I did that by switching to a "classic" mode. Don't recall doing much "hacking".
The Win 7 start menu search is non-deterministic so if you don't want to make mistakes you have to wait to see what actually pops up before pressing enter. Non-deterministic stuff like these and "Personalized Menus" don't help as much as a good deterministic UI.
I dislike some of the new Win 7 UI stuff, for example the "Network and Sharing Center".To me it doesn't help the noobs nor the expert users. The noobs don't normally do such stuff on their own so you might as well design it to make it easier for someone to talk them through stuff over the phone. The experts? They don't need graphics targeted at noobs. If there are graphics it should tell them something useful in a concise and deterministic manner.
Same goes for the much of the flashy window management stuff: The preview of thumbnailed windows in Win 7 and OS X might be nice if you have a few windows, but pretty much useless if you have > 20 windows open.
In my opinion if you only have a few windows open, you don't really need previews to tell you which windows are which
An OS should help new users, but it should also have ways to augment users who bother to learn the shortcuts or are trained.
Analogy: any crappy OS can handle one or two processes. A good OS handles dozens or hundreds of processes well.
Example: Windows 7 allows you to switch among apps by pressing winkey+number. However it raises the first window of the relevant app, not the most recently used window. This is fine if you only have one window open per app. But doing MRU would help in both the "few windows" case and the many windows case.
FWIW, I wrote "LinkKey" to do stuff like link alt+number to arbitrary windows- which is nice if I need to work with more than two windows at the same time (for two windows - alt-tab works). For example, say I have to refer to one or two windows (reference docs) and then work with two other windows based on the reference docs.
I could do lots of clicking, but the GUI should help if it can. It's sad if "unix screen" beats a "modern" GUI in task management.
You can't drag&drop a file from explorer to cmd to get there full pathname.
I just checked. I can do it.
There are times when that doesn't work, for example when the cmd shell is running as a different user from the explorer.
The stuff I like about Windows 7:
- task buttons are grouped by apps
- per app volume control
- the search thingy when it works.
- filesystem is 4KB aligned by default.
The stuff I don't like about windows 7: :). I often have to type the entire name out.
- Lots of stuff changed for no apparent good reason
- Lots of stuff more cluttered: for example the Network Sharing Center is a mess, it doesn't really help the noobs, nor does it help the experts.
- Windows Explorer often insists on "calculating" stuff rather than actually doing stuff.
- the search thingy when it doesn't work
- the search thingy prevents me from using the start menu short cut system I've been using for Win 95/2K/XP (create folders/shortcuts and subfolders in the start menu that start with a number or letter, then use winkey, letter/number to launch the stuff).