Hmm, I think I may have figured it out. I think that the browsers are adding an implicit.com at the end. So CNet got its hands on com.com, and when I type "http://com" in, it tries adding a.com to get http://com.com/ which then redirects to cnet.
So I think my previous test wasn't working the way I expected. Now that said, I still don't know what the difference is with what IE does -- I just tried typing 'www' into IE, and it took me to my domain's www host, and did not do a search.
I just typed "www" in the address bar of FF 13 and it correctly brought up my company's main webpage. Why? Because the resolver on my PC is set to automatically search our own domain when looking up a hostname. FF only goes to web search if the resolver fails to return an IP address.
Meanwhile, I tried 'com'. "http://com" resolves correctly, but entering just "com" does a search.
I'm not enough of a networking guy to explain the difference. Anyone want to comment?
The blame for this is on certain browser developers (*cough* MS *cough*). There is no technical reason why "amazon" couldn't be a host, but IE stupidly assumes that when you enter a single word, you want to search for it.
Psst... don't look now, but Firefox, Chrome, and Opera all do the same thing. But don't that stop you from following in the/. tradition and singling out MS.
"That's not how binary blob software works. Every imaginable library the program might concievably need will be included in the package."
That depends what you mean. If you're talking about a binary blob actually meant for the end user, then yes, you're right. Those actually work. But almost nothing gets packaged that way. If you're talking about the things that people actually use -- binary packages from the distro -- then no, those are built assuming you'll be installing through a package manager (or don't mind hashing out dependencies yourself).
So Linux binary tarballs and installers aren't as uncommon as you think, at least when it comes to cross-platform projects that have fairly frequent official releases.
That may be true... but "cross-platform projects that have fairly frequent official releases" isn't a particularly common thing that I want to install. (And yeah, I'm posting this from a custom-installed Opera.:-)) Excluding 1 Python library, the 10 latest things I've installed like this are: Boost (no 1st-party binary build available that I can see), libdwarf (no binaries available; in addition, common 3rd party builds like the one in Ubuntu's repos are unsuitable), gperftools (RPMs available; don't know if they work), libigraph (no 1st-party binary), git (no 1st-party binary), ghex (no 1st-party binary), libgnomeprint (no 1st-party binary), tree (no 1st-party binary), p7zip (binary release available; I didn't try it), and the Awesome window manager (no 1st-party binary; has several dependencies like libxcb that I also had to build as no 1st-party binaries are available). That's 80% have binary releases only through distros or other places I don't know about.
In some of them I'm sure I could have used the distro's RPMs -- but not always. In the case of libxcb for example, it's too old. In other cases, programs build to explicitly reference things via hard-coded absolute paths under their --prefix, and so installing them to other locations would fail. (I cannot install Spotify, for instance, for this reason -- it looks for things under/usr explicitly.) And even if a distro RPM would work, that doesn't help with the dependency-resolution problem. Building packages is almost always pretty easy; it's figuring out what other packages to install that gets annoying.
Steam pretty aggressively updates the actual games in its library. This means that either (1) it would fairly frequently need to ask the user to sudo those changes or (2) put the game files in $HOME anyway. It's possible they think that (1) would be too obnoxious and so go with (2) for that reason; and once you've done (2), why not just put Steam itself in $HOME too?
That doesn't mean it's commonly done. For instance, installing to anything but/usr is something that almost no package manager out there does. So sure, you can install $PACKAGE yourself, but first you're going to have to track down the three libraries it uses, and the two libraries one of those use, and the three libraries one of those use. (Believe me, I do this a fair bit because I somewhat frequently have need to install things to non-standard locations.)
What we're talking about here is what basically every user will see. In other words, the common case, rather than (at least currently) the uncommon one.
Why would they limit themselves to the crapbuntu is unknown to me, but my guess to spare time on user support. Oh well.
From what Valve has said, that's not intended as a long-term thing. They are going with Ubuntu first because... surprise surprise... that's what the vast majority of their survey respondents said.
Because multiple repositories just multiplies the work Valve has to do supporting Linux. Simply packaging things isn't a lot of work, but checking to see if the packages work is. Better to have one canonical archive and let the distros do their own packaging and testing.
I can flip that argument around though: if you're Valve and thus concerned about the quality of your product, why would you turn over control of said quality to a third party?
(I'm not sure to what extent I buy these two arguments; I'm just putting it out there as sort of a "devil's advocate" perspective.)
I also heard chrome does the same (on windows as well).
I can confirm that it does (or least, did) on Windows. It's one of a few reasons I don't use it.
(And yeah, I know about some alternative thing you can download that's aimed at business that lets you choose installation location. I said "one of a few reasons":-))
That's not really true at all; according to Wikipedia, CounterStrike hit beta 4 before Valve got involved, and didn't fully acquire (2000) it until after its first release (1999).
By contrast, while Narbacular Drop was the genesis of Portal, Valve hired that team before development of Portal really began. Narbacular Drop is an impressive student project -- but as an actually published game it'd be pretty awful. The ideas were developed quite a bit for Portal beyond what Narbacular Drop did.
"Portal is Narbacular Drop" in true only in the same sense that, say, "HL1 is Doom" is true.
2) I strongly dislike putting it into the browser (for a couple reasons, that just doesn't work with the way I use terminals); any plans for some stand-alone program (even if it's just a wrapper around a webkit widget or something)?
I guess I should also say: a lot of the focus of this story's discussion has been in the context of connecting to remote system; in such a context, a browser is more reasonable. My comment is based on a "I want a cool terminal to use locally" viewpoint.
1) I tried hangman but it wasn't working; Chrome 22.0.1229.94 on RHEL6. (It's slightly out of date -- see "RHEL6.":-))
2) I strongly dislike putting it into the browser (for a couple reasons, that just doesn't work with the way I use terminals); any plans for some stand-alone program (even if it's just a wrapper around a webkit widget or something)?
3) I like some of the recent efforts towards rethinking what it means to be a terminal emulator (embedded images and such), so kudos for that. You're not the only one, though you seem to have taken it further than most of the other projects I've seen.
Cue one person who may have actually used this mainframe-timeshare style of computing. I've been using Linux for over a decade and I've never seen an implementation of network-based X11 terminals in real life, ever. Some school in Germany may have fussed with it a decade ago.
To be fair, I have used X11's network transparency on several occasions, and it's not to deal with mainframe-timeshare stuff: it's to just run a program over SSH.
Yes, there are other ways of doing it, with VNC and whatever. But I've never bothered to figure out how to set that up. Why? Because ssh -X something and ssh -Y something are quick, easy, and easy to remember (-X to get X).
You don't need to be in the thin client mindset to want network transparency. (That said, I could almost not care less if it goes away. I only use that once a month at most, and even less rarely is it actually important that it works.)
Who wants any program to change the resolution of their screen?
Someone whose graphics card isn't up to the task of running a game at full native resolution? That'd be my guess anyway; I haven't willingly used a lower resolution for a while. (Some games don't support high resolutions, or don't support widescreen resolutions, and there it's "reasonable" that they change it as well. But a program like that probably wouldn't use that in the first place, so whatever.)
The window manager should always be superior to the app, and one should always be able to manage the window (task switch, move to another desktop, etc) using the window manager, regardless of what the app thinks it is doing.
I don't know enough about this proposal to say how it interacts with this (indeed, I'm rather disappointed by both the summary and TFA not actually, you know, saying what the problems are in the first place), but there's absolutely no reason why those goals are in conflict. In fact, the proposal specifically addresses this: "If the window loses input focus while fullscreen, the Window Manager MUST revert the resolution change and iconify the window until it regains input focus. The Window Manager MUST protect desktop state (icon positions, geometry of other windows, etc) during resolution change, so that the state will be unchanged when the window ceases to be marked as fullscreen."
I also think so, and I think that's one difference. I'm pretty sure MS patches are incremental.
Suppose patch B depends on patch A. In the Windows model, installing patch A is faster than the Linux model (ignoring all the other crap like system restore points that Windows does during updates to actually make it slower). The same is true of patch B when applied to a system with patch A: since MS only sends Windows users the things that need to change, it's smaller and faster to apply than under the Linux model where they have to send you everything.
The problem with the Windows model comes when you want to apply both patches to a system that has neither. Under the Linux model, you just get patch B since that's a full image, but under the Linux model you need patch A first.
My feeling is that the Windows model is better for the long-term, since incremental patching is what you do most of the time anyway; but it gets really really annoying when you want to do an initial install, as you have to install tons and tons of patches.
The other consequence is that (re. your other post about 1.0/2.0 to 1.0.1/2.0.1) is that in some sense there isn't a latest version of Windows, while there is usually a latest version of Linux and its software. (And the main exceptions to the latter case are when you have two separate packages, e.g. Qt3 and 4, where one doesn't strictly override the other.) But in the Windows model, you can have person 1 who has patches M, N, and O, and person 2 who has patches N, O, and P. Why doesn't person 1 have P? Maybe P is to fix some specific piece of hardware or something, and person 1 either deliberately chose not to install it under the "if it ain't broken, don't fix it" mantra or doesn't even know that the hotfix exists because Windows Update didn't suggest it (perhaps because it knows that person 1 doesn't have that piece of software). This also works in favor of the Windows model in terms of long-term behavior: on Linux, I'd guess I get updates for things which I don't even care about or use, while those would be filtered out of what I see on Windows. (OTOH under the Windows model maybe there's some problem I'm having which would be fixed by a patch, but I don't know about it.)
Of course, then the actual Windows Update mechanism goes and kills those benefits by dicking around and doing-who-knows what during the actual installation.(Taking 30 minutes to just install updates that were already downloaded -- even on a desktop drive -- in my experience was fairly common.) I strongly suspect those are independent of the incremental/full decision though.
That's, uh, kind of my point. If it was in a context where it was completely clear that "impact" meant "affect", it would merely be annoying; the fact that it could conceivably actually mean "impact" in this case is what makes me want to hit the author.
none of Falcon 9â(TM)s other eight engines were impacted by this event.
God I hate this wording.
Don't use "impact" when you mean to say "affected", as I suspect they mean here, especially when the sentence could (if slightly tortuously) be read as "none of Falcon 9's other eight engines were hit [impacted] by debris from the fairing."
[I know that's not you, jkflying, I'm just ranting.]
Not to take anything away from SpaceX, but to the extent that you mean to suggest "SpaceX did a better job than NASA did early on" (which may be none at all), it's of course not really fair to compare considering that SpaceX didn't exactly throw out the knowledge that NASA and others built up because of those failures.
Slashdot Mirror
I assumed you were being a little hyperbolic and followed suit.
You do realize that there are C and D students too, right? And my statement applies to them as well...
Because flunking people who don't care about learning is preferable to pandering to them?
And, of course, constantly flunking someone is the best way to get them to care.
Hmm, I think I may have figured it out. I think that the browsers are adding an implicit .com at the end. So CNet got its hands on com.com, and when I type "http://com" in, it tries adding a .com to get http://com.com/ which then redirects to cnet.
So I think my previous test wasn't working the way I expected. Now that said, I still don't know what the difference is with what IE does -- I just tried typing 'www' into IE, and it took me to my domain's www host, and did not do a search.
I just typed "www" in the address bar of FF 13 and it correctly brought up my company's main webpage. Why? Because the resolver on my PC is set to automatically search our own domain when looking up a hostname. FF only goes to web search if the resolver fails to return an IP address.
Meanwhile, I tried 'com'. "http://com" resolves correctly, but entering just "com" does a search.
I'm not enough of a networking guy to explain the difference. Anyone want to comment?
The blame for this is on certain browser developers (*cough* MS *cough*). There is no technical reason why "amazon" couldn't be a host, but IE stupidly assumes that when you enter a single word, you want to search for it.
Psst... don't look now, but Firefox, Chrome, and Opera all do the same thing. But don't that stop you from following in the /. tradition and singling out MS.
"That's not how binary blob software works. Every imaginable library the program might concievably need will be included in the package."
That depends what you mean. If you're talking about a binary blob actually meant for the end user, then yes, you're right. Those actually work. But almost nothing gets packaged that way. If you're talking about the things that people actually use -- binary packages from the distro -- then no, those are built assuming you'll be installing through a package manager (or don't mind hashing out dependencies yourself).
So Linux binary tarballs and installers aren't as uncommon as you think, at least when it comes to cross-platform projects that have fairly frequent official releases.
That may be true... but "cross-platform projects that have fairly frequent official releases" isn't a particularly common thing that I want to install. (And yeah, I'm posting this from a custom-installed Opera. :-)) Excluding 1 Python library, the 10 latest things I've installed like this are: Boost (no 1st-party binary build available that I can see), libdwarf (no binaries available; in addition, common 3rd party builds like the one in Ubuntu's repos are unsuitable), gperftools (RPMs available; don't know if they work), libigraph (no 1st-party binary), git (no 1st-party binary), ghex (no 1st-party binary), libgnomeprint (no 1st-party binary), tree (no 1st-party binary), p7zip (binary release available; I didn't try it), and the Awesome window manager (no 1st-party binary; has several dependencies like libxcb that I also had to build as no 1st-party binaries are available). That's 80% have binary releases only through distros or other places I don't know about.
In some of them I'm sure I could have used the distro's RPMs -- but not always. In the case of libxcb for example, it's too old. In other cases, programs build to explicitly reference things via hard-coded absolute paths under their --prefix, and so installing them to other locations would fail. (I cannot install Spotify, for instance, for this reason -- it looks for things under /usr explicitly.) And even if a distro RPM would work, that doesn't help with the dependency-resolution problem. Building packages is almost always pretty easy; it's figuring out what other packages to install that gets annoying.
I don't know. But I do have a guess.
Steam pretty aggressively updates the actual games in its library. This means that either (1) it would fairly frequently need to ask the user to sudo those changes or (2) put the game files in $HOME anyway. It's possible they think that (1) would be too obnoxious and so go with (2) for that reason; and once you've done (2), why not just put Steam itself in $HOME too?
That doesn't mean it's commonly done. For instance, installing to anything but /usr is something that almost no package manager out there does. So sure, you can install $PACKAGE yourself, but first you're going to have to track down the three libraries it uses, and the two libraries one of those use, and the three libraries one of those use. (Believe me, I do this a fair bit because I somewhat frequently have need to install things to non-standard locations.)
What we're talking about here is what basically every user will see. In other words, the common case, rather than (at least currently) the uncommon one.
Why would they limit themselves to the crapbuntu is unknown to me, but my guess to spare time on user support. Oh well.
From what Valve has said, that's not intended as a long-term thing. They are going with Ubuntu first because ... surprise surprise ... that's what the vast majority of their survey respondents said.
Because multiple repositories just multiplies the work Valve has to do supporting Linux. Simply packaging things isn't a lot of work, but checking to see if the packages work is. Better to have one canonical archive and let the distros do their own packaging and testing.
I can flip that argument around though: if you're Valve and thus concerned about the quality of your product, why would you turn over control of said quality to a third party?
(I'm not sure to what extent I buy these two arguments; I'm just putting it out there as sort of a "devil's advocate" perspective.)
Well shucks. So much for my plans.
I also heard chrome does the same (on windows as well).
I can confirm that it does (or least, did) on Windows. It's one of a few reasons I don't use it.
(And yeah, I know about some alternative thing you can download that's aimed at business that lets you choose installation location. I said "one of a few reasons" :-))
As others have said (but I'll reply here so you're more likely to see it), apparently Steam essentially installs to your $HOME.
That's not really true at all; according to Wikipedia, CounterStrike hit beta 4 before Valve got involved, and didn't fully acquire (2000) it until after its first release (1999).
By contrast, while Narbacular Drop was the genesis of Portal, Valve hired that team before development of Portal really began. Narbacular Drop is an impressive student project -- but as an actually published game it'd be pretty awful. The ideas were developed quite a bit for Portal beyond what Narbacular Drop did.
"Portal is Narbacular Drop" in true only in the same sense that, say, "HL1 is Doom" is true.
That's where the comment/question about running in a browser comes in.
2) I strongly dislike putting it into the browser (for a couple reasons, that just doesn't work with the way I use terminals); any plans for some stand-alone program (even if it's just a wrapper around a webkit widget or something)?
I guess I should also say: a lot of the focus of this story's discussion has been in the context of connecting to remote system; in such a context, a browser is more reasonable. My comment is based on a "I want a cool terminal to use locally" viewpoint.
A couple comments:
1) I tried hangman but it wasn't working; Chrome 22.0.1229.94 on RHEL6. (It's slightly out of date -- see "RHEL6." :-))
2) I strongly dislike putting it into the browser (for a couple reasons, that just doesn't work with the way I use terminals); any plans for some stand-alone program (even if it's just a wrapper around a webkit widget or something)?
3) I like some of the recent efforts towards rethinking what it means to be a terminal emulator (embedded images and such), so kudos for that. You're not the only one, though you seem to have taken it further than most of the other projects I've seen.
Cue one person who may have actually used this mainframe-timeshare style of computing. I've been using Linux for over a decade and I've never seen an implementation of network-based X11 terminals in real life, ever. Some school in Germany may have fussed with it a decade ago.
To be fair, I have used X11's network transparency on several occasions, and it's not to deal with mainframe-timeshare stuff: it's to just run a program over SSH.
Yes, there are other ways of doing it, with VNC and whatever. But I've never bothered to figure out how to set that up. Why? Because ssh -X something and ssh -Y something are quick, easy, and easy to remember (-X to get X).
You don't need to be in the thin client mindset to want network transparency. (That said, I could almost not care less if it goes away. I only use that once a month at most, and even less rarely is it actually important that it works.)
The RAM hit isn't too bad, given that GPUs these days ship with 1GB or more
Sure, for desktops. What about laptops?
Who wants any program to change the resolution of their screen?
Someone whose graphics card isn't up to the task of running a game at full native resolution? That'd be my guess anyway; I haven't willingly used a lower resolution for a while. (Some games don't support high resolutions, or don't support widescreen resolutions, and there it's "reasonable" that they change it as well. But a program like that probably wouldn't use that in the first place, so whatever.)
The window manager should always be superior to the app, and one should always be able to manage the window (task switch, move to another desktop, etc) using the window manager, regardless of what the app thinks it is doing.
I don't know enough about this proposal to say how it interacts with this (indeed, I'm rather disappointed by both the summary and TFA not actually, you know, saying what the problems are in the first place), but there's absolutely no reason why those goals are in conflict. In fact, the proposal specifically addresses this: "If the window loses input focus while fullscreen, the Window Manager MUST revert the resolution change and iconify the window until it regains input focus. The Window Manager MUST protect desktop state (icon positions, geometry of other windows, etc) during resolution change, so that the state will be unchanged when the window ceases to be marked as fullscreen."
I also think so, and I think that's one difference. I'm pretty sure MS patches are incremental.
Suppose patch B depends on patch A. In the Windows model, installing patch A is faster than the Linux model (ignoring all the other crap like system restore points that Windows does during updates to actually make it slower). The same is true of patch B when applied to a system with patch A: since MS only sends Windows users the things that need to change, it's smaller and faster to apply than under the Linux model where they have to send you everything.
The problem with the Windows model comes when you want to apply both patches to a system that has neither. Under the Linux model, you just get patch B since that's a full image, but under the Linux model you need patch A first.
My feeling is that the Windows model is better for the long-term, since incremental patching is what you do most of the time anyway; but it gets really really annoying when you want to do an initial install, as you have to install tons and tons of patches.
The other consequence is that (re. your other post about 1.0/2.0 to 1.0.1/2.0.1) is that in some sense there isn't a latest version of Windows, while there is usually a latest version of Linux and its software. (And the main exceptions to the latter case are when you have two separate packages, e.g. Qt3 and 4, where one doesn't strictly override the other.) But in the Windows model, you can have person 1 who has patches M, N, and O, and person 2 who has patches N, O, and P. Why doesn't person 1 have P? Maybe P is to fix some specific piece of hardware or something, and person 1 either deliberately chose not to install it under the "if it ain't broken, don't fix it" mantra or doesn't even know that the hotfix exists because Windows Update didn't suggest it (perhaps because it knows that person 1 doesn't have that piece of software). This also works in favor of the Windows model in terms of long-term behavior: on Linux, I'd guess I get updates for things which I don't even care about or use, while those would be filtered out of what I see on Windows. (OTOH under the Windows model maybe there's some problem I'm having which would be fixed by a patch, but I don't know about it.)
Of course, then the actual Windows Update mechanism goes and kills those benefits by dicking around and doing-who-knows what during the actual installation.(Taking 30 minutes to just install updates that were already downloaded -- even on a desktop drive -- in my experience was fairly common.) I strongly suspect those are independent of the incremental/full decision though.
That's, uh, kind of my point. If it was in a context where it was completely clear that "impact" meant "affect", it would merely be annoying; the fact that it could conceivably actually mean "impact" in this case is what makes me want to hit the author.
none of Falcon 9â(TM)s other eight engines were impacted by this event.
God I hate this wording.
Don't use "impact" when you mean to say "affected", as I suspect they mean here, especially when the sentence could (if slightly tortuously) be read as "none of Falcon 9's other eight engines were hit [impacted] by debris from the fairing."
[I know that's not you, jkflying, I'm just ranting.]
Not to take anything away from SpaceX, but to the extent that you mean to suggest "SpaceX did a better job than NASA did early on" (which may be none at all), it's of course not really fair to compare considering that SpaceX didn't exactly throw out the knowledge that NASA and others built up because of those failures.