Um, as someone who is somewhat (but not only somewhat) familiar with generics in both systems, I don't see anything in TFA's explanation which is misleading or incorrect, nor contradicted by your link. Care to elaborate on what you mean?
On the flip side you'll see some weird stuff like stores that won't let you order on the Sabbath. B&H Photo Video, one of the best camera stores in the US, is like that. They have a big, well designed, online ordering system. However it won't let you order on the Sabbath. You can browse, but if you try to place an order, it won't allow it, you have to wait, it won't queue it into the system. The servers don't get the day off, but they aren't allowed to take orders:).
Huh, I've noticed that, but never knew why (but never been dedicated enough in the answer to investigate). Thanks for the information.:-)
The second reason is interesting, and is sort of the biggest objection I could think of (I was considering homemade stuff).
However, the "there is no such free service" is not, because while that remains true states cannot require internet vendors to collect sales tax. It is a requirement of the bill that states would need to provide such a free service to require tax collection.
And if a business in such a State sells something to someone living in Kenner LA, they'll have to be able to figure sales tax for LA, Jefferson Parish, Kenner, and such sales tax holidays as might be applicable on any particular item at any particular time...
No, not really. If LA wants Amazon to pay LA sales tax, then LA must make freely available software or a service that will do said calculation for Amazon (and if said software gets it wrong, Amazon will not be liable for the difference).
I'm not entirely convinced that said system will always be easy to implement, and PRMan (I think that's the name of the poster) in a reply to a different post of mine points out an interesting privacy issue that I'm not sure what the answer is (/if there is one). But at the same time, I also think it's certainly conceivable that the law will impart a relatively low burden in terms of implementation cost.
Though again, I don't feel strongly one way or another about whether the law is "right" or "wrong".
Try telling that to anyone that works in tax with multiple states, they wouldn't stop laughing at you.
Care to elaborate any? Because theoretically at least, all the complications of what items are taxed at what rate are not in the hands of the retailers; they just integrate with a free service that provides that information. I haven't looked for anything like this, but I haven't heard any actual explanation of why such a system would be complex (e.g. "matching up UPCs is hard" or something like that).
I'm not saying it isn't, just that I'd like to know more.
First, many valid searches are also valid URLs. You likely never encounter this if you don't have a local intranet that you go to.
My contention is this is mostly just a problem with the decision procedure for what to do: if browsers were better about de-prioritizing search in favor of treating things which could be a URL as a potential URL, almost all of the problems with this I think would disappear. You'd have to do a very minor amount of effort if you wanted to do a search for a single word which was also a valid name on your internet.
Second, many typos of otherwise-valid URLs are indistinguishable from non-URLs and become searches. This can get confusing and also in the worst case leak some private information.
This is an interesting argument; actually I think it's one of the most convincing I've seen in this thread.
Third, there's the search provider.... you can add explicit text-based prefixes
If what you mean is what I think you mean (e.g. "g foo" can search google for foo, "w bar" will search wikipedia for bar), those prefixes are exactly why I like the combined bar as much as I do. I like it rather more than Firefox-style search providers in the search box. (And yes, Firefox supports keyword searches as well, as does Opera.)
Fourth, even without search in there the address bar is already multifunctional. Merging in search means that search terms must be wiped out after searching...
I think this is a minor problem which is outweighed by the benefits (like reduced clutter and, in practice, too-small search box)....and the current address must be wiped out to search.
This I don't see as a problem at all; or at least no more of a problem than the fact that you have to wipe out the current address to go to another address now.
Durrr, what? What you're talking about appears to me to be entirely orthogonal to the issue of whether the address bar searches or not, unless your contention is going to that URL will actually lead you to a search page.
It's not like when you type in a URL you get sent to to a Google page that says "hey, this is a URL, I'll do a silent redirection to the URL". It's the client side that decides whether it just navigates to the page or goes to the URL.
ooh! I know, the user is wanting to search for those on google!!
I entered both of those URLs along with an IP which is actually accessible to me into three different browsers (Chrome, Opera, and Firefox for Linux), and not once did I get a search. Opera and Firefox did add an explicit.com at the end of http://intranet/ and went to http://www.intranet.com./
I also tried just the IP addresses without the http:/// prefix, and not one of them led to a search page.
The only thing that did was entering "intranet" on its own. But turning on troll mode (though "troll mode with a point") for a second, that's not a URL; http://intranet/ is the URL. Your browser is already applying a heruistic (prefix the scheme) to arrive at the URL. After all, who's to say you didn't really intend https://intranet/? In some sense, all the browsers are doing in that case is applying a different heuristic that goes to a far less related page.
[1.] You can adjust the relative size of the search bar and the address bar manually. [2.] And it could have been done automatically.
(1) Yes, but that's extra work and can't be done from the keyboard (at least AFAIK). (2) I conceeded that point.
You only need one shortcut to switch focus to the either one, it just happens to be a different shortcut for each (as it should be)
Um, that's not a good response, because I disagree on the last assumption.
[1.] The firefox search box allows you to select different search providers already. and [2.] your keyword searches could have been incorporated there instead.
(1) I did mention that. Access isn't as good IMO. (2) Also conceed that point.
But hey, are we talking about how things are, or how they could be? Because if we're talking about how things are, then my first and third objections definitely currently apply. If we're talking about how things could be, then I submit it's also possible to make a combined bar work well enough that it addresses basically every concrete (i.e. not "they shouldn't be combined!") objection in this thread.
Either the guessing algorithm is dumb, and annoys the user, or it is really sophisticated, in which case it took probably away a huge amount of developer manpower to implement in a way that pleases both the "I want to shop for something vague" vague user and the "Shit, the system is down, we are losing $100,000 a minute, and this shitty browser is trying to do a search, which he can't do since the connection to the internet is down, and locks up while waiting for the time-out, instead of just going to the web fronted for the NAS!!".
I don't completely disagree with where you're coming from. I definitely recognize the conflict between "attempt to be user friendly and do a good job most of the time" and predictability (this is not even remotely the. only place it comes up), and I'll admit that I fall a little more on the first side than many power users. But at the same time, I think you'd be pretty hard-pressed to find a problem with "try DNS and if that doesn't work then search".
For instance, take your example. If your browser freezes because the internet is down and it can't hit the search provider, then it has bigger problems than URLs vs searches. And it wouldn't be not going to the NAS front end in such a situation if it didn't try to search; it would be not going to the "server not found" error page.
(And of course, that policy isn't what happens now with browsers, but it's also not a fundamental problem with the combined bar.)
In the comparison with ls and cat, a unified search/url input in the same GUI element you would basically have to type something like "http://xxxxx" to go to an url ans something like "search://xxxxx" to do a search, wo work like the CLI
But here's the thing: You can! What you say is already the situation! (Sort of.)
If you type http://url/ it will go to that URL and not try to search. And if you set up a keyword search and use it, then it is unambiguously not a URL (with a different syntax than search://, but same idea).
In fact, the broswer is already applying a heuristic when you enter an address -- it'll prepend http:/// After all, "google.com" is not a URL if I'm a dick and pedant. In some sense, the only thing that's changing is what sorts of heuristics are applied to things which aren't explicit URLs and aren't explicit searches in order to figure out where to go. I mean, take the internet in 20 years. Maybe it'll be the case that HTTPS is universal, and when you type in "example.com", your browser will assume you mean "https://example.com" instead. And that'll break things too! But that's okay, because "example.com" is fundamentally not an unambiguous request even now.
Can't do that by mashing keywords into the URL bar (as far as I know).
You can.
In Firefox, go to any website you want to set up a search for, right click on the search box, and choose "add keyword for this search". If you add, say, a keyword of "g" on Google, then "g foo" in your address bar will search Google. In Chrome, you'll choose "add as search engine."
Why am I focusing on "stuff" instead of the command? Hello! because that is what you are acting on. entering data into a command line is pointless without a command to run.
IMO, the line between data vs command is blurrier than you make it out to be. From some point of view, typing "example.com" into your browser is giving it data. But I'd argue it's just as reasonable to look at it is a command -- "go to example.com". I think this is even stronger with searches: "g blah" is a command saying "search Google for blah". So I think that it's not so outrageous for me to compare entering whatever into the address bar of a browser to entering "emacs" vs "ls".
The thing is, you already have full access to a perfectly useful search tool in the search box (on firefox).... This is a thing that has NO positive benefits, only negative.
There are at least three benefits, though admittedly two of them are merely deficiencies with the current implementation in Firefox:
1) Having a unified bar means that I can see both long URLs and long search queries. In Firefox, if I copy and paste an error message or something like that into the search box, it will almost certainly be too small to view the entire query. [This deficiency could be remedied by having the search box expand to cover most of the URL as I'm typing stuff into it.]
2) Having a unified bar means I only have to learn and use one shortcut for changing focus to the bar. [This deficiency is very minor, but fundamental.]
3) The address bar keyword searches actually work better for searching than does the search bar IMO (not for everyone, but I suspect many power users would agree) because of the ability to set up keyword searches that use multiple search engines. In Firefox, to change what search provider is used I have to use alt + the arrow keys to change what I want. I can far faster type a couple letters and not worry about what the program is doing. (In addition, adding new keyword searches is easier in my experience than adding a new search provider.) [This deficiency could be remedied by supporting keyword searches from the search bar -- but at the cost of either introducing yet another ambiguity or requiring them.]
wonder what part of "national sales tax" you missed. Everyone gets to pay sales tax on internet purchases going forward.
The part where that didn't happen.
As I just said in another post, there's no "internet sales tax", just the ability for states to require internet retailers to collect sales tax on sales to residents. If a state has no sales tax, there will continue to be no sales tax.
(I make no statement on whether the federal bill/law is good or bad, just that the name "internet sales tax" is apparently incredibly misleading.)
The "national internet sales tax" is a stupid and incorrect name for what happened, regardless of whether you agree or disagree with the bill.
What they got is for Congress to say (or is it still a bill? I forget) that states can require Internet vendors to collect sales tax for remote sales to those residents. There's no "internet sales tax", it just moves the burden of collecting sales tax on internet purchases from the residents (who will often not pay and is basically unenforcable) to the retailers.
In other words: if states were to get rid of the state sales tax, then Amazon wouldn't be collecting any either.
I'm willing to concede that searching without a keyword is somewhat questionable (probably useful for most people, bad for power users)
Maybe I should upgrade that to neutral for power users. The main reason it's bad IMO is the interference with DNS, which is covered by my following statement.
Effectively making the "stuff" a different part of the UI based on the context of the "ls"|"cat" command that preceded it
Why the focus on the "stuff" part of the line? What about if I just type "emacs" or "ls", no arguments to either?
There is nothing you can do to distinctly tell it to search or navigate
Sure there is. If you enter http:/// and it won't search, and if you enter a search keyword it won't try to navigate.
Elsewhere in the thread I said the main thing I like about the combined box is not so much the fact that you can just type search terms but the fact that you can set up keyworded searches. I'm willing to concede that searching without a keyword is somewhat questionable (probably useful for most people, bad for power users) and not going to DNS first for things which could be a URL is definitely bad. (That's probably true for everyone: power users won't like it for obvious reasons, and normal people will have a harder time figuring out how to go to a weird URL if the browser searches than they will figuring out how to search if it goes to the page.) So I'd agree there's room for improvement with current design.
However, I stand by the idea of having just the single address bar. And the difference is such that if you offered me the choice of (1) a Firefox or Chrome-like address bar which does searches or (2) a really old style address bar which only accepts real URLs, I'd take the former one in a heartbeat and never regret it.
ls and cat are not entered from the same ui element, not really. once you enter the ls or cat command the following data is distinct for its intended purpose.
What? I type both in the same place, and it shows the results in the same place. Works the same in a browser.
With a combo search/url bar, "stuff" can be a valid domain under your local DNS, but your shit-tastic box will search for it instead of navigating there.
That's an implementation problem with the search, not a conceptual problem with the combined address bar. If it tried single words as addresses first, it'd pretty much work the same as the command line.
I don't like the "type in something and it will search" much, but what I do really like is the named searches you can do from it. For me, "g " will search Google, "w " wikipedia, "nws " will bring up the weather forecast, etc.
It's almost like a command line for common searches, and the space means it basically can't be confused with a URL.
Read your keystrokes, and thus get passwords without decryption
I'm not sure, but this may already be possible (for the current user) now, without root.
Even if it's not in general, you could still do something like install a browser extension for the user that does it while they're in the browser. (At least for Firefox; not sure if Chrome extensions are powerful enough to do that.)
Read directly from memory, therefore also bypassing the need for decryption, and accessing even more sensitive information unaided (GPG/SSH/SSL/etc unencrypted, etc)
On most Linux systems, this is also possible without root. (I did recently discover that you can't use GDB under the default configuration on Ubuntu as non-root users can't ptrace by default, so on that system it'd likely be protected.)
I don't want to discount the threat of a priviledge escalation bug, but if I had to say the relative threats for a single-user system, I'd guess that probably 90% of the danger of a vulnerability doesn't need root.
I think the bigger question is more game support. The list now of Linux-supported games is relatively small, and there are almost no big AAA titles on it. Even Valve hasn't ported either any of the HL2 games nor Portal 2 yet*.
If publishers start to say "hey, if we write more generically then we can pick up Mac and Linux, and Valve is supporting both platforms with Steam so there must be something to it" and then start publishing games, then it'll happen. But without that, even a dedicated console-like gaming PC won't do much.
It also has no visual indication that users can just start typing after hitting the start menu to find programs. As it is inferior to both 95/NT4 and 7, one can argue that Metro is a 30-year backward slide in interface design.
Just because there's no indication that you can't just start typing (which I'll agree is a problem) doesn't mean that you can't. And as such, no way in hell is Win8 inferior to 95/NT4 from the "starting programs" point of view; it's superior to XP, Gnome 2, and any other similar system where you can't do that. (And it matches Vista and Win7. Well, pretty much matches; I don't like the split programs/settings/other crap scopes in Win8.)
(And even on the "click the program you want" front, if you're comparing the Win8 tile screen to the desktop, I'd still put Win8 ahead by quite a bit: it's scrollable and you don't have to minimize stuff to get to it.)
Slashdot Mirror
Um, as someone who is somewhat (but not only somewhat) familiar with generics in both systems, I don't see anything in TFA's explanation which is misleading or incorrect, nor contradicted by your link. Care to elaborate on what you mean?
I'm not your parent, but:
No, the last film remake was Superman Returns, staring Brandon Routh.
On the flip side you'll see some weird stuff like stores that won't let you order on the Sabbath. B&H Photo Video, one of the best camera stores in the US, is like that. They have a big, well designed, online ordering system. However it won't let you order on the Sabbath. You can browse, but if you try to place an order, it won't allow it, you have to wait, it won't queue it into the system. The servers don't get the day off, but they aren't allowed to take orders :).
Huh, I've noticed that, but never knew why (but never been dedicated enough in the answer to investigate). Thanks for the information. :-)
There is no such free service and UPCs are not U.
The second reason is interesting, and is sort of the biggest objection I could think of (I was considering homemade stuff).
However, the "there is no such free service" is not, because while that remains true states cannot require internet vendors to collect sales tax. It is a requirement of the bill that states would need to provide such a free service to require tax collection.
And if a business in such a State sells something to someone living in Kenner LA, they'll have to be able to figure sales tax for LA, Jefferson Parish, Kenner, and such sales tax holidays as might be applicable on any particular item at any particular time...
No, not really. If LA wants Amazon to pay LA sales tax, then LA must make freely available software or a service that will do said calculation for Amazon (and if said software gets it wrong, Amazon will not be liable for the difference).
I'm not entirely convinced that said system will always be easy to implement, and PRMan (I think that's the name of the poster) in a reply to a different post of mine points out an interesting privacy issue that I'm not sure what the answer is (/if there is one). But at the same time, I also think it's certainly conceivable that the law will impart a relatively low burden in terms of implementation cost.
Though again, I don't feel strongly one way or another about whether the law is "right" or "wrong".
Try telling that to anyone that works in tax with multiple states, they wouldn't stop laughing at you.
Care to elaborate any? Because theoretically at least, all the complications of what items are taxed at what rate are not in the hands of the retailers; they just integrate with a free service that provides that information. I haven't looked for anything like this, but I haven't heard any actual explanation of why such a system would be complex (e.g. "matching up UPCs is hard" or something like that).
I'm not saying it isn't, just that I'd like to know more.
First, many valid searches are also valid URLs. You likely never encounter this if you don't have a local intranet that you go to.
My contention is this is mostly just a problem with the decision procedure for what to do: if browsers were better about de-prioritizing search in favor of treating things which could be a URL as a potential URL, almost all of the problems with this I think would disappear. You'd have to do a very minor amount of effort if you wanted to do a search for a single word which was also a valid name on your internet.
Second, many typos of otherwise-valid URLs are indistinguishable from non-URLs and become searches. This can get confusing and also in the worst case leak some private information.
This is an interesting argument; actually I think it's one of the most convincing I've seen in this thread.
Third, there's the search provider. ... you can add explicit text-based prefixes
If what you mean is what I think you mean (e.g. "g foo" can search google for foo, "w bar" will search wikipedia for bar), those prefixes are exactly why I like the combined bar as much as I do. I like it rather more than Firefox-style search providers in the search box. (And yes, Firefox supports keyword searches as well, as does Opera.)
Fourth, even without search in there the address bar is already multifunctional. Merging in search means that search terms must be wiped out after searching...
I think this is a minor problem which is outweighed by the benefits (like reduced clutter and, in practice, too-small search box). ...and the current address must be wiped out to search.
This I don't see as a problem at all; or at least no more of a problem than the fact that you have to wipe out the current address to go to another address now.
Durrr, what? What you're talking about appears to me to be entirely orthogonal to the issue of whether the address bar searches or not, unless your contention is going to that URL will actually lead you to a search page.
It's not like when you type in a URL you get sent to to a Google page that says "hey, this is a URL, I'll do a silent redirection to the URL". It's the client side that decides whether it just navigates to the page or goes to the URL.
ooh! I know, the user is wanting to search for those on google!!
I entered both of those URLs along with an IP which is actually accessible to me into three different browsers (Chrome, Opera, and Firefox for Linux), and not once did I get a search. Opera and Firefox did add an explicit .com at the end of http://intranet/ and went to http://www.intranet.com./
I also tried just the IP addresses without the http:/// prefix, and not one of them led to a search page.
The only thing that did was entering "intranet" on its own. But turning on troll mode (though "troll mode with a point") for a second, that's not a URL; http://intranet/ is the URL. Your browser is already applying a heruistic (prefix the scheme) to arrive at the URL. After all, who's to say you didn't really intend https://intranet/? In some sense, all the browsers are doing in that case is applying a different heuristic that goes to a far less related page.
[1.] You can adjust the relative size of the search bar and the address bar manually. [2.] And it could have been done automatically.
(1) Yes, but that's extra work and can't be done from the keyboard (at least AFAIK). (2) I conceeded that point.
You only need one shortcut to switch focus to the either one, it just happens to be a different shortcut for each (as it should be)
Um, that's not a good response, because I disagree on the last assumption.
[1.] The firefox search box allows you to select different search providers already. and [2.] your keyword searches could have been incorporated there instead.
(1) I did mention that. Access isn't as good IMO. (2) Also conceed that point.
But hey, are we talking about how things are, or how they could be? Because if we're talking about how things are, then my first and third objections definitely currently apply. If we're talking about how things could be, then I submit it's also possible to make a combined bar work well enough that it addresses basically every concrete (i.e. not "they shouldn't be combined!") objection in this thread.
Either the guessing algorithm is dumb, and annoys the user, or it is really sophisticated, in which case it took probably away a huge amount of developer manpower to implement in a way that pleases both the "I want to shop for something vague" vague user and the "Shit, the system is down, we are losing $100,000 a minute, and this shitty browser is trying to do a search, which he can't do since the connection to the internet is down, and locks up while waiting for the time-out, instead of just going to the web fronted for the NAS!!".
I don't completely disagree with where you're coming from. I definitely recognize the conflict between "attempt to be user friendly and do a good job most of the time" and predictability (this is not even remotely the. only place it comes up), and I'll admit that I fall a little more on the first side than many power users. But at the same time, I think you'd be pretty hard-pressed to find a problem with "try DNS and if that doesn't work then search".
For instance, take your example. If your browser freezes because the internet is down and it can't hit the search provider, then it has bigger problems than URLs vs searches. And it wouldn't be not going to the NAS front end in such a situation if it didn't try to search; it would be not going to the "server not found" error page.
(And of course, that policy isn't what happens now with browsers, but it's also not a fundamental problem with the combined bar.)
In the comparison with ls and cat, a unified search/url input in the same GUI element you would basically have to type something like "http://xxxxx" to go to an url ans something like "search://xxxxx" to do a search, wo work like the CLI
But here's the thing: You can! What you say is already the situation! (Sort of.)
If you type http://url/ it will go to that URL and not try to search. And if you set up a keyword search and use it, then it is unambiguously not a URL (with a different syntax than search://, but same idea).
In fact, the broswer is already applying a heuristic when you enter an address -- it'll prepend http:/// After all, "google.com" is not a URL if I'm a dick and pedant. In some sense, the only thing that's changing is what sorts of heuristics are applied to things which aren't explicit URLs and aren't explicit searches in order to figure out where to go. I mean, take the internet in 20 years. Maybe it'll be the case that HTTPS is universal, and when you type in "example.com", your browser will assume you mean "https://example.com" instead. And that'll break things too! But that's okay, because "example.com" is fundamentally not an unambiguous request even now.
Can't do that by mashing keywords into the URL bar (as far as I know).
You can.
In Firefox, go to any website you want to set up a search for, right click on the search box, and choose "add keyword for this search". If you add, say, a keyword of "g" on Google, then "g foo" in your address bar will search Google. In Chrome, you'll choose "add as search engine."
Why am I focusing on "stuff" instead of the command? Hello! because that is what you are acting on. entering data into a command line is pointless without a command to run.
IMO, the line between data vs command is blurrier than you make it out to be. From some point of view, typing "example.com" into your browser is giving it data. But I'd argue it's just as reasonable to look at it is a command -- "go to example.com". I think this is even stronger with searches: "g blah" is a command saying "search Google for blah". So I think that it's not so outrageous for me to compare entering whatever into the address bar of a browser to entering "emacs" vs "ls".
The thing is, you already have full access to a perfectly useful search tool in the search box (on firefox). ... This is a thing that has NO positive benefits, only negative.
There are at least three benefits, though admittedly two of them are merely deficiencies with the current implementation in Firefox:
1) Having a unified bar means that I can see both long URLs and long search queries. In Firefox, if I copy and paste an error message or something like that into the search box, it will almost certainly be too small to view the entire query. [This deficiency could be remedied by having the search box expand to cover most of the URL as I'm typing stuff into it.]
2) Having a unified bar means I only have to learn and use one shortcut for changing focus to the bar. [This deficiency is very minor, but fundamental.]
3) The address bar keyword searches actually work better for searching than does the search bar IMO (not for everyone, but I suspect many power users would agree) because of the ability to set up keyword searches that use multiple search engines. In Firefox, to change what search provider is used I have to use alt + the arrow keys to change what I want. I can far faster type a couple letters and not worry about what the program is doing. (In addition, adding new keyword searches is easier in my experience than adding a new search provider.) [This deficiency could be remedied by supporting keyword searches from the search bar -- but at the cost of either introducing yet another ambiguity or requiring them.]
Sorry, substitute "national sales tax" for "internet sales tax" in my comment.
wonder what part of "national sales tax" you missed. Everyone gets to pay sales tax on internet purchases going forward.
The part where that didn't happen.
As I just said in another post, there's no "internet sales tax", just the ability for states to require internet retailers to collect sales tax on sales to residents. If a state has no sales tax, there will continue to be no sales tax.
(I make no statement on whether the federal bill/law is good or bad, just that the name "internet sales tax" is apparently incredibly misleading.)
The "national internet sales tax" is a stupid and incorrect name for what happened, regardless of whether you agree or disagree with the bill.
What they got is for Congress to say (or is it still a bill? I forget) that states can require Internet vendors to collect sales tax for remote sales to those residents. There's no "internet sales tax", it just moves the burden of collecting sales tax on internet purchases from the residents (who will often not pay and is basically unenforcable) to the retailers.
In other words: if states were to get rid of the state sales tax, then Amazon wouldn't be collecting any either.
I'm willing to concede that searching without a keyword is somewhat questionable (probably useful for most people, bad for power users)
Maybe I should upgrade that to neutral for power users. The main reason it's bad IMO is the interference with DNS, which is covered by my following statement.
Effectively making the "stuff" a different part of the UI based on the context of the "ls"|"cat" command that preceded it
Why the focus on the "stuff" part of the line? What about if I just type "emacs" or "ls", no arguments to either?
There is nothing you can do to distinctly tell it to search or navigate
Sure there is. If you enter http:/// and it won't search, and if you enter a search keyword it won't try to navigate.
Elsewhere in the thread I said the main thing I like about the combined box is not so much the fact that you can just type search terms but the fact that you can set up keyworded searches. I'm willing to concede that searching without a keyword is somewhat questionable (probably useful for most people, bad for power users) and not going to DNS first for things which could be a URL is definitely bad. (That's probably true for everyone: power users won't like it for obvious reasons, and normal people will have a harder time figuring out how to go to a weird URL if the browser searches than they will figuring out how to search if it goes to the page.) So I'd agree there's room for improvement with current design.
However, I stand by the idea of having just the single address bar. And the difference is such that if you offered me the choice of (1) a Firefox or Chrome-like address bar which does searches or (2) a really old style address bar which only accepts real URLs, I'd take the former one in a heartbeat and never regret it.
ls and cat are not entered from the same ui element, not really. once you enter the ls or cat command the following data is distinct for its intended purpose.
What? I type both in the same place, and it shows the results in the same place. Works the same in a browser.
With a combo search/url bar, "stuff" can be a valid domain under your local DNS, but your shit-tastic box will search for it instead of navigating there.
That's an implementation problem with the search, not a conceptual problem with the combined address bar. If it tried single words as addresses first, it'd pretty much work the same as the command line.
"'ls' and 'cat' are two very different things and should never ever be entered from the same UI element."
I don't think they're as different as you do. Entering a URL means "go to this URL exactly"; search means "go to a URL which I am abbreviating a bit."
How different the tasks are depends greatly on what level of abstraction you view them at.
Oh good... this should have said, for example "g <blah<" and "g <zip>", etc.
I don't like the "type in something and it will search" much, but what I do really like is the named searches you can do from it. For me, "g " will search Google, "w " wikipedia, "nws " will bring up the weather forecast, etc.
It's almost like a command line for common searches, and the space means it basically can't be confused with a URL.
I'm not sure, but this may already be possible (for the current user) now, without root.
Even if it's not in general, you could still do something like install a browser extension for the user that does it while they're in the browser. (At least for Firefox; not sure if Chrome extensions are powerful enough to do that.)
On most Linux systems, this is also possible without root. (I did recently discover that you can't use GDB under the default configuration on Ubuntu as non-root users can't ptrace by default, so on that system it'd likely be protected.)
I don't want to discount the threat of a priviledge escalation bug, but if I had to say the relative threats for a single-user system, I'd guess that probably 90% of the danger of a vulnerability doesn't need root.
I think the bigger question is more game support. The list now of Linux-supported games is relatively small, and there are almost no big AAA titles on it. Even Valve hasn't ported either any of the HL2 games nor Portal 2 yet*.
If publishers start to say "hey, if we write more generically then we can pick up Mac and Linux, and Valve is supporting both platforms with Steam so there must be something to it" and then start publishing games, then it'll happen. But without that, even a dedicated console-like gaming PC won't do much.
* They run on Wine, but that's different.
Just because there's no indication that you can't just start typing (which I'll agree is a problem) doesn't mean that you can't. And as such, no way in hell is Win8 inferior to 95/NT4 from the "starting programs" point of view; it's superior to XP, Gnome 2, and any other similar system where you can't do that. (And it matches Vista and Win7. Well, pretty much matches; I don't like the split programs/settings/other crap scopes in Win8.)
(And even on the "click the program you want" front, if you're comparing the Win8 tile screen to the desktop, I'd still put Win8 ahead by quite a bit: it's scrollable and you don't have to minimize stuff to get to it.)