In the particular case of dogs, I'd argue that having contact with humans is their natural way of living. Over ten thousand years of contact with humans has shaped the species. There is no way you can consider any dog to be not exposed to humans: it's in their genes.
As far as I know, NPAPI plugins can't be sandboxed effectively. So they are indeed security risks. You could argue whether it is Google or the end user that should decide what risks to take with plugins, but given how easily people click "Yes" without even reading the question, I don't really blame them for not leaving this to the end user.
As for an open web, what did plugins ever do to open the web? The most popular plug-in is Flash, which is proprietary. Silverlight is proprietary; it has an open source clone that never actually worked when I tried. Java is open source but Java Applets are pretty much obsolete today.
I do share the concern that Chrome is becoming too dominant. Moving to PPAPI plugins would not be a step forward, but phasing out plugins altogether would be.
I think the eco aspect is not in the race itself, but in F1 acting as R&D for technologies that will eventually end up in consumer cars. By having fuel restrictions, they're forcing the engineers to look for ways to do more with the same amount of fuel.
That's a good idea. You could even present the hash in a more accessible way, like picking two words from a dictionary or showing three icons from a fixed set.
It could be handled like SSH: when you get an invite to connect to someone, their key fingerprint is displayed. If you are paranoid, you can verify the fingerprint via alternative channels. Otherwise, you blindly accept it. In either case, you are protected against man in the middle attacks after that first connection is made. Also, if you did accept a fake key, any time you try to talk to that person over a network where the man in the middle is not present will trigger a key mismatch, revealing that an attack took place on the initial connect.
It's a buzzword for demanding federal control of the internet, to remedy the government-caused problem of last mile providers who are protected from competition by local cable monopoly privileges.
What kind of additional control would net neutrality give the government over the internet besides the enforcing net neutrality itself?
Besides, I doubt any possible negative side effects of net neutrality would come close to the problem of ongoing massive warrantless spying, so if you're worried about government control over the internet, this seems like the wrong battle to pick.
All we need to solve the problem of the Comcasts and the Time-warners of the world is to expose them to competition.
That may not be easy... The big telcos lobby for laws protecting them from municipal broadband, but as far as I know they are not protected from commercial rivals, yet few are challenging them.
Here in the Netherlands when it comes to broadband competition, on ADSL there is a lot of competition because the government forced the leading telco (KPN, the former state telco) to share their telephone lines with other ISPs, since those lines were laid with public money. On cable, for some reason such a line sharing wasn't enforced, so two big companies (UPC and Ziggo) bought all the local cable networks and are now trying to merge, meaning there will be one giant cable company for the entire country (*). On fiber, there used to be a lot of different ISPs, but KPN bought most of them and a few other failed (probably because of mismanagement), so there is very little competition left there as well.
(*) I do agree with the cable companies' reasoning that they are not competing against each other anyway, since they don't operate in the same areas: every house has at most one cable connection. But in my opinion the line sharing should have been enforced for cable too, since those networks were also built with public money. But they were owned by local governments and sold for a lot of money during the dot-com boom (unlike KPN, which was owned by the state and then privatized), so I guess it would be unfair to change the conditions for network use after selling them.
My point is that mergers and acquisitions will reduce competition, even in situations where there are no corrupt laws blocking healthy competition. So I think it's wishful thinking that if you allow competition it will automatically come into existence, regardless of properties of the specific market.
There is also a practical aspect: it is inefficient to have to run several cables to each house. In my opinion, ideally each house would be connected to a single fiber optic cable, over which an unlimited number of ISPs could offer their services. The last mile is not a good place to look for competition; the rest of the service is.
I don't think the prevailing winds matter all that much: it is the winds in the first days after the accident that matter, since during that time the radioactive particles were still in the air. I know that here in the Netherlands (west of Germany) in the months after the accident some types of crops were destroyed because they were considered unsafe for consumption.
Git is used to maintain the Linux kernel; I don't think any game has a rate of commits that comes even close to that. The problem you're referring to is probably that Git is not designed to handle large binary data efficiently. That doesn't make it a joke, but it could disqualify it for a particular use.
Unfortunately the site hosting TFA from that story seems to be gone. In my opinion the most deceptive thing about 80's game boxes wasn't the cover art: it was pretty clear it wasn't representative of the in-game graphics. However, a lot of games were available on multiple systems and the box would often feature screen shots from a different system. Some had fine print stating which system the shots were from and some didn't even have that, but in either case there were more than a few game boxes with screen shots that looked significantly better than the game inside the box would.
After reading the article from dmbrun's post, it seems what they're doing is a single code base, more shared APIs across Windows variants and a single store interface. So it's mostly focused on making it easy for developers to support multiple Windows variants. A smart move, but nothing revolutionary.
The third link is not actually a link, since the <a> tag is missing the href attribute. I wanted to check what the CEO actually said, since "unify" could mean a lot of things.
Are they going for x86-64 only, killing the ARM-based WIndows RT, as Hot Hardware is reporting? They'd still have to keep ARM support for Windows Mobile. Perhaps they should have put Windows Mobile plus some tablet extensions on the low-budget tablets, that would have fit people's expectations a lot better.
Are they going for a single code base? In that case there would be multiple products created from that code base, so that doesn't tell us anything about the fate of Windows RT or any other specific products.
Are they going for a single product named Windows? While I think it would be good to drop the artificial home/pro/ultimate differentiation, having a different Windows for client and server use is still useful. Although that could be handled by having a different default configuration rather than an entirely different product.
Another reason cheat codes existed is that without them, a lot of players couldn't finish the game. I think there are several reasons for this: the arcade roots, a larger percentage of hardcore gamers, the need to prevent the player from finishing an expensive game quickly after buying or renting it and game design being a much younger discipline.
Don't get me wrong, I actually prefer today's easier games, but it does mean that you don't really need a cheat code anymore to finish most games. Instead of having the difficulty increase a lot as the levels progress, games now have selectable difficulty from the start and achievements to add challenge for more talented and/or experienced players.
Chrome extensions are tied to your Google account, and Google has pretty much complete control over them. Chrome, as a browser, does not need to be tied to a Google account (although it will suggest that you do so) and its automatic updating can be disabled.
Not updating your browser will also leave you vulnerable. You could download updated Chrome installs from a generic download page, using a different browser and an IP address that is not associated with you, instead of accepting (possibly customized) automatic updates. That would be safe under the assumption that the generic Chrome build is not trojaned.
More to the point, though, I can securely send messages even though a compromised browser, if I encrypt the messages externally.
True, but then it would be more convenient to send messages from an external mail application and not use web mail at all.
That and the lobbyists: if there were fewer of these agreements in negotiation there would be less work for them. Not all GDP increases are actually useful. In the Netherlands we had an exceptionally soft winter; the GDP decreased because less natural gas was sold.
If you're worried about Google itself being forced to compromise this extension, you shouldn't be using Chrome at all.
In any case, the current state of webmail is typically messages stored as plain text, transmitted over secure sockets. Encrypting the message itself is a big step forward.
This is Google's hedge against increasingly higher costs for peering and neutrality breaking ISP's, so why would they then turn around and be hypocrites by ruining the very reason they're moving intro infrastucture to begin with?
Android started in much the same way, to avoid telcos getting control over the content people access on their phones. While the base OS of Android is still free, a lot of the standard applications are now licensed from Google and the terms for licensing them are becoming more strict. Google's fiber is neutral today, but that doesn't mean it will stay neutral forever.
They tried to go for the infotainment market with the ARM-based Windows RT, but it found very few customers, mainly because there are not many apps for it. A "Surface Mini" would only have a chance if it runs on x86 and I don't know how feasible it is to produce a small light x86 tablet that gets a decent battery life, while also being affordable and powerful enough to run Windows 8.
So I don't know if I would call this a long-term strategy or just facing the realities of today.
Yesterday there was a headline saying 300,000 servers remain vulnerable to Heartbleed. So the bug is still (ab)usable even after it has been published.
We could try to raise funds to pay for reverse engineering of the VPU in the Novena laptop -- if we could find skilled reverse engineers ready to take the job. Can you introduce me to any?
The GPU is a Vivante GC2000, which has been partially reverse engineered already; support is being added to etnaviv, which is a user-space driver -- the part connecting Mesa + Gallium to the kernel driver -- for the Vivante graphics cores (support older cores like the GC860 is good enough for everyday use). The kernel driver itself (galcore) is available under GPL, although it could use a cleanup. So there is no need to reverse engineer everything from scratch, but the etnaviv project could certainly use more contributors.
There is also a video decoding acceleration block in the i.MX6, but like all things H.264 that is likely a patent minefield, so I'm not sure it would be worth spending a lot of resources on reverse engineering that.
Also, drives aren't proper backup, unless they're offsite, and these discs pack 50GB each, more than enough for most discrete items on your 3TB drive (what do you need that for anyway, HD porn?)
Optical discs aren't a proper backup either unless you store them offsite: they are easily destroyed in a fire or taken by a burglar.
I think encrypted online backup is a far more convenient solution than optical discs: it can run as a background process instead of requiring the user to insert a blank disc regularly.
Well, I'd argue that a library that needs a single global init call is itself a poorly implemented singleton with all the associated problems. It is unfortunately a common occurrence and wrapping it in a singleton class is a way to deal with it. But in my opinion that is making the best of a bad situation rather than a pattern that I'd recommend if you have anything to say about the library interface.
I have seen a lot of singleton use in C++ unrelated to libraries and most of those uses became problematic at some point. In C++ in particular, the fact that with a singleton you can't control the moment it destructs can be a problem if the destructor needs to do more than free memory.
If you like Dijkstra's style, I can recommend Programming: The Derivation of Algorithms by Kaldewaij. For details, see my favorites list in a later post.
Computer Architecture: A Quantitative Approach by Hennessy & Patterson
Helps you understand what goes on inside a computer at the hardware and OS level, as well as illustrating how you can reason about the performance of a system before you actually build it.
Computer Graphics: Principles and Practice by Foley & van Dam
A good starting point for learning about computer graphics. Not all of it is still relevant, but even if you skip the chapters about vector displays and user interfaces there is still plenty of useful material in there.
Programming: The Derivation of Algorithms by Kaldewaij
Teaches a way of constructing algorithms that are provably correct. Although I rarely follow this approach to the letter (it is very time consuming), elements of it are extremely valuable in everyday programming. For example, thinking in terms of preconditions, postconditions and invariants (design by contract) helps in designing good interfaces, finding bugs, placing useful asserts etc. Even just thinking to yourself "could I prove this program?" without actually doing it is useful, since if the answer is negative, the program is too complex and probably incorrect.
Slashdot Mirror
In the particular case of dogs, I'd argue that having contact with humans is their natural way of living. Over ten thousand years of contact with humans has shaped the species. There is no way you can consider any dog to be not exposed to humans: it's in their genes.
As far as I know, NPAPI plugins can't be sandboxed effectively. So they are indeed security risks. You could argue whether it is Google or the end user that should decide what risks to take with plugins, but given how easily people click "Yes" without even reading the question, I don't really blame them for not leaving this to the end user.
As for an open web, what did plugins ever do to open the web? The most popular plug-in is Flash, which is proprietary. Silverlight is proprietary; it has an open source clone that never actually worked when I tried. Java is open source but Java Applets are pretty much obsolete today.
I do share the concern that Chrome is becoming too dominant. Moving to PPAPI plugins would not be a step forward, but phasing out plugins altogether would be.
I think the eco aspect is not in the race itself, but in F1 acting as R&D for technologies that will eventually end up in consumer cars. By having fuel restrictions, they're forcing the engineers to look for ways to do more with the same amount of fuel.
That's a good idea. You could even present the hash in a more accessible way, like picking two words from a dictionary or showing three icons from a fixed set.
It could be handled like SSH: when you get an invite to connect to someone, their key fingerprint is displayed. If you are paranoid, you can verify the fingerprint via alternative channels. Otherwise, you blindly accept it. In either case, you are protected against man in the middle attacks after that first connection is made. Also, if you did accept a fake key, any time you try to talk to that person over a network where the man in the middle is not present will trigger a key mismatch, revealing that an attack took place on the initial connect.
It's a buzzword for demanding federal control of the internet, to remedy the government-caused problem of last mile providers who are protected from competition by local cable monopoly privileges.
What kind of additional control would net neutrality give the government over the internet besides the enforcing net neutrality itself?
Besides, I doubt any possible negative side effects of net neutrality would come close to the problem of ongoing massive warrantless spying, so if you're worried about government control over the internet, this seems like the wrong battle to pick.
All we need to solve the problem of the Comcasts and the Time-warners of the world is to expose them to competition.
That may not be easy... The big telcos lobby for laws protecting them from municipal broadband, but as far as I know they are not protected from commercial rivals, yet few are challenging them.
Here in the Netherlands when it comes to broadband competition, on ADSL there is a lot of competition because the government forced the leading telco (KPN, the former state telco) to share their telephone lines with other ISPs, since those lines were laid with public money. On cable, for some reason such a line sharing wasn't enforced, so two big companies (UPC and Ziggo) bought all the local cable networks and are now trying to merge, meaning there will be one giant cable company for the entire country (*). On fiber, there used to be a lot of different ISPs, but KPN bought most of them and a few other failed (probably because of mismanagement), so there is very little competition left there as well.
(*) I do agree with the cable companies' reasoning that they are not competing against each other anyway, since they don't operate in the same areas: every house has at most one cable connection. But in my opinion the line sharing should have been enforced for cable too, since those networks were also built with public money. But they were owned by local governments and sold for a lot of money during the dot-com boom (unlike KPN, which was owned by the state and then privatized), so I guess it would be unfair to change the conditions for network use after selling them.
My point is that mergers and acquisitions will reduce competition, even in situations where there are no corrupt laws blocking healthy competition. So I think it's wishful thinking that if you allow competition it will automatically come into existence, regardless of properties of the specific market.
There is also a practical aspect: it is inefficient to have to run several cables to each house. In my opinion, ideally each house would be connected to a single fiber optic cable, over which an unlimited number of ISPs could offer their services. The last mile is not a good place to look for competition; the rest of the service is.
I don't think the prevailing winds matter all that much: it is the winds in the first days after the accident that matter, since during that time the radioactive particles were still in the air. I know that here in the Netherlands (west of Germany) in the months after the accident some types of crops were destroyed because they were considered unsafe for consumption.
Git is used to maintain the Linux kernel; I don't think any game has a rate of commits that comes even close to that. The problem you're referring to is probably that Git is not designed to handle large binary data efficiently. That doesn't make it a joke, but it could disqualify it for a particular use.
Unfortunately the site hosting TFA from that story seems to be gone. In my opinion the most deceptive thing about 80's game boxes wasn't the cover art: it was pretty clear it wasn't representative of the in-game graphics. However, a lot of games were available on multiple systems and the box would often feature screen shots from a different system. Some had fine print stating which system the shots were from and some didn't even have that, but in either case there were more than a few game boxes with screen shots that looked significantly better than the game inside the box would.
After reading the article from dmbrun's post, it seems what they're doing is a single code base, more shared APIs across Windows variants and a single store interface. So it's mostly focused on making it easy for developers to support multiple Windows variants. A smart move, but nothing revolutionary.
The third link is not actually a link, since the <a> tag is missing the href attribute. I wanted to check what the CEO actually said, since "unify" could mean a lot of things.
Are they going for x86-64 only, killing the ARM-based WIndows RT, as Hot Hardware is reporting? They'd still have to keep ARM support for Windows Mobile. Perhaps they should have put Windows Mobile plus some tablet extensions on the low-budget tablets, that would have fit people's expectations a lot better.
Are they going for a single code base? In that case there would be multiple products created from that code base, so that doesn't tell us anything about the fate of Windows RT or any other specific products.
Are they going for a single product named Windows? While I think it would be good to drop the artificial home/pro/ultimate differentiation, having a different Windows for client and server use is still useful. Although that could be handled by having a different default configuration rather than an entirely different product.
Yes, it's a reference board. What's new about it is that it contains a 64-bit ARM processor.
For what it's worth, I thought the summary was very informative.
Another reason cheat codes existed is that without them, a lot of players couldn't finish the game. I think there are several reasons for this: the arcade roots, a larger percentage of hardcore gamers, the need to prevent the player from finishing an expensive game quickly after buying or renting it and game design being a much younger discipline.
Don't get me wrong, I actually prefer today's easier games, but it does mean that you don't really need a cheat code anymore to finish most games. Instead of having the difficulty increase a lot as the levels progress, games now have selectable difficulty from the start and achievements to add challenge for more talented and/or experienced players.
Chrome extensions are tied to your Google account, and Google has pretty much complete control over them. Chrome, as a browser, does not need to be tied to a Google account (although it will suggest that you do so) and its automatic updating can be disabled.
Not updating your browser will also leave you vulnerable. You could download updated Chrome installs from a generic download page, using a different browser and an IP address that is not associated with you, instead of accepting (possibly customized) automatic updates. That would be safe under the assumption that the generic Chrome build is not trojaned.
More to the point, though, I can securely send messages even though a compromised browser, if I encrypt the messages externally.
True, but then it would be more convenient to send messages from an external mail application and not use web mail at all.
That and the lobbyists: if there were fewer of these agreements in negotiation there would be less work for them. Not all GDP increases are actually useful. In the Netherlands we had an exceptionally soft winter; the GDP decreased because less natural gas was sold.
If you're worried about Google itself being forced to compromise this extension, you shouldn't be using Chrome at all.
In any case, the current state of webmail is typically messages stored as plain text, transmitted over secure sockets. Encrypting the message itself is a big step forward.
This is Google's hedge against increasingly higher costs for peering and neutrality breaking ISP's, so why would they then turn around and be hypocrites by ruining the very reason they're moving intro infrastucture to begin with?
Android started in much the same way, to avoid telcos getting control over the content people access on their phones. While the base OS of Android is still free, a lot of the standard applications are now licensed from Google and the terms for licensing them are becoming more strict. Google's fiber is neutral today, but that doesn't mean it will stay neutral forever.
They tried to go for the infotainment market with the ARM-based Windows RT, but it found very few customers, mainly because there are not many apps for it. A "Surface Mini" would only have a chance if it runs on x86 and I don't know how feasible it is to produce a small light x86 tablet that gets a decent battery life, while also being affordable and powerful enough to run Windows 8.
So I don't know if I would call this a long-term strategy or just facing the realities of today.
I would like to spend more of my time creating new things rather than fighting to make existing things work together.
Yesterday there was a headline saying 300,000 servers remain vulnerable to Heartbleed. So the bug is still (ab)usable even after it has been published.
We could try to raise funds to pay for reverse engineering of the VPU in the Novena laptop -- if we could find skilled reverse engineers ready to take the job. Can you introduce me to any?
A quick search turns up this product description which points to the Freescale i.MX6Q specs.
Does anyone know what he means with "VPU"?
The GPU is a Vivante GC2000, which has been partially reverse engineered already; support is being added to etnaviv, which is a user-space driver -- the part connecting Mesa + Gallium to the kernel driver -- for the Vivante graphics cores (support older cores like the GC860 is good enough for everyday use). The kernel driver itself (galcore) is available under GPL, although it could use a cleanup. So there is no need to reverse engineer everything from scratch, but the etnaviv project could certainly use more contributors.
There is also a video decoding acceleration block in the i.MX6, but like all things H.264 that is likely a patent minefield, so I'm not sure it would be worth spending a lot of resources on reverse engineering that.
Also, drives aren't proper backup, unless they're offsite, and these discs pack 50GB each, more than enough for most discrete items on your 3TB drive (what do you need that for anyway, HD porn?)
Optical discs aren't a proper backup either unless you store them offsite: they are easily destroyed in a fire or taken by a burglar.
I think encrypted online backup is a far more convenient solution than optical discs: it can run as a background process instead of requiring the user to insert a blank disc regularly.
Well, I'd argue that a library that needs a single global init call is itself a poorly implemented singleton with all the associated problems. It is unfortunately a common occurrence and wrapping it in a singleton class is a way to deal with it. But in my opinion that is making the best of a bad situation rather than a pattern that I'd recommend if you have anything to say about the library interface.
I have seen a lot of singleton use in C++ unrelated to libraries and most of those uses became problematic at some point. In C++ in particular, the fact that with a singleton you can't control the moment it destructs can be a problem if the destructor needs to do more than free memory.
If you like Dijkstra's style, I can recommend Programming: The Derivation of Algorithms by Kaldewaij. For details, see my favorites list in a later post.
Computer Architecture: A Quantitative Approach by Hennessy & Patterson Helps you understand what goes on inside a computer at the hardware and OS level, as well as illustrating how you can reason about the performance of a system before you actually build it. Computer Graphics: Principles and Practice by Foley & van Dam A good starting point for learning about computer graphics. Not all of it is still relevant, but even if you skip the chapters about vector displays and user interfaces there is still plenty of useful material in there. Programming: The Derivation of Algorithms by Kaldewaij Teaches a way of constructing algorithms that are provably correct. Although I rarely follow this approach to the letter (it is very time consuming), elements of it are extremely valuable in everyday programming. For example, thinking in terms of preconditions, postconditions and invariants (design by contract) helps in designing good interfaces, finding bugs, placing useful asserts etc. Even just thinking to yourself "could I prove this program?" without actually doing it is useful, since if the answer is negative, the program is too complex and probably incorrect.