Be careful with model or even revision numbers, always check hardware compatibility lists. very often times the difference between something like a "653" and a "653+" can be an entirely different (and not supported) chipset.
You do not receive the Google Docs login prompt if your browser is not logged into Google at all.
You do, however, receive the login prompt if your browser is logged in through another Google service (like search). Check to make sure nobody has you logged into Google search or something.
This sort of half logged in status is very annoying.
Yes, but being inspired to write a similar book is now a grey area.
As a some-time composer / musician, I like to play around with existing themes and thus create new themes. Many of history's greatest musical pieces reference other pieces (J.S. Bach referenced traditional church pieces, Mussorgsky referenced many traditional folk songs, the list is probably endless), indeed the vast majority of popular music rarely strays from a handful of progressions around a limited palette of chords. Imagine if someone had managed to patent the 12 bar blues early on... No blues explosion, no Rock & Roll, no Elvis, no Beatles, etc. etc.
The argument that patents are for protecting original ideas is becoming more specious with time. It seems that the primary reason many companies now apply for patents is to either protect themselves from future patent cases, or, as is the case with IV, to prosecute any company or individual who tries to bring a similar idea to market.
I belive there is a real moral hazard to selling addicting/impulsive products, especially to children. After all this is part of the reason why zynga has such a bad reputation.
path prefixes only generally apply to ./configure scripts when you are generating makefiles.
As paths to libs and stuff are hardcoded as part of the ELF spec, it becomes difficult to implement something like this and ive not seen a package manager that can do it.
theoreticly you could work around the library/datafile issues with LD_PRELOAD hacks to make it load stuff from your home directory instead, but thats pretty awful.
Steam has a package so dependancies can be satisfied easily without resorting to "install xyz beforehand", and it runs an installer into your home folder because the user has to be able to modify the games directory for many, many games on steam, because stuff like configuration, custom maps, custom models etc, is stored alongside everything else.
Also steam has diff based patching (which requires accress from whoever is running the steam binary) which makes a lot more sense than how package managers operate for large packages, imagine downloading an entire 20 gig game every time there was a minor bugfix, it would be very obnoxious.
Unless the design of both package managers, and how steam games store settings/etc both change radically, this really is the only workable solution.
Luckily, you will still be able to share steam folders cross user, just simply give both users read/write access to the folder.
This is irrelevant. They can add the Steam binary to their own PPA and update it as they update the client now. Steam will be able to do all those thing, like every single program in Linux can, while being installed as a system package.
I'm only talking about handling Steam updates, I agree with you on game updates. However, the Steam client can still access the user's home directory and create/access game data there, as all Linux apps do, so the current way of having Steam dump its binaries at the home dir is unclean.
Pretty much the only valid point is having to update the whole thing every release, but I've never seen the Steam client download an update that was less than 75 MB.
the issue is, if you have a cluster of games/etc managed by steam in your home directory that is already not under the control of package management, what do you gain by splitting out the steam client itself? it is easier from valve's perspective to just allow steam to manage its own updates along with everything else it manages, than to have a rather arbitrary split that gives you no real advantages anyways.
Steam has always been designed on both osx and windows to be a portable folder that you can move around from system to system and run stuff out of wihout worrying about installers and dependancies.
"By that reasoning, if you have one package on your system that's not managed by the package manager, you should discard the package manager entirely."
No?
Something like "I want to play TF2, so I should update Steam and TF2" is a reasonably common thing and it makes sense to want one thing to handle both of them.
"You should discard the package manager entirely" does not follow from that.
You don't need to update Steam to play TF2 any more than you need to update Gnome to play TF2. By your reasoning, if you should need to update Steam to play TF2, and therefore need to keep Steam out of the package manager, you should also update Gnome, and therefore keep it out of the package manager, as well as the kernel, and pretty much every other package, just to play TF2.
Ergo, "you should discard the package manager entirely".
Steam is separate from the games, it's just an installer. You can play (and update) the games without the installer, therefore at least Steam should be a managed package.
"and therefore keep it out of the package manager"
That is not much like my reasoning. Taking something out of the package manager does not generally make it so that it is taken care of by the same thing that takes care of TF2 being up to date. Making Steam handle Steam updates does.
Once you have introduced Steam as a thing that handles updates for you, moving Steam updates from package manager to Steam is clearly not exactly the same issue as removing things from the package manager in general.
(I mean, it sort of is if "the package manager should handle as many things as possible" is your goal. It is not if "as few things as possible should handle package manager-like things" is your goal.)
> if you have a cluster of games/etc managed by steam in your home directory that is already not under the control of package management, what do you gain by splitting out the steam client itself?
The same thing you gain from every other linux package that has a globally installed application with per-user configuration? which is... every single other application in the entire linux world?
>Steam has always been designed on both osx and windows to be a portable folder that you can move around from system to system and run stuff out of wihout worrying about installers and dependancies.
Huh? Are you familiar with Linux? You can move/copy your home dir, reinstall the package-managed binary and it "just works". That is the best definition of portable, far better than copy-pasting a "Program Files" directory between machines and crossing your fingers. Again, I've yet to hear a technical reason that we can't have /usr/bin/steam and ~/.steam/<steamapps> like every other Linux application does.
No. He means using a deb with a packaging system will install those dependencies automatically. Otherwise it would be the instructions to manually 'install xyz beforehand'.
Its best to always remember this, Google was not on the side of "internet freedom" when they recommended to the FCC that wireless networks didn't need net neutrality.
Please explain where Google harmed Internet freedom.
Without Google and Android the mobile Internet would be 98% gated by the iOS app store and 2% mobile web running on dead-ended mobile safari with a slow JS engine.
"we both recognize that wireless broadband is different from the traditional wireline world, in part because the mobile marketplace is more competitive and changing rapidly. In recognition of the still-nascent nature of the wireless broadband marketplace, under this proposal we would not now apply most of the wireline principles to wireless, except for the transparency requirement. "
IE, nothing about network neutrality, except telling people what you throttle/etc should apply to wireless.
If you want to use the Android SDK (this includes additionally Google APIs), you have to agree to this license: http://developer.android.com/sdk/terms.html This is also needed to release your App in the Play store.
Someone has argued source.android.com should be given a different name, similar to chromium and chrome. I think that would clear things up, too.
People who fork Android wouldn't really benefit from offering a separate SDK anyway. They would want to take advantage of the existing app ecosystem and preserve compatibility, just like Amazon is doing with Kindle Fire.
