I do agree that if the kid doesn't show any interest in your gift you should pick something different next year. But just buying more of the same kind of toys they already have is also not going to contribute a lot to their fun. How do you know a kid won't like something if he/she has never played with it?
Geomag is a system that has balls and sticks, where the ends of the sticks contain the magnets. You can build all kinds of geometric shapes from them. It's popular with my friends (geeky 30-somethings) but my little nephew also likes it.
The magnets are pretty strong, but not as extreme as some other magnets. The box says age 4+.
Although I didn't hate it, I did lose interest in the Rubik's Cube for the same reason: as a kid I had no chance of solving it. Rubik's Magic (tiles with rings on them) on the other hand is solvable for a kid, probably closer to age 10 than to age 5 though. I don't know if they still sell those. It is rather fragile, so if the kid is wild or very clumsy it would not be the best gift.
I also liked a pentomino puzzle. With some persistence a kid has a decent chance of solving it. We also had a tangram set and a book with dozens of figures you could try and duplicate. I played with it for quite a while until it became too easy for me.
So when it comes to puzzles, it's important that it is neither too hard nor too easy. And it does take a slightly obsessive personality to enjoy puzzles: someone who decides it's too hard the first time he/she gets stuck and then stops trying is not going to enjoy it.
Branching without merging works fine in SVN. It is different from most other systems by using a directory structure for branches and tags, which means you have to mess with URLs when creating branches and tags. Still, no major problems here.
Branching with merging had the tracking issue you described: what was the last time that branch was merged into this branch? People who were really bothered by this probably migrated to different tools and didn't see it fixed in SVN.
Another set of problems still exists though because of the way SVN is designed: in SVN you merge trees instead of commits. A merge is done by taking a working directory with one branch, applying a series of commits from another branch to it and finally committing the result to the first branch. This means that only the result of the development from the other branch is merged, but the exact steps that were taken are lost.
Let's say that at some point you find a piece of code that doesn't seem to make sense. You'd probably like to know who wrote it and what the intended purpose was. If you look in the output of "svn annotate" or a web SVN view, you'll see the code was added when merging a series of commits from another branch. You must then run "svn annotate" again on the last revision that was included by the merge to figure out which actual commit introduced the code. If code flows between a lot of branches, this kind of archeology gets very tedious.
Sometimes you don't want to merge all changes from a branch. For example, you have recently released version 1.2 and are now working towards 1.3 in one branch, while you have another branch that is destined to become version 1.2.1, a bugfix release. If someone fixes a bug in the 1.3 branch, that commit must be merged into the 1.2.1 branch. You can do this in SVN, but you'll have to manually construct a commit message like "Merged r1234: <copy-pasted commit message from r1234>" or you'll lose the metadata. In for example git all this is a single command (cherry-pick).
Some people do new feature development in separate branches. Whether this is a good idea is another matter, but that's a question about how you organize your development rather than about version control, in my opinion. Let's just assume that you are in this situation either because you chose to or because it was unavoidable. Then you probably want to keep the feature branch in sync with the branch it was created from, both to avoid "big bang" integration problems when it is finished and because your development might depend on changes made in the original branch since the branch point. Because there is parallel development, merging changes from the original branch will introduce conflicts from time to time.
In SVN, you solve those conflicts before you commit the merged code. Because of this, the commit contains both the merged changes and the conflict resolution. If something went wrong in conflict resolution, it is later non-trivial to figure out what part of the commit was merged code and what part was conflict resolution.
All of these weak points of SVN can be addressed by adopting a way of working that suits the tool. However, it does lower your productivity if a significant part of your job is to review and merge changes from other people, which is probably why Linus hates SVN.
The kind of hashes used in password databases are a lot longer than 4 characters (~24 bits) though. The total number of hashes produced by 4-character passwords is so much less than the total number of possible hashes that the chances of a hash collision like you describe are negligible.
Since the salt and the hash are typically stored in the same place, someone running this kind of attack most likely knows the salt too. If it's possible to try all 6-character passwords in less than an hour, that will still be the case with a known salt attached to it. The only difference is that since a different salt is used for every user account, the brute force attack must be repeated for each user. If the attacker's goal is to gain entry to a specific account is does not make a difference, but if the goal is to gain access to any account it can make a huge difference.
There is a reason for that: after the EU said "either you lot pick a single charger plug or we'll do it for you", the phone manufacturers decided to standardize on micro USB. You'll find that most of the other differences between the US and EU cell phone markets are also due to pressure from the EU: cell operators are not nicer on this side of the pond, they are just kept on a tighter leash.
This article has some more info: They got 55 mph average speed, not top speed. The test run was on a highway, from Munich to Berlin. It doesn't say though what limited the average speed: the driver choosing not to go faster, the congestion on the road or speed limits. Since both the start and finish were inside a city, the first and last stretch will have been slow.
Actually, Caprica is about humans trying to achieve immortality by creating AI copies of themselves/others. So it's not robots becoming sentient but AIs who do not want to be confined to a virtual world.
At least that's where I think the story is heading. Since the pace is rather slow, I doubt we'll even see any non-centurion robots before the final episode.
Demand for oil and natural gas is still increasing faster than production, so even if you ignore the CO2 problem there is still the question of where we'll get our energy from. Unless you want to expand coal mining significantly, we have to switch to non-fossil fuel anyway.
If that were the case, increasing the alphabet by 1 would have no effect since (53-52)^7 = 1.
The number of different 7-character passwords using a 52-character alphabet is 52^7, while using a 60-character alphabet it is 60^7: an increase by a factor of 60^7/52^7 = (60/52)^7.
If you would add 7 random characters from the set !@#$%^&* to the existing 7-letter password, it would take 8^7 = 2^21 times the effort to crack it. However, if you switch from a 52-character set (mixed case letters) to a 60-character set, it only takes (60/52)^7 times as long, which is about 2.7 times.
Re:Cross-platform, but not cross-compiling
on
Autotools
·
· Score: 1
I indeed regularly run into configure scripts or Makefiles that think they can execute the binaries they have built on the build machine.
Just as bad are configure scripts that realize they cannot run a certain check in a cross compile and will use a hardcoded pessimistic result instead. In many cases the package then breaks during compilation because this alternative is completely untested since no actual system still in use requires it. In other cases it leads to useful features being turned off or unnecessary workarounds being enabled.
Another problem I often run into when compiling for embedded systems is not caused by autotools: a lot of packages pretend to be far more modular than they actually are. When aiming for a minimal footprint I like to disable all features that this particular system does not require. Deviating from the default configuration leads to compile errors on many packages. Sometimes because header files are included unconditionally even if the code using them is between #ifdefs. Sometimes because what is thought to be an optional dependency is actually not (or no longer) optional. And sometimes because package features have dependencies between themselves which are not (or incompletely) enforced by the build system.
Re:FOR ALL AUTOTOOLS "REPLACEMENTS"
on
Autotools
·
· Score: 1
shell+make are also a requirement on the build machine. "shell" is not even a single program, but a collection of utilities: at least sed is required and probably a lot more, looking at the contents of MSYS.
Why is one set of build requirements OK and another totally wrong? In my opinion it is important that the build requirements are few in number and are highly portable themselves. But that does not mean that anything except shell and Make is automatically disqualified.
One problem is that a configure script prints lots of things to stdout. The few relevant lines are drowned in pages of irrelevant ones. For example, I once built SDL_image and later a program that links to it and that program's attempts to load PNG files failed. It turns out that the configure script of SDL_image failed to link with libpng and said so, but I didn't catch that message because it was between hundreds of useless lines.
I didn't expect SDL_image to build without PNG support, since I explicitly told configure to include PNG loading (--enable-png). Still it decided to not include the feature since it thought libpng was unavailable. I think it's reasonable that if I request something explicitly and it cannot be delivered, the result should be an error and not omitting the requested feature. I don't know if this behavior is built into autoconf or it is just a practice associated with autoconf, but I have seen it happen on many different packages.
Another problem is that a lot of unnecessary checks are done. It seems half the packages out there check for a Fortran compiler while they don't contain a single line of Fortran code. Also features are checked that are present on every system produced in the last 10 years and in most cases compilation will fail anyway if the feature is not present since the result of the configure check is ignored by the actual code. The unnecessary checks both add to the irrelevant output and slow down the build.
Because configure is a shell script, it runs its checks sequentially. So even if you have a quad core system, only one core is being put to use. For compilation Make is used, which is given a dependency graph that allows it to run certain tasks in parallel. It would make sense to do the configuration step in Make as well, but that is not how autoconf works.
Because autotools generate files, if an error occurs for example while running the configure script, you have to manually trace it back to the configure.ac or to one of its include files. This is a generic problem when generating code, but in autotools it is made worse by the use of a macro expander instead of a compiler: many errors that could be caught by a compiler will be forwarded to the output by a macro expander. And in the case of automake, there are two layers of expansion: Makefile.am -> Makefile.in -> Makefile, increasing the effort of tracing problems back to their origin.
Note that these points are design flaws in the autotools, so it's not likely they can be addressed while staying compatible with thousands of existing packages using the current autotools. So I would like to see a replacement for autotools, but so far every other system I tried (Ant, SCons, qmake) works great for simple builds but becomes a struggle for more complex builds.
Re:No amount of documentation ...
on
Autotools
·
· Score: 1
The problem is that Scratchbox and its kin add yet another layer to an already overly complex system. It often works but when it fails, it's even harder to debug than cross compilation because you have to figure out whether the configure script drew the wrong conclusion about the target system or whether the pseudo-target did not mimic the actual target convincingly enough. In addition, the use of such workarounds means the actual cross compilation problems in packages do not get reported and fixed upstream.
Re:Cross-platform, but not cross-compiling
on
Autotools
·
· Score: 1
Note that the option to specify the target architecture is "--host". This makes sense for GCC and binutils and almost nowhere else, but every package has to deal with this naming. To make things worse, configure scripts created by recent versions of autoconf print a warning when you use "--host" in this way, but offer no alternative.
Whether or not a package using autotools will cross compile depends on how the configure.ac was written. Often it is copy-pasted together using fragments from other packages without really understanding what they do and in that case it is likely to break. If the configure.ac was written with cross compilation in mind or just does not attempt any tricky stuff, cross compilation will work fine.
Cross-compilation support is not magically added by autotools, the maintainer still has to consider the fact that the produced binaries might not be executable on the machine doing the build. The same is true of cross-platform support, by the way: autoconf does not provide it out of the box, it only provides a means of implementing it.
The government cannot take for granted that you just post some code or a media file, slap a CC license on it and you had every right to do that.
And why not? Unless there is evidence to the contrary, I think there is no problem believing such claims. Putting the burden of proof on the creator stifles creativity. Do I have to take a photo of me in front of my PC to prove that I wrote this comment?
Realtime games all use UDP. What they run over UDP is indeed different, but an ISP could just prioritize all UDP packets and gaming performance would improve without violating net neutrality.
I get 60 mbps down / 6 mbps up for 35 euros a month ($45) in an urban part of the Netherlands. No tax money is involved at all.
I think one key difference is that while I have only 1 option for cable, I have a dozen options for ADSL, meaning different companies to choose from. The government decided that since the copper network was built with public money, the privatized telecoms company maintaining it (KPN) would have to allow competing companies to rent the copper at a reasonable rate. This created a lot of competition on ADSL and drove down prices quickly. Today, several companies offer 20 mbps ADSL at 20 euros a month ($26).
Encouraging competition is more likely to result in affordable broadband than throwing money at near-monopolies. And it's cheaper too.
A study showed that in the Netherlands, one third of the electricity could be reliably generated from wind. There is a link to the Ph.D. thesis at the bottom of the article.
The Netherlands has a long coast line, which makes it a very good location for wind energy. I don't know if the US has enough good locations to place wind farms to produce one third of electricity, but if it does not, then the problem with fluctuations in how much power is supplied to the grid will only be easier to manage.
In other words, you indeed cannot get 100% of your electricity from wind, but this is no reason not to build lots of wind farms today since you're nowhere near the limit yet.
Even with the Other OS option, the PS3 is semi locked down hardware. Without it, it is fully locked down: you won't be able to run any software on it unless Sony approved it. In a situation like that, I don't think you can consider the firmware a separate product from the hardware.
This is very different from using a web site: people are not buying a PC from PayPal for the specific task of accessing the PayPal service.
Slashdot Mirror
My fun uncle played chess with me.
I do agree that if the kid doesn't show any interest in your gift you should pick something different next year. But just buying more of the same kind of toys they already have is also not going to contribute a lot to their fun. How do you know a kid won't like something if he/she has never played with it?
Geomag is a system that has balls and sticks, where the ends of the sticks contain the magnets. You can build all kinds of geometric shapes from them. It's popular with my friends (geeky 30-somethings) but my little nephew also likes it.
The magnets are pretty strong, but not as extreme as some other magnets. The box says age 4+.
Although I didn't hate it, I did lose interest in the Rubik's Cube for the same reason: as a kid I had no chance of solving it. Rubik's Magic (tiles with rings on them) on the other hand is solvable for a kid, probably closer to age 10 than to age 5 though. I don't know if they still sell those. It is rather fragile, so if the kid is wild or very clumsy it would not be the best gift.
I also liked a pentomino puzzle. With some persistence a kid has a decent chance of solving it. We also had a tangram set and a book with dozens of figures you could try and duplicate. I played with it for quite a while until it became too easy for me.
So when it comes to puzzles, it's important that it is neither too hard nor too easy. And it does take a slightly obsessive personality to enjoy puzzles: someone who decides it's too hard the first time he/she gets stuck and then stops trying is not going to enjoy it.
Branching without merging works fine in SVN. It is different from most other systems by using a directory structure for branches and tags, which means you have to mess with URLs when creating branches and tags. Still, no major problems here.
Branching with merging had the tracking issue you described: what was the last time that branch was merged into this branch? People who were really bothered by this probably migrated to different tools and didn't see it fixed in SVN.
Another set of problems still exists though because of the way SVN is designed: in SVN you merge trees instead of commits. A merge is done by taking a working directory with one branch, applying a series of commits from another branch to it and finally committing the result to the first branch. This means that only the result of the development from the other branch is merged, but the exact steps that were taken are lost.
Let's say that at some point you find a piece of code that doesn't seem to make sense. You'd probably like to know who wrote it and what the intended purpose was. If you look in the output of "svn annotate" or a web SVN view, you'll see the code was added when merging a series of commits from another branch. You must then run "svn annotate" again on the last revision that was included by the merge to figure out which actual commit introduced the code. If code flows between a lot of branches, this kind of archeology gets very tedious.
Sometimes you don't want to merge all changes from a branch. For example, you have recently released version 1.2 and are now working towards 1.3 in one branch, while you have another branch that is destined to become version 1.2.1, a bugfix release. If someone fixes a bug in the 1.3 branch, that commit must be merged into the 1.2.1 branch. You can do this in SVN, but you'll have to manually construct a commit message like "Merged r1234: <copy-pasted commit message from r1234>" or you'll lose the metadata. In for example git all this is a single command (cherry-pick).
Some people do new feature development in separate branches. Whether this is a good idea is another matter, but that's a question about how you organize your development rather than about version control, in my opinion. Let's just assume that you are in this situation either because you chose to or because it was unavoidable. Then you probably want to keep the feature branch in sync with the branch it was created from, both to avoid "big bang" integration problems when it is finished and because your development might depend on changes made in the original branch since the branch point. Because there is parallel development, merging changes from the original branch will introduce conflicts from time to time.
In SVN, you solve those conflicts before you commit the merged code. Because of this, the commit contains both the merged changes and the conflict resolution. If something went wrong in conflict resolution, it is later non-trivial to figure out what part of the commit was merged code and what part was conflict resolution.
All of these weak points of SVN can be addressed by adopting a way of working that suits the tool. However, it does lower your productivity if a significant part of your job is to review and merge changes from other people, which is probably why Linus hates SVN.
The kind of hashes used in password databases are a lot longer than 4 characters (~24 bits) though. The total number of hashes produced by 4-character passwords is so much less than the total number of possible hashes that the chances of a hash collision like you describe are negligible.
Since the salt and the hash are typically stored in the same place, someone running this kind of attack most likely knows the salt too. If it's possible to try all 6-character passwords in less than an hour, that will still be the case with a known salt attached to it. The only difference is that since a different salt is used for every user account, the brute force attack must be repeated for each user. If the attacker's goal is to gain entry to a specific account is does not make a difference, but if the goal is to gain access to any account it can make a huge difference.
There is a reason for that: after the EU said "either you lot pick a single charger plug or we'll do it for you", the phone manufacturers decided to standardize on micro USB. You'll find that most of the other differences between the US and EU cell phone markets are also due to pressure from the EU: cell operators are not nicer on this side of the pond, they are just kept on a tighter leash.
This article has some more info: They got 55 mph average speed, not top speed. The test run was on a highway, from Munich to Berlin. It doesn't say though what limited the average speed: the driver choosing not to go faster, the congestion on the road or speed limits. Since both the start and finish were inside a city, the first and last stretch will have been slow.
Actually, Caprica is about humans trying to achieve immortality by creating AI copies of themselves/others. So it's not robots becoming sentient but AIs who do not want to be confined to a virtual world.
At least that's where I think the story is heading. Since the pace is rather slow, I doubt we'll even see any non-centurion robots before the final episode.
Demand for oil and natural gas is still increasing faster than production, so even if you ignore the CO2 problem there is still the question of where we'll get our energy from. Unless you want to expand coal mining significantly, we have to switch to non-fossil fuel anyway.
openSUSE is switching as well. Not surprising, as they were shipping go-oo before.
If that were the case, increasing the alphabet by 1 would have no effect since (53-52)^7 = 1.
The number of different 7-character passwords using a 52-character alphabet is 52^7, while using a 60-character alphabet it is 60^7: an increase by a factor of 60^7/52^7 = (60/52)^7.
If you would add 7 random characters from the set !@#$%^&* to the existing 7-letter password, it would take 8^7 = 2^21 times the effort to crack it. However, if you switch from a 52-character set (mixed case letters) to a 60-character set, it only takes (60/52)^7 times as long, which is about 2.7 times.
I indeed regularly run into configure scripts or Makefiles that think they can execute the binaries they have built on the build machine.
Just as bad are configure scripts that realize they cannot run a certain check in a cross compile and will use a hardcoded pessimistic result instead. In many cases the package then breaks during compilation because this alternative is completely untested since no actual system still in use requires it. In other cases it leads to useful features being turned off or unnecessary workarounds being enabled.
Another problem I often run into when compiling for embedded systems is not caused by autotools: a lot of packages pretend to be far more modular than they actually are. When aiming for a minimal footprint I like to disable all features that this particular system does not require. Deviating from the default configuration leads to compile errors on many packages. Sometimes because header files are included unconditionally even if the code using them is between #ifdefs. Sometimes because what is thought to be an optional dependency is actually not (or no longer) optional. And sometimes because package features have dependencies between themselves which are not (or incompletely) enforced by the build system.
shell+make are also a requirement on the build machine. "shell" is not even a single program, but a collection of utilities: at least sed is required and probably a lot more, looking at the contents of MSYS.
Why is one set of build requirements OK and another totally wrong? In my opinion it is important that the build requirements are few in number and are highly portable themselves. But that does not mean that anything except shell and Make is automatically disqualified.
One problem is that a configure script prints lots of things to stdout. The few relevant lines are drowned in pages of irrelevant ones. For example, I once built SDL_image and later a program that links to it and that program's attempts to load PNG files failed. It turns out that the configure script of SDL_image failed to link with libpng and said so, but I didn't catch that message because it was between hundreds of useless lines.
I didn't expect SDL_image to build without PNG support, since I explicitly told configure to include PNG loading (--enable-png). Still it decided to not include the feature since it thought libpng was unavailable. I think it's reasonable that if I request something explicitly and it cannot be delivered, the result should be an error and not omitting the requested feature. I don't know if this behavior is built into autoconf or it is just a practice associated with autoconf, but I have seen it happen on many different packages.
Another problem is that a lot of unnecessary checks are done. It seems half the packages out there check for a Fortran compiler while they don't contain a single line of Fortran code. Also features are checked that are present on every system produced in the last 10 years and in most cases compilation will fail anyway if the feature is not present since the result of the configure check is ignored by the actual code. The unnecessary checks both add to the irrelevant output and slow down the build.
Because configure is a shell script, it runs its checks sequentially. So even if you have a quad core system, only one core is being put to use. For compilation Make is used, which is given a dependency graph that allows it to run certain tasks in parallel. It would make sense to do the configuration step in Make as well, but that is not how autoconf works.
Because autotools generate files, if an error occurs for example while running the configure script, you have to manually trace it back to the configure.ac or to one of its include files. This is a generic problem when generating code, but in autotools it is made worse by the use of a macro expander instead of a compiler: many errors that could be caught by a compiler will be forwarded to the output by a macro expander. And in the case of automake, there are two layers of expansion: Makefile.am -> Makefile.in -> Makefile, increasing the effort of tracing problems back to their origin.
Note that these points are design flaws in the autotools, so it's not likely they can be addressed while staying compatible with thousands of existing packages using the current autotools. So I would like to see a replacement for autotools, but so far every other system I tried (Ant, SCons, qmake) works great for simple builds but becomes a struggle for more complex builds.
The problem is that Scratchbox and its kin add yet another layer to an already overly complex system. It often works but when it fails, it's even harder to debug than cross compilation because you have to figure out whether the configure script drew the wrong conclusion about the target system or whether the pseudo-target did not mimic the actual target convincingly enough. In addition, the use of such workarounds means the actual cross compilation problems in packages do not get reported and fixed upstream.
Note that the option to specify the target architecture is "--host". This makes sense for GCC and binutils and almost nowhere else, but every package has to deal with this naming. To make things worse, configure scripts created by recent versions of autoconf print a warning when you use "--host" in this way, but offer no alternative.
Whether or not a package using autotools will cross compile depends on how the configure.ac was written. Often it is copy-pasted together using fragments from other packages without really understanding what they do and in that case it is likely to break. If the configure.ac was written with cross compilation in mind or just does not attempt any tricky stuff, cross compilation will work fine.
Cross-compilation support is not magically added by autotools, the maintainer still has to consider the fact that the produced binaries might not be executable on the machine doing the build. The same is true of cross-platform support, by the way: autoconf does not provide it out of the box, it only provides a means of implementing it.
Contrary to what the headline suggests, Intel is not buying all of Infineon: they are negotiating to buy the wireless division.
The government cannot take for granted that you just post some code or a media file, slap a CC license on it and you had every right to do that.
And why not? Unless there is evidence to the contrary, I think there is no problem believing such claims. Putting the burden of proof on the creator stifles creativity. Do I have to take a photo of me in front of my PC to prove that I wrote this comment?
Realtime games all use UDP. What they run over UDP is indeed different, but an ISP could just prioritize all UDP packets and gaming performance would improve without violating net neutrality.
I get 60 mbps down / 6 mbps up for 35 euros a month ($45) in an urban part of the Netherlands. No tax money is involved at all.
I think one key difference is that while I have only 1 option for cable, I have a dozen options for ADSL, meaning different companies to choose from. The government decided that since the copper network was built with public money, the privatized telecoms company maintaining it (KPN) would have to allow competing companies to rent the copper at a reasonable rate. This created a lot of competition on ADSL and drove down prices quickly. Today, several companies offer 20 mbps ADSL at 20 euros a month ($26).
Encouraging competition is more likely to result in affordable broadband than throwing money at near-monopolies. And it's cheaper too.
Any sufficiently advanced selfishness is indistinguishable from altruism?
If you return home alive though, sea air is a lot healthier than dust accumulating in your lungs.
A study showed that in the Netherlands, one third of the electricity could be reliably generated from wind. There is a link to the Ph.D. thesis at the bottom of the article.
The Netherlands has a long coast line, which makes it a very good location for wind energy. I don't know if the US has enough good locations to place wind farms to produce one third of electricity, but if it does not, then the problem with fluctuations in how much power is supplied to the grid will only be easier to manage.
In other words, you indeed cannot get 100% of your electricity from wind, but this is no reason not to build lots of wind farms today since you're nowhere near the limit yet.
Even with the Other OS option, the PS3 is semi locked down hardware. Without it, it is fully locked down: you won't be able to run any software on it unless Sony approved it. In a situation like that, I don't think you can consider the firmware a separate product from the hardware.
This is very different from using a web site: people are not buying a PC from PayPal for the specific task of accessing the PayPal service.