In my opinion, acting like an engineer means accepting that you're only human and are going to make mistakes. Therefore, adopt tools and practices that reduce the chance of mistakes and reduce the damage when mistakes do occur.
In the case of SQL, pick a database interface that automatically escapes every string substituted into a query. This one architectural decision eliminates an entire class of bugs; it's much more effective than double checking hundreds of individual query constructions. And it has the added advantage that most queries will be using prepared statements which can execute faster than query strings.
They needed physical access to find the backdoor. To use the backdoor, they only need JTAG access. JTAG is typically used during development and not during operation, but there might be systems where the JTAG interface is still accessible during operation, either to allow easy debugging/patching in the field or because it was made available through some other interface during development and never removed afterward.
Another risk is that a stored AES key that is supposed to be unreadable was readable through the backdoor. So if the same key is used for multiple units, an attacker getting his hands on one unit can extract the key and do nasty things to other units.
I might be feeding a troll here, but I did a quick search and found this. Depending on the type of cell and the manufacturing process and where the panels will be deployed, somewhere between 1 and 3 years, while panels typically come with a 20 year warranty and will likely last 30 to 40 years. That study is from 2000, manufacturing may have become more efficient since then.
The array will produce far more energy during its lifetime than was used to produce and install it. So while it would be nice if it was built with renewable energy, it's not all that important.
It's not that hard to make a web app that is future proof, as long as you write it to comply with the specs from W3C. I have developed a web app, so I know that not everything is specified unambiguously and not all browsers follow the spec to the letter, but it yields much better results than coding to one specific browser version.
In our web app, over a period of about 5 years, the only regression on a browser upgrade I can recall is that IE8 would misrender VML. The very use of VML was a forced deviation from the specs because IE7 and 8 didn't support SVG (and while there is a VML spec, IE doesn't follow it).
Back when these IE6-only applications were developed it was already clear that they would never run in non-Microsoft browsers. To me, that made it a bad idea, but many people didn't care or even realize that there were platforms other than Microsoft's. What people (me included) didn't realize though, is that even later IE versions would be incompatible with IE6.
Both Apple and FreeBSD didn't want to adopt the GPLv3 versions of GCC, so they were stuck at GCC 4.2. Compared to that GCC version, the code generated by LLVM/Clang is not worse, in my experience.
Oh, I'm not arguing against Java in general, just that Java applets have fallen into disuse. The niche of applications that are too complex to implement in HTML + JavaScript but are still a good idea to run inside of the browser has shrunk to nearly nothing.
I have Java installed on my systems, but have the Java plugin disabled in the web browsers I regularly use. I came across exactly one site that required a Java applet to run in the last year or so: a system to book appointments at the local government office. Maybe it's different in the enterprise; the last big company I worked for had some kind of SAP front-end as a Java applet. But for home use Java is no longer necessary on a daily basis.
Page 4 of TFA states that the 30% was measured while gaming. Games typically put a high load on both the CPU and GPU; these are scenarios where the total power usage is high and therefore the screen and radios make up a smaller fraction of the power footprint.
Was it effective? I doubt Wilders would have become as popular as he is if Fortuyn were still around. At least Fortuyn was remarkably honest for a politician, while I get the impression that Wilders is playing one big popularity game. The problem is not Wilders himself, but that a large number of people vote for him.
As much as I dislike most of Wilders' ideas, his party did vote for network neutrality and against ratification of ACTA.
After this weekend's events, I don't think any other party is eager to having Wilders as an ally any time soon. So while he'll continue to create noise in the media, at least we can get a new government that is not held hostage by him.
In the Netherlands, our IRS-equivalent provides an income tax application. Not open source as far as I know, but there is a Windows, Mac and Linux version.
I have no problem with context sensitive ads. Google displays ads for Chrome on OS X when I browse from a Mac and Chrome for Linux when I browse from a Linux box; that's fine with me. It's also more efficient than Microsoft displaying ads for IE9 when I'm browsing from a Linux box.
When I read an article about electric cars, an ad for a car would not be out of place. Of course that ad would be wasted if I don't want to drive a car, cannot afford a car or just bought a new car. So the car company would be willing to pay more to Google to show the ad only to people who are in the market for a new car. However, to deliver that service Google has to create a much larger context than what the HTTP request by itself provides. They could get that information by looking at which other pages I visited, what I searched for, what I wrote in e-mails, what items I bought. However, this is where it gets creepy: when they follow me around everywhere and build a profile of my entire life. When a person does that, we call it stalking.
Google could be satisfied with selling ads based on limited context information. It wouldn't be as profitable per ad, but with the huge volume they have it should be enough to keep the company afloat. Instead, they want to provide higher value ads, like Facebook can. But I don't think there is a way to be like Facebook without being creepy. The only thing they can do about it is being less overt, as you say, but faking lower targeting accuracy (such as Target putting lawn mowers next to diapers) doesn't help if you want people to believe your "don't be evil" motto.
Today some don't have it, but this is a design for a future standard. Smartphones already have MPEG4 acceleration and I think hardware AES would take less transistors than MPEG4. Also, a software fallback for encryption is possible, so even if it would take a bit more power you'd still be able to use it. And when transistors continue to shrink computation will become cheaper over time, while the amount of power spent on the display and the radio will probably not decrease a lot.
I also realize that not all devices are smartphones, but the embedded market uses SoC designs and adding an encryption module to such a system would not cause a significant increase in footprint.
For every optional feature, the server will need code to deal with clients that do support it and clients that don't. It's more code to write and more potential for bugs. Of course this doesn't mean that every feature should be mandatory, but compression and encryption are already supported by pretty much every browser and server push would be a significant improvement over polling.
On metered connections, compression and server push would be improvements and encryption wouldn't make a difference. For power consumption, server push would be an improvement (polling means sending over a wireless link regularly), compression would probably not make much of a difference (assuming we're talking about gzip here) and encryption might tax the battery a bit more. However, if this is an issue, the common encryption algorithms could be hardware accelerated.
Wouldn't they have to honour it in all of the EU, being EU law..?
As far as I know, most "EU law" is actually EU guidelines that are put into national laws by the member states. So the member states will have very similar laws, but it's not a single law that is applied to the entire EU.
In the case of Apple's warranty, there was an item about this yesterday in a Dutch consumer rights TV program (Radar). They said there was a lawsuit in Italy about this exact same issue and Apple lost there. So it's likely Apple will lose similar suits in other EU countries, but separate lawsuits are needed for each country.
There is a lot of bad documentation out there, so Microsoft's is probably above average, but I wouldn't call it good. At least the.Net documentation is a huge collection of example code fragments but contains very little text that actually explains what the methods do. Especially important details like how the method reacts when the input is invalid, the state is invalid, the operation fails etc are often missing. Or some hint about the underlying implementation, so you can get a feeling which methods have to do a lot of work and which will return quickly. You can't learn those things from a code example, they have to be documented explicitly.
Wind and solar are not anywhere near being able to reduce our dependence on foreign oil. Rather than massively investing in building out wind and solar we should be spending all that money researching ways to make it viable instead of a gimmick designed to enrich campaign donors and their startups' poor business plans.
Wind and solar do produce a lot more energy than it costs to install and operate them. Whether it is economically viable to do so depends on the location and the business plan, but with fossil fuel getting more expensive the alternatives are going to be viable in many more situations.
It's the same with ethanol - it's not viable as an energy source, but it's quite profitable as a political source.
This is true for corn-based ethanol today, which runs on subsidies. However the next generation of biofuels will be created from waste material instead of the edible part of the plant. It's a lot easier to break even if your source material is considered waste today.
When there is a new hot area of technology, there are always people trying to make money without building a proper business. But just because a lot of the dotcoms failed doesn't mean it's impossible to build a profitable internet business.
It's hard for the average person to accept such a large swing in gas prices in such a short time especially when there are little alternatives. In Europe you have a good mass transit system. You even have Ryan Air for cheap air travel. The US doesn't have nearly as good system of trains and buses.
Although there are millions using mass transit, still the majority of people in Europe travels by car. For many people, the main alternative to a gas-guzzling car is a fuel efficient car. Since the last few years, almost all car ads here in the Netherlands emphasize fuel economy, either directly or indirectly (this car qualifies for a lower tax rate).
BTW, I'm a Republican and am no defender of Obama, but I would love to ask the Republican candidates who was in charge when gas prices started to ramp up in the year 2000 and why it did so.
Why would politicians be responsible for gas prices anyway? Demand for oil is rising faster than supply, so prices go up. We'll just have to accept that cheap energy is a thing of the past and act accordingly, by using it more efficiently.
Or you could release the server sources and let the player decide which server to connect to. From an algorithmic point of view, having a central authority during the game is a lot simpler than trying to reach distributed consensus between peers. It doesn't necessarily mean that there can be only one such authority in the entire world.
For LAN play, just run the server on the LAN. Maybe the server could even be integrated into the client application, for example a "host a game" option in the main menu that starts the server. DNS-SD (Bonjour) could be used by the clients to discover the server on the local network.
Every game in Apple's App Store has DRM, it's part of the system. You can make the source available as well though, so your users have the ability to make modifications to the client or port it to new devices. Put all the intelligence in the server, that way the client is simpler and you don't have to worry about people cheating by modifying the client.
For scalability, since this is based on a board game I would guess the number of players per game session is relatively low, which makes scaling easy: you can start new game sessions on the server with the lowest load. More difficult to scale is the matchmaking, where you do have to deal with the total worldwide number of players. Perhaps you can create a hash of the user ID and use that to determine which server handles authentication and status of users, like buckets in a hash table.
For deployment, I think this is one case where cloud computing is a good match: you can bring up move servers when there are a lot of players and bring them down again when demand is lower. This is especially useful if you get a lot of players when the game is first released or got some media attention but the number doesn't stay high; if you would buy your own servers you would be stuck with a lot of capacity that you don't use anymore. Ideally you'll either have the ability to migrate games between servers or a time limit on game length, so you can force games off a server when you want to shut it down.
Don't spend too much time on designing the perfectly scalable system though: a game with scalability issues is still better than a game that is never released at all. One thing that allows you to correct your mistakes is to make the client and server negotiate a protocol version. This allows later client versions to use a protocol version that is more suitable for scaling. If needed, you could even stop supporting old protocol versions at some point and instruct the user to upgrade the client.
Slashdot Mirror
In my opinion, acting like an engineer means accepting that you're only human and are going to make mistakes. Therefore, adopt tools and practices that reduce the chance of mistakes and reduce the damage when mistakes do occur.
In the case of SQL, pick a database interface that automatically escapes every string substituted into a query. This one architectural decision eliminates an entire class of bugs; it's much more effective than double checking hundreds of individual query constructions. And it has the added advantage that most queries will be using prepared statements which can execute faster than query strings.
They needed physical access to find the backdoor. To use the backdoor, they only need JTAG access. JTAG is typically used during development and not during operation, but there might be systems where the JTAG interface is still accessible during operation, either to allow easy debugging/patching in the field or because it was made available through some other interface during development and never removed afterward.
Another risk is that a stored AES key that is supposed to be unreadable was readable through the backdoor. So if the same key is used for multiple units, an attacker getting his hands on one unit can extract the key and do nasty things to other units.
They probably mean 100% renewable energy during operation, excluding construction.
I might be feeding a troll here, but I did a quick search and found this. Depending on the type of cell and the manufacturing process and where the panels will be deployed, somewhere between 1 and 3 years, while panels typically come with a 20 year warranty and will likely last 30 to 40 years. That study is from 2000, manufacturing may have become more efficient since then.
The array will produce far more energy during its lifetime than was used to produce and install it. So while it would be nice if it was built with renewable energy, it's not all that important.
It's not that hard to make a web app that is future proof, as long as you write it to comply with the specs from W3C. I have developed a web app, so I know that not everything is specified unambiguously and not all browsers follow the spec to the letter, but it yields much better results than coding to one specific browser version.
In our web app, over a period of about 5 years, the only regression on a browser upgrade I can recall is that IE8 would misrender VML. The very use of VML was a forced deviation from the specs because IE7 and 8 didn't support SVG (and while there is a VML spec, IE doesn't follow it).
Back when these IE6-only applications were developed it was already clear that they would never run in non-Microsoft browsers. To me, that made it a bad idea, but many people didn't care or even realize that there were platforms other than Microsoft's. What people (me included) didn't realize though, is that even later IE versions would be incompatible with IE6.
Both Apple and FreeBSD didn't want to adopt the GPLv3 versions of GCC, so they were stuck at GCC 4.2. Compared to that GCC version, the code generated by LLVM/Clang is not worse, in my experience.
Are new enterprise apps still being written as Java applets, or is the lifespan for enterprise apps just longer than consumer apps?
Oh, I'm not arguing against Java in general, just that Java applets have fallen into disuse. The niche of applications that are too complex to implement in HTML + JavaScript but are still a good idea to run inside of the browser has shrunk to nearly nothing.
I have Java installed on my systems, but have the Java plugin disabled in the web browsers I regularly use. I came across exactly one site that required a Java applet to run in the last year or so: a system to book appointments at the local government office. Maybe it's different in the enterprise; the last big company I worked for had some kind of SAP front-end as a Java applet. But for home use Java is no longer necessary on a daily basis.
Page 4 of TFA states that the 30% was measured while gaming. Games typically put a high load on both the CPU and GPU; these are scenarios where the total power usage is high and therefore the screen and radios make up a smaller fraction of the power footprint.
Was it effective? I doubt Wilders would have become as popular as he is if Fortuyn were still around. At least Fortuyn was remarkably honest for a politician, while I get the impression that Wilders is playing one big popularity game. The problem is not Wilders himself, but that a large number of people vote for him.
As much as I dislike most of Wilders' ideas, his party did vote for network neutrality and against ratification of ACTA.
After this weekend's events, I don't think any other party is eager to having Wilders as an ally any time soon. So while he'll continue to create noise in the media, at least we can get a new government that is not held hostage by him.
In the Netherlands, our IRS-equivalent provides an income tax application. Not open source as far as I know, but there is a Windows, Mac and Linux version.
I have no problem with context sensitive ads. Google displays ads for Chrome on OS X when I browse from a Mac and Chrome for Linux when I browse from a Linux box; that's fine with me. It's also more efficient than Microsoft displaying ads for IE9 when I'm browsing from a Linux box.
When I read an article about electric cars, an ad for a car would not be out of place. Of course that ad would be wasted if I don't want to drive a car, cannot afford a car or just bought a new car. So the car company would be willing to pay more to Google to show the ad only to people who are in the market for a new car. However, to deliver that service Google has to create a much larger context than what the HTTP request by itself provides. They could get that information by looking at which other pages I visited, what I searched for, what I wrote in e-mails, what items I bought. However, this is where it gets creepy: when they follow me around everywhere and build a profile of my entire life. When a person does that, we call it stalking.
Google could be satisfied with selling ads based on limited context information. It wouldn't be as profitable per ad, but with the huge volume they have it should be enough to keep the company afloat. Instead, they want to provide higher value ads, like Facebook can. But I don't think there is a way to be like Facebook without being creepy. The only thing they can do about it is being less overt, as you say, but faking lower targeting accuracy (such as Target putting lawn mowers next to diapers) doesn't help if you want people to believe your "don't be evil" motto.
No, they would spend a bit more power by doing decryption in software instead of hardware.
Today some don't have it, but this is a design for a future standard. Smartphones already have MPEG4 acceleration and I think hardware AES would take less transistors than MPEG4. Also, a software fallback for encryption is possible, so even if it would take a bit more power you'd still be able to use it. And when transistors continue to shrink computation will become cheaper over time, while the amount of power spent on the display and the radio will probably not decrease a lot.
I also realize that not all devices are smartphones, but the embedded market uses SoC designs and adding an encryption module to such a system would not cause a significant increase in footprint.
For every optional feature, the server will need code to deal with clients that do support it and clients that don't. It's more code to write and more potential for bugs. Of course this doesn't mean that every feature should be mandatory, but compression and encryption are already supported by pretty much every browser and server push would be a significant improvement over polling.
On metered connections, compression and server push would be improvements and encryption wouldn't make a difference. For power consumption, server push would be an improvement (polling means sending over a wireless link regularly), compression would probably not make much of a difference (assuming we're talking about gzip here) and encryption might tax the battery a bit more. However, if this is an issue, the common encryption algorithms could be hardware accelerated.
A guideline is voluntary, EU directives most certainly not.
Indeed "directive" is the correct word here, I just couldn't think of it when writing my post.
Wouldn't they have to honour it in all of the EU, being EU law..?
As far as I know, most "EU law" is actually EU guidelines that are put into national laws by the member states. So the member states will have very similar laws, but it's not a single law that is applied to the entire EU.
In the case of Apple's warranty, there was an item about this yesterday in a Dutch consumer rights TV program (Radar). They said there was a lawsuit in Italy about this exact same issue and Apple lost there. So it's likely Apple will lose similar suits in other EU countries, but separate lawsuits are needed for each country.
There is a lot of bad documentation out there, so Microsoft's is probably above average, but I wouldn't call it good. At least the .Net documentation is a huge collection of example code fragments but contains very little text that actually explains what the methods do. Especially important details like how the method reacts when the input is invalid, the state is invalid, the operation fails etc are often missing. Or some hint about the underlying implementation, so you can get a feeling which methods have to do a lot of work and which will return quickly. You can't learn those things from a code example, they have to be documented explicitly.
Wind and solar are not anywhere near being able to reduce our dependence on foreign oil. Rather than massively investing in building out wind and solar we should be spending all that money researching ways to make it viable instead of a gimmick designed to enrich campaign donors and their startups' poor business plans.
Wind and solar do produce a lot more energy than it costs to install and operate them. Whether it is economically viable to do so depends on the location and the business plan, but with fossil fuel getting more expensive the alternatives are going to be viable in many more situations.
It's the same with ethanol - it's not viable as an energy source, but it's quite profitable as a political source.
This is true for corn-based ethanol today, which runs on subsidies. However the next generation of biofuels will be created from waste material instead of the edible part of the plant. It's a lot easier to break even if your source material is considered waste today.
When there is a new hot area of technology, there are always people trying to make money without building a proper business. But just because a lot of the dotcoms failed doesn't mean it's impossible to build a profitable internet business.
It's hard for the average person to accept such a large swing in gas prices in such a short time especially when there are little alternatives. In Europe you have a good mass transit system. You even have Ryan Air for cheap air travel. The US doesn't have nearly as good system of trains and buses.
Although there are millions using mass transit, still the majority of people in Europe travels by car. For many people, the main alternative to a gas-guzzling car is a fuel efficient car. Since the last few years, almost all car ads here in the Netherlands emphasize fuel economy, either directly or indirectly (this car qualifies for a lower tax rate).
BTW, I'm a Republican and am no defender of Obama, but I would love to ask the Republican candidates who was in charge when gas prices started to ramp up in the year 2000 and why it did so.
Why would politicians be responsible for gas prices anyway? Demand for oil is rising faster than supply, so prices go up. We'll just have to accept that cheap energy is a thing of the past and act accordingly, by using it more efficiently.
Or you could release the server sources and let the player decide which server to connect to. From an algorithmic point of view, having a central authority during the game is a lot simpler than trying to reach distributed consensus between peers. It doesn't necessarily mean that there can be only one such authority in the entire world.
For LAN play, just run the server on the LAN. Maybe the server could even be integrated into the client application, for example a "host a game" option in the main menu that starts the server. DNS-SD (Bonjour) could be used by the clients to discover the server on the local network.
Every game in Apple's App Store has DRM, it's part of the system. You can make the source available as well though, so your users have the ability to make modifications to the client or port it to new devices. Put all the intelligence in the server, that way the client is simpler and you don't have to worry about people cheating by modifying the client.
For scalability, since this is based on a board game I would guess the number of players per game session is relatively low, which makes scaling easy: you can start new game sessions on the server with the lowest load. More difficult to scale is the matchmaking, where you do have to deal with the total worldwide number of players. Perhaps you can create a hash of the user ID and use that to determine which server handles authentication and status of users, like buckets in a hash table.
For deployment, I think this is one case where cloud computing is a good match: you can bring up move servers when there are a lot of players and bring them down again when demand is lower. This is especially useful if you get a lot of players when the game is first released or got some media attention but the number doesn't stay high; if you would buy your own servers you would be stuck with a lot of capacity that you don't use anymore. Ideally you'll either have the ability to migrate games between servers or a time limit on game length, so you can force games off a server when you want to shut it down.
Don't spend too much time on designing the perfectly scalable system though: a game with scalability issues is still better than a game that is never released at all. One thing that allows you to correct your mistakes is to make the client and server negotiate a protocol version. This allows later client versions to use a protocol version that is more suitable for scaling. If needed, you could even stop supporting old protocol versions at some point and instruct the user to upgrade the client.