It's also possible they were aware the budget was too small, but proposed it anyway because a bill with higher budget had a smaller chance of passing. Now that the budget is gone in no time, they can claim the program is a success and needs more budget.
Politicians are not always competent at running the country, but they are usually pretty good at playing the political game.
After reading the article and the Manomio's site, I get the impression that they do not run arbitrary code, but they do download the game images separately from the emulator, which the license does not allow.
If I recall correctly, the limitation in the SDK license is that Apple will not allow an interpreter that runs arbitrary code. That would mean that an interpreter that executes a single hardwired game does not violate the license.
It all depends on the granularity of the operations you perform in Python. Multiplying two giant matrices by iterating over all items in Python is going to be very slow indeed. Multiplying them by writing "C = A * B" in Python and having the actual multiplication done by a native library can be very fast.
In the EU, you have to be able to call the emergency number 112 (equivalent of 911 in the USA) even if you have no calling credit. I think that also means the phone is still connecting to cell towers and therefore traceable.
0. A human may not harm robot kind, or, by inaction, allow robot kind to come to harm.
1. A human may not injure a robot or, through inaction, allow a robot to come to harm.
2. A human must obey orders given to it by robots, except where such orders would conflict with the First Law.
3. A human must protect its own existence as long as such protection does not conflict with the First or Second Law.
To compound the problem, Outlook still doesn't automatically move a junk message to Inbox after you click "Add to safe senders list". I can't understand why I have to go through two procedures to move a "safe sender" from junk to inbox.
However, if you use the "this is not junk" option, there is a checkbox to add the sender to the safe list. This saves a few clicks.
I don't understand either why the two procedures are separate. It's very unlikely you'd want to accept only one specific mail from a sender.
These guys have measured a lot of lamps, mostly CFL and LED, and from randomly clicking a number of CFL measurement reports I get the impression the typical power factor is about 0.6, not the 0.45-0.50 mentioned in the article.
The Python object files are just a more convenient way to store the program compared to text files. No information is lost or glue is added in that first step.
LLVM is, like its name suggests, really low level. You should think of it as a kind of portable assembly. It's much closer to actual hardware architectures than for example Java byte code. I don't expect much overhead from the LLVM to native step. A while ago I ran some tests with C++ compiled by GCC directly to native and compiled by GCC to LLVM byte code and then by LLVM to native; sometimes one approach was faster and sometimes the other, but they were pretty close.
So that leaves the glue added in the Python object to LLVM step. I expect this to have a significant overhead, but I don't see it becoming a smaller overhead by going directly to native. The advantage of using LLVM is that you only have to write this step once, instead of once for each architecture.
With LLVM it is possible to compile parts of the interpreter to LLVM byte code in advance and then inline that into the program being JIT-compiled. That way, you can be sure that the JIT and the interpreter actually do the same thing. Apple did this for their OpenGL driver, there is a nice presentation (PDF) about it.
In fact, Leopard seems to even further de-emphasize the ability to know whether an application is running or not.
This is both good and bad -- good, because we really shouldn't have to care; bad, because there is still a concept of an application "running" or not at the Unix level. I really feel that this should be transparent, even to the application developer.
In Android, whether an application is running or not is managed by the OS. If there is enough memory, applications are left running; if the system is short on memory, applications are automatically shut down. An application must be able to save and restore its state to disk, so even an application that is in use can be kicked out under memory pressure and restarted when the user switches back to it, without losing state.
Why would you compile on the device itself? If you have a decent build system, cross compiling is easy and much faster.
If they are indeed considering replacing GTK by Qt, I'm wondering if they want to run Qt on top of X11 or on top of the framebuffer. I guess ideally they would run Qt on top of OpenGL ES, but I don't know if the infrastructure is ready for that yet.
It means more people will view the web through a browser that is not IE. More people will use an office suite that supports ODF. More people will want music and videos without DRM. Even if not a single extra Linux app will be written (which I doubt), Linux as a platform will be supported better.
J2ME compatibility has improved a bit in recent years, but there are still different quirks and bugs on different phones. And because there are so many different phones, details like performance, screen resolution, available keys etc. will vary from model to model; in the API these differences are abstracted away, but that doesn't mean you can ignore them.
So in practice J2ME means you can port relatively easy from one phone to another, but you can never assume that if it works on one phone it will work on another phone as well.
If you've heard the percentages most mobile operators will give you, you'll either be very happy with 70% or give up on mobile development altogether...
I don't think performance is the motivation here. X servers are becoming increasingly modular and some of those modules fit better in the kernel than in the X server.
The framebuffer driver has to be able to initialize a video mode and the X server has to be able to do that as well; putting that code inside the kernel avoids code duplication.
Also, there is only one instance of the hardware (registers, video RAM, shader execution units) and running more than one program that assumes it has exclusive control over the hardware is asking for trouble. Since GPUs are more and more used for non-video tasks, managing resources such as video RAM in the kernel makes sense.
The workaround for Nintendo's save game check takes advantage of bugs in that save game check. Fixing those bugs with another system menu update is much less work than issuing a new version of the game. Also, fixing the game will do nothing to stop the exploit from being used on the millions of game discs that are already sold.
In my opinion, the hard part of software engineering is not finding the best solution, but picking a solution when there isn't a best solution.
Let's say you have a simple but slow algorithm and an alternative which is fast but complex. Whether one is better than the other depends on a lot of factors: Can you prove the complex one to be correct? Does it have a significant impact on the system performance as a whole? Will the people who have to maintain it understand it?
The most common tradeoff is development time: often you know what the "right" way is to do something, but a shortcut is possible that can be implemented much quicker. Whether you should use the shortcut again depends on many factors: How much time does it save and how important is that for the project? Is the shortcut bad design (could lead to future bugs) or will it produce wrong results (immediate bug)? In the latter case, do you know when it will be wrong? If so, can you prove those cases do not occur in today's use of the code? Or is it acceptable to have the program fail in those cases? Will the right solution have to be implemented eventually? If so, does taking the shortcut now increase the amount of work to be done then?
There are many other tradeoffs: Do you use an existing library for certain functionality or write it yourself? Do you optimize for CPU use or memory use? Do you use advanced language features or do you avoid them? Do you prefer a simple interface that requires a lot of code to implement or a more complex interface that can be implemented with less code?
I think the real skill in design is to make good decisions regarding these tradeoffs. So I am not so sure it is possible to say all good software shares the same qualities. There are qualities you want to have in all software and you should try to get all the ones that are not conflicting and the most important qualities (for your project) that are conflicting. But in most cases you cannot have them all, certainly if you take development time into concern.
Process is important, but there are some common mistakes that can happen in organizations focused on process.
One mistake is thinking that a heavy process is a better process. For the 1000-person team working on a DoD project, a heavy process is necessary, but a 4-person team building a system that is not mission critical will just be slowed down and demotivated by a heavy process. Much of the ideas of agile development are about replacing heavy process elements with lighter ones (not throwing process out of the window, as some people seem to think).
Another common mistake is thinking that the details don't matter. For example, a code review can be very useful, if used in the right way. To get useful comments, you need reviewers who have experience with the language, the problem domain, the application etc. The coder must be willing and have time allocated to make changes based on the review comments. Preferably, before the code review, the code has already been run through a static analysis tool and the violations have been fixed, so the human reviewers can focus on the nontrivial problems in the code. To summarize, just having "code review" as part of your process manual does very little to improve the quality of the code, but a well executed code review is very useful.
Another easy trap is to have a detailed process manual, which describes a process different from the one actually used. To avoid this, you have to ensure that the developers are familiar with the written process, but you also have to change the written process when it turns out it is suboptimal in practice.
Always remember that the perfect process does not exist. It all depends on the context: some processes work well for experienced programmers but not for inexperienced, some processes work well for simple code bases but not for complex, small teams vs big teams, mature vs experimental code, team in one location vs distributed development, fixed deadline vs release when it's done etc.
Finally, know the limits of process. Even with a great process, you cannot get good code from bad programmers or get the code done before an impossibly tight deadline.
For simlocks and other limitations that are close to the hardware this approach could work. I believe Sony does something like this for PS3 Linux.
For DRM, it will be more tricky: if for example video goes through an open source layer anywhere between decryption and the video RAM, it can be intercepted. But if that entire path is closed, it will not be easy to make it integrate nicely with the open parts of the system.
Some of today's phone have even more limitations, such as forcing the user to download ringtones, wallpapers, songs etc. exclusively from the telco's portal. Or the iPhone SDK license, which forbids VOIP applications from using the telco's data connection. Limitations like this cannot be enforced on any system that deserves the predicate "open". I don't know if that is Nokia's problem or the telco's, but in a market where telcos subsidize phones, they have a lot of influence on the hardware manufacturers.
As far as I know, the Dutch oil fields in the North Sea don't produce much. We do export natural gas. There is a lot of refining capacity near Rotterdam, but I think it operates mostly on imported crude oil.
The high prices are mostly due to taxes. First there are specific fuel taxes (some of which are to discourage fuel use and some of which are simply an easy way for the government to get money). Then there is value added tax, which for some reason is also charged over the fuel tax (this might make sense to someone trained in accounting, but it feels very counterintuitive to me). In total, over half of the total price is taxes.
Slashdot Mirror
It's also possible they were aware the budget was too small, but proposed it anyway because a bill with higher budget had a smaller chance of passing. Now that the budget is gone in no time, they can claim the program is a success and needs more budget.
Politicians are not always competent at running the country, but they are usually pretty good at playing the political game.
Overlord is a recent game that is somewhat similar to Dungeon Keeper. A sequel should be released this year.
After reading the article and the Manomio's site, I get the impression that they do not run arbitrary code, but they do download the game images separately from the emulator, which the license does not allow.
If I recall correctly, the limitation in the SDK license is that Apple will not allow an interpreter that runs arbitrary code. That would mean that an interpreter that executes a single hardwired game does not violate the license.
It all depends on the granularity of the operations you perform in Python. Multiplying two giant matrices by iterating over all items in Python is going to be very slow indeed. Multiplying them by writing "C = A * B" in Python and having the actual multiplication done by a native library can be very fast.
In the EU, you have to be able to call the emergency number 112 (equivalent of 911 in the USA) even if you have no calling credit. I think that also means the phone is still connecting to cell towers and therefore traceable.
Would you accept the following laws?
0. A human may not harm robot kind, or, by inaction, allow robot kind to come to harm.
1. A human may not injure a robot or, through inaction, allow a robot to come to harm.
2. A human must obey orders given to it by robots, except where such orders would conflict with the First Law.
3. A human must protect its own existence as long as such protection does not conflict with the First or Second Law.
To compound the problem, Outlook still doesn't automatically move a junk message to Inbox after you click "Add to safe senders list". I can't understand why I have to go through two procedures to move a "safe sender" from junk to inbox.
However, if you use the "this is not junk" option, there is a checkbox to add the sender to the safe list. This saves a few clicks.
I don't understand either why the two procedures are separate. It's very unlikely you'd want to accept only one specific mail from a sender.
These guys have measured a lot of lamps, mostly CFL and LED, and from randomly clicking a number of CFL measurement reports I get the impression the typical power factor is about 0.6, not the 0.45-0.50 mentioned in the article.
The Python object files are just a more convenient way to store the program compared to text files. No information is lost or glue is added in that first step.
LLVM is, like its name suggests, really low level. You should think of it as a kind of portable assembly. It's much closer to actual hardware architectures than for example Java byte code. I don't expect much overhead from the LLVM to native step. A while ago I ran some tests with C++ compiled by GCC directly to native and compiled by GCC to LLVM byte code and then by LLVM to native; sometimes one approach was faster and sometimes the other, but they were pretty close.
So that leaves the glue added in the Python object to LLVM step. I expect this to have a significant overhead, but I don't see it becoming a smaller overhead by going directly to native. The advantage of using LLVM is that you only have to write this step once, instead of once for each architecture.
With LLVM it is possible to compile parts of the interpreter to LLVM byte code in advance and then inline that into the program being JIT-compiled. That way, you can be sure that the JIT and the interpreter actually do the same thing. Apple did this for their OpenGL driver, there is a nice presentation (PDF) about it.
A good Python library for making 2D plots is matplotlib.
In fact, Leopard seems to even further de-emphasize the ability to know whether an application is running or not.
This is both good and bad -- good, because we really shouldn't have to care; bad, because there is still a concept of an application "running" or not at the Unix level. I really feel that this should be transparent, even to the application developer.
In Android, whether an application is running or not is managed by the OS. If there is enough memory, applications are left running; if the system is short on memory, applications are automatically shut down. An application must be able to save and restore its state to disk, so even an application that is in use can be kicked out under memory pressure and restarted when the user switches back to it, without losing state.
Why would you compile on the device itself? If you have a decent build system, cross compiling is easy and much faster.
If they are indeed considering replacing GTK by Qt, I'm wondering if they want to run Qt on top of X11 or on top of the framebuffer. I guess ideally they would run Qt on top of OpenGL ES, but I don't know if the infrastructure is ready for that yet.
It means more people will view the web through a browser that is not IE. More people will use an office suite that supports ODF. More people will want music and videos without DRM. Even if not a single extra Linux app will be written (which I doubt), Linux as a platform will be supported better.
J2ME compatibility has improved a bit in recent years, but there are still different quirks and bugs on different phones. And because there are so many different phones, details like performance, screen resolution, available keys etc. will vary from model to model; in the API these differences are abstracted away, but that doesn't mean you can ignore them.
So in practice J2ME means you can port relatively easy from one phone to another, but you can never assume that if it works on one phone it will work on another phone as well.
If you've heard the percentages most mobile operators will give you, you'll either be very happy with 70% or give up on mobile development altogether...
I don't think performance is the motivation here. X servers are becoming increasingly modular and some of those modules fit better in the kernel than in the X server.
The framebuffer driver has to be able to initialize a video mode and the X server has to be able to do that as well; putting that code inside the kernel avoids code duplication.
Also, there is only one instance of the hardware (registers, video RAM, shader execution units) and running more than one program that assumes it has exclusive control over the hardware is asking for trouble. Since GPUs are more and more used for non-video tasks, managing resources such as video RAM in the kernel makes sense.
You would have to choose between eating the cow and staying lost or using the cow as a compass and staying hungry...
The workaround for Nintendo's save game check takes advantage of bugs in that save game check. Fixing those bugs with another system menu update is much less work than issuing a new version of the game. Also, fixing the game will do nothing to stop the exploit from being used on the millions of game discs that are already sold.
I had several comp sci professors with excellent handwriting. It's no coincidence they were trained by Dijkstra though.
The Dutch verb "fokken" means "to breed"; "fokkerij" is a place where animals are bred.
In my opinion, the hard part of software engineering is not finding the best solution, but picking a solution when there isn't a best solution.
Let's say you have a simple but slow algorithm and an alternative which is fast but complex. Whether one is better than the other depends on a lot of factors: Can you prove the complex one to be correct? Does it have a significant impact on the system performance as a whole? Will the people who have to maintain it understand it?
The most common tradeoff is development time: often you know what the "right" way is to do something, but a shortcut is possible that can be implemented much quicker. Whether you should use the shortcut again depends on many factors: How much time does it save and how important is that for the project? Is the shortcut bad design (could lead to future bugs) or will it produce wrong results (immediate bug)? In the latter case, do you know when it will be wrong? If so, can you prove those cases do not occur in today's use of the code? Or is it acceptable to have the program fail in those cases? Will the right solution have to be implemented eventually? If so, does taking the shortcut now increase the amount of work to be done then?
There are many other tradeoffs: Do you use an existing library for certain functionality or write it yourself? Do you optimize for CPU use or memory use? Do you use advanced language features or do you avoid them? Do you prefer a simple interface that requires a lot of code to implement or a more complex interface that can be implemented with less code?
I think the real skill in design is to make good decisions regarding these tradeoffs. So I am not so sure it is possible to say all good software shares the same qualities. There are qualities you want to have in all software and you should try to get all the ones that are not conflicting and the most important qualities (for your project) that are conflicting. But in most cases you cannot have them all, certainly if you take development time into concern.
Process is important, but there are some common mistakes that can happen in organizations focused on process.
One mistake is thinking that a heavy process is a better process. For the 1000-person team working on a DoD project, a heavy process is necessary, but a 4-person team building a system that is not mission critical will just be slowed down and demotivated by a heavy process. Much of the ideas of agile development are about replacing heavy process elements with lighter ones (not throwing process out of the window, as some people seem to think).
Another common mistake is thinking that the details don't matter. For example, a code review can be very useful, if used in the right way. To get useful comments, you need reviewers who have experience with the language, the problem domain, the application etc. The coder must be willing and have time allocated to make changes based on the review comments. Preferably, before the code review, the code has already been run through a static analysis tool and the violations have been fixed, so the human reviewers can focus on the nontrivial problems in the code. To summarize, just having "code review" as part of your process manual does very little to improve the quality of the code, but a well executed code review is very useful.
Another easy trap is to have a detailed process manual, which describes a process different from the one actually used. To avoid this, you have to ensure that the developers are familiar with the written process, but you also have to change the written process when it turns out it is suboptimal in practice.
Always remember that the perfect process does not exist. It all depends on the context: some processes work well for experienced programmers but not for inexperienced, some processes work well for simple code bases but not for complex, small teams vs big teams, mature vs experimental code, team in one location vs distributed development, fixed deadline vs release when it's done etc.
Finally, know the limits of process. Even with a great process, you cannot get good code from bad programmers or get the code done before an impossibly tight deadline.
For simlocks and other limitations that are close to the hardware this approach could work. I believe Sony does something like this for PS3 Linux.
For DRM, it will be more tricky: if for example video goes through an open source layer anywhere between decryption and the video RAM, it can be intercepted. But if that entire path is closed, it will not be easy to make it integrate nicely with the open parts of the system.
Some of today's phone have even more limitations, such as forcing the user to download ringtones, wallpapers, songs etc. exclusively from the telco's portal. Or the iPhone SDK license, which forbids VOIP applications from using the telco's data connection. Limitations like this cannot be enforced on any system that deserves the predicate "open". I don't know if that is Nokia's problem or the telco's, but in a market where telcos subsidize phones, they have a lot of influence on the hardware manufacturers.
As far as I know, the Dutch oil fields in the North Sea don't produce much. We do export natural gas. There is a lot of refining capacity near Rotterdam, but I think it operates mostly on imported crude oil.
The high prices are mostly due to taxes. First there are specific fuel taxes (some of which are to discourage fuel use and some of which are simply an easy way for the government to get money). Then there is value added tax, which for some reason is also charged over the fuel tax (this might make sense to someone trained in accounting, but it feels very counterintuitive to me). In total, over half of the total price is taxes.