From what I've read cultists also seriously kludged their deployment resulting in a good bit of the gas ending up in the ventilation shafts rather than in the subway tunnels.
Though deployment of Sarin was far from perfect, the gas was released mostly inside of trains, so I am not sure why ventilation shafts playing any important role in that. In any case, despite a huge number of people who were exposed to the sarin, only very few of them died, because of impurity.
There was another attacked conducted by Aum Shinrikyo just 9 months prior to the attack on the Tokyo subway. In that attack sarin was released in one neighbourhood on unsuspected people late in the vening, which caused seven deaths (plus one more victim, who suffered severe brain damage, died 14 years later). So, this is a scale that a well orgganized terrorirst group can achieve.
The death toll in the Ghouta attacks in Syria clearly indicates that military-grade gas and delivery systems were used. I think there will be more evidences when the UN report will be released.
Heck some cults have done it in the past, and used them, I just can't for the life of me remember their name(s) at the moment.
I guess you mean Aum Shinrikyo. They released sarin in five coordinated attacks on the Tokyo subway at the peak of the rush hour. As result, 13 people died and about 50 people were severly injured. The death toll was not as high as one might expect because of impurity, which caused its quick degradation.
To kill over 1400 people over a large area of open air requires completely different expertise in chemical weaponry and much larger amount of the nerve gas.
I think most programmers know English well enough to comprehend technical messages in English. Some of them who used to having English UI may prefer English to their native language as it makes easier to search for the solution. Still some other programmers may strongly prefer to have the UI in their native language, as it makes the UI of the program more consistent with the rest of applications that they are running.
In fact, being able to use the UI in English is not same as being comfortable with English when it comes to reading. For example, many programmers in Russia find rather challenging to read any large documentation in English. For that reason alone, they switch to the UI in Russian as it makes all documentation to appear in Russian if it is available. Now if you switch between two or more programs using the UI in different languages, it can be slightly annoying, but usually it is not a dealbreaker.
So when you start a new tool, I do not think it makes sense to spend much time thinking about localization. If your tool gets really popular among developers then you will have more time to think about the issue. If it is an open source project, you are likely to be offered a helping hand by someone who has more experience in localization than you.
Google Translate usually works better translating from Russian into English than in the opposite direction, because English has more ambiguity. People use common sense when they read, so they do not notice any problem in most cases, but any automatic translation tool has neither common sense nor understanding of the context in which the phrase was used.
There are many reasons why malware is so rampant in poor countries.
1. If majority of population cannot afford buying software legally, even those who can afford do not buy it, because they see no reason to pay relatively huge money for something that almost everyone gets for free. Piracy creates increases the risk not only because some pirated software may include malware, but automatic update is often disabled to prevent the pirated version being detected by the vendor.
2. Old computers often mean that they cannot run new software, which means a lot of software in use is no longer supported by the vendor, and there is no security updates for it (even if it was bought legally).
3. Sharing a PC among many people is very common. This dramatically increases a chance of some virus being introduced, because it feels like no one responsible. If something bad happened, anyone can claim it is someone else's fault. Thus anyone feels free to do whatever damn thing comes to his or her mind.
4. There is no police to fight cyber crime, so cyber criminals can do whatever they want with virtual immunity. In fact, common attitude is to blame victims (they should not have installed some pirated software, they should not have visited such sites, etc).
5. Most people do not use their computer to store or transmit any private sensible information (such as credit card numbers), so as long as malware does not interfere with their work, they are reluctant to take any action to remove it. Usually they do not have any antivirus software except perhaps a demo, which can only scan but does not remove malware. So they have to pay some money a local "guru" to clean up their computer, but only to find the computer infected again in less than a week later (probably, due to some unpatched software, infected an USB stick, or some other reason).
6. Very low computer literacy means that people have less understanding about how computers work and how to use them safely. So they may download and install programs that make some completely unrealistic promises (such as making your computer or Internet connection twice faster). In general, they have no clue about the source from which they download software.
Therefore, an intruder or "hacker" can only learn that the tag serial number is, for example, #69872331, but that does not provide any useful information.
Yes, it is just a serial number, like SSN, and we are going to use it for authentication. What can possible go wrong?
Productivity in the US has steadily increased over the past 40 years, but real wages have been stagnant.
This is not exactly correct, because both median and average wages grew over that period, it is just that wages failed to grow nearly as fast as productivity.
Accordingly statistics, productivity grew more than 80% between 1973 and 2011, while the median hourly compensation (adjusted to inflation) grew 10.7%. The only way to argue that wages were stagnant over that period is too look only at the median male wage, which grew 0.1% (while the female median wage, which grew 33.2% over that period).
Of course, this is in sharp contrast with what it was before 1973 when productivity and hourly compensation grew at about the same rate. So what did it happen in 1973? The only plausible explanation that I see is that the initial impetus for wage stagnation came from the 1973 oil crisis. US economy was vastly energy inefficient and suffered far more than many other countries. For example, Japan that did not have their own natural resources, but it recovered from the oil crisis much faster and overall Japan economy experienced fast grow in the 1970s (despite two oil crises in 1973 and 1979).
In the 1980s, the US found yourself in competition with fast growing Asian economy. Initially, it was mostly Japan, but later with other Asian countries. To state competitive against Japan, it was crucial for the US to keep its wages low. Many Reagan's policies that were enacted at that time intended made US labor force really cheap, which helped to attract investments and make the US goods more competitive. The downside of these policies was a larger US debt and a growing gap between the rich and poor.
The 1990s were defined by collapsed the Soviet Union, which opened many new markets to large international corporations. While many American companies clearly benefited from new markets, it had mostly negative impact on American wages. All former Soviet countries had very low capital per worker ratio, therefore competition for investments depressed wages in most Western countries. German reunification is a good example of that, because it became a single country without any economic barriers. So between 1990 and 1995, wages in Eastern Germany grew more than twice but still remain about 74% of wages in West Germany, where wages were stagnant over that period. So you could see Eastern workers were unhappy about being paid less for the same job even after 5 years of reunification, while Western workers are unhappy about stagnation in their wages despite raise in productivity.
Finally, in the 2000s, we can see the largest speculation bubble in US history since the Great Depression. The US experienced significant reduction in manufacturing jobs over decades (some of them were outsourced and others were lost to automation) while new jobs (in consumer electronics, etc) were mostly created in Asia. At the same time, low taxes on capital gains and some other incentives together with perceived stability of US economy made it very attractive for foreign investors. This created perfect conditions for a speculative bubble. When it burst, it obliterated gains that most Americans had over last two decades.
While closing loopholes and more sensible rate on capital gains is important to promote social stability, this cannot solve the underlying problem. Currently, the US has an unsustainable rate of consumption. It is estimated that the Earth can support approximately 1.5 billion people who consume as much as the average American, and there is close to 7 billion people on the planet today. In the global market, differences in wages between the US and other countries will eventually level out. So those people will have money to buy their fare share of natural resources. Therefore, prices on natural resources are likely to grow making many everyday products more costly, which will offset any future increases in the medium wage in the US. In other words, the medium wage adjusted to inflation is unlikely to grow significantly until overconsumption of natural resources is fixed somehow.
First of all, the bug has never been bisected, and the whole story that hit Slashdot and some other news sites was based solely on Ted's speculation, which was never confirmed. In fact, at the of the same day, Ted admitted that his hypothesis was wrong.
After a few days of investigation, the problem was traced to an experimental mounting option, which is not turned on by default and was intended for developers only. Accidentally, this option was not marked as "experimental", so it is available to users.
https://lkml.org/lkml/2012/10/26/570
If you don't budget for upgrades, you'd better either plan to be gone by then or be fortunate enough to be able to toss the whole thing.
You seem do not realize that in many industries the traditional upgrade cycle for expensive equipment is 15-25 years! So they did plan for upgrade, but that time may be 10 or more years away from now.
So if anyone has the Wal-Mart Shopper mentality here, it is those who think that the typical PC update cycle is suitable for everyone. It is not about updating PC, but updating the whole infrastructure (which relies on a lot of crappy third-party software) and re-training the whole personal to use it. It is completely unrealistic to do that every 3-5 years as you do in the IT-world...
If I tell you that you need to buy a new PC and replace all software (which you got used to) every 6 months, how would you like this idea?
There is no reason to think that it is part of hacker culture, but women always face a lot of challenges when they try to enter to any male dominated group.
First of all, among a large enough group of men, there will be at least one asshole who acts very disrespectfully to women. Let's suppose that on average there is one such an asshole per 100 men, and you have 100 attendees on some conference. If there is only one woman among them then probability is very high that she is going to experience sexual harassment (roughly speaking 99%). On the other hand, if you have 50 men and 50 women then probability for any woman to experience sexual harassment is about 1%. (The above numbers are just for demonstration of the point and not based on any actual statistics). Not surprisingly, most women feel much more comfortable in more gender mixed groups.
Aside the issue of sexual harassment, some women are put aback by high stress on competitiveness instead of co-operation in hacker culture. This often makes them feel uncomfortable or unwelcome. However, this is not because men dislike women, but a typical male-bonding ritual includes a lot of arguing even in those cases when both men may be mostly agreed on the issue. I want to underscore that this men's behavior is not specific to hacker culture, in fact, it is even more profoundly expressed in pubs and other places where young men socialize among themselves. When women socialize among themselves (without men), they tend to focus more on co-operation around some shared interests, as well as sharing their emotions about related events. Usually gender mixed groups tend to take the middle ground, so both extremes are eliminated.
The bottom line is that any group that consists mostly of men (for whatever reason) acts quite differently than more gender mixed groups, and that presents a lot of challenges to women who want to be part of them. This has nothing to do with hacker culture.
I would imagine google is running tens of thousands of identical servers running the same server daemon, so why would Virtualization make sense and save energy there?
Who said that Google uses virtualization to run identical servers?
Just running "git log --grep=virtualization" on the Linux kernel, you can see that Google does not contributed much to virtualization in the Linux lernel, in sharp contrast to other part of the kernel such as ext4.
By definition, explicit renames will work 100% of the time
No merge algorithm works correctly all time, and any merge relies on certain heuristics to find where to make changes inside of files. Just tracking some abstract file-ids does not mean that the merge will find the right place or even the right file for those changes. It is much better to look at the _context_ to find the correct place when changes are applied.
That means you need to manually compare two files
If you do that it only shows that you do not know how to use Git. There is a much better way to merge than that.
But can Git actually track that?
As with file rename, Git does not track those things, but it can easily _find_ them. Git log's pickaxe allows easy to find where some function (or just some line) were introduced.
The point of a VCS is to track the history of development.
but the question is what history is worth saving. Should every version of each file to be saved in history every time when you hit "Save" in your editor? Or maybe even each your move during editing those files? Obviously, those intermediate steps are not interesting!
So, the question is what is the right moment when you say that it worths saving in history. In Bazaar (and many other VCS), it is the time when a new commit is created, which means that you cannot commit your changes unless you have passed all reviews, or you end up with a _lot_ intermediate changes that just pollute history and make it difficult to understand bisect later. Storying your patches outside of your VCS and sharing them by other means than the normal "fetch" is additional burden to all developers, and it may cause mistakes and confusion.
Git gives you freedom to choose when you want to make your history immutable. Typically, a patch series becomes immutable when it is merged to the 'next' branch. But as long as your patches are going through reviews, you can modify your patches based on feedback that you received.
So the goal is _not_ to make the history perfect, but to avoid the development history being fill with crap, which obliterates actual changes through a lot of small errors in commits and fix-ups to them. Also, many developers do not write good commit messages initially, because they consider somethings as self-obvious at the moment when they look at the problem. However, when someone else is going through those changes a few years later, it makes difficult to understand what are motivations behind of those changes or why it was implemented in this way and not some other. Then you may want to add additional information to those commits, like who have reviewed and tested those changes.
Now if you do not really care about history, like you never go back to study what was changed and why then those fix-ups and other crappy commits are not going to hurt you much. But if you try to bisect more than a year worth history of some active project to find the cause of some tricky bug, you will see that having cleaner history makes huge difference.
I have argued for a long time, done experiments, collected data on both real and trivial repositories, and I have convinced hardcore Git fans that explicit is the way to go.
I don't know anything about your experiments, but it would be interesting to see that on real-life repositories, such as the Linux kernel or Git itself. I doubt that it will work any better than what Git does based on heuristic, but it would be interesting to see.
As to your artificial example, it is not convincing, because it is not what you normally have during development, and the conflict is easy to resolve anyway.
We had the freedom to rename or change the files as much as we wanted, and we did so.
Let's suppose, I move a few functions to another file. Now how is your explicit rename/copy tracking is going to help here?
In my experience, moving code around refactoring is much more common than renaming or copying files. With Git, it is easy to find where some function came from. Somehow I have not found similar functionality in Bazaar, but maybe I did not try hard enough to find it.
I don't want my tool to fail just because I am not following best practices.
Git does not fail, it is just that it works better in some cases than in others. Best practices describe how to take most advantage of it. It does not mean that you cannot do in other ways.
but the pieces of the file that changed in both branches get a >>> <<<< conflict marker).
In simple cases, those markers are really useful, but relying on them in complex merges leads to mistakes, because they do not mark all places that has to be changed (regardless whether rename/copy is involved or not). So, much better way to handle complex merges is to use "gitk --merge", where you can see what was changed and why.
Now, for trivial changes, rename heuristic in Git works pretty well. In cases, where you have substantial changes to some files (=>50%), I primary rely on "gitk --merge" anyway, so those markers are not so important. Not to mentioned that in many cases, those markers can be around the wrong lines.
Personally, I don't have much experience with explicit rename tracking (except SVN but it does not do branches well, so it does not count), but accordingly to Linus, explicit rename in BitKeeper caused more confusion than being helpful.
It is entirely possible to apply the same workflow in both tools.
I have not said that is impossible, but it may not be as easy. And this is the reason why people tend to use one tool in one way, and the other in another.
If we speak about Bazaar, a typical approach is to create a feature branch, to do your work on it. When everything is fine and tested to merge it to "trunk". The problem is that intermediate steps may contain mistakes.
One of key features of Git is interactive rebase. It means that you can amend any commit later. You may want to do that due to some mistakes that you did not notice initially, or based on feedback from other developers, or result of testing the same code on another platform. In my experience, it is rare that the initial series of patches is perfect, especially if we speak about not very experience developers or those who work on the code that they do not know well.
Sure, you can use some patch management system instead, but if it is not integrated with your VCS, it is a real pain. But even if it is integrated, it is more complex than you really want in most cases. Obviously, if you maintain some patches on the top of another code, then you need a patch management system. But if you only want to be able to correct your initial series of patches, interactive rebase is much easier to use.
that you can commit part of a changeset without having tested that it compiles
You can always do that with any VCS. The index just gi
A question about explicit rename was raised so many times on the Git ML, and Linus and then many other developers answered it extensively, so I suggest you look-up their explnations.
the old mantra "explicit is better than implicit" applies here
A mantra is not a logical argument, and while it may be true for many cases, it tends to be oversimplification of reality.
When you say, explicit is better than implicit, does it mean than the C language is better than Python, because allocation memory in C is _explicit_? And then following this line of reasoning, one may conclude than the Assembler language is even better than C, because register allocation is explicit.
The principle explicit is better than implicit only applies to things that matters, while those that do not matter are better to be implicit, so they won't be distraction.
Now, if we speak about renames, what it matters is the end state and how source code was moved, so file content is far more important than some abstract file-id. In other words, it does not matter whether you rename some file or moved most content to a new file.
If you are not convinced, then take a look how the "diff" command works. It does not show how lines were actually, moved, but it shows the difference between two states. And, yes, "diff" uses some heuristics to detect this difference, so it does not always produce the perfect result.
The following is all that is required to trigger a complete merge failure on Git
So what? It seems you believe that if something merged automatically then it is good otherwise it is not.
In practice, failure of automatic merge can be a _good_ thing, because it can make a developer to think and resolve the conflict correctly. Definitely, we do not want to bother developers with trivial failures, but when a file is mostly re-written and then it is renamed, then there are some reasons for it. So, a good VCS should be to make obvious the cause of the conflict, and provide means to resolve it easily.
Based on my experience, in practice, the situation that you describe will lead to the wrong merge result anyway. I mean even with less extensive changes to one file when the merge detected automatically and there was a trivial change on the other branch, the end result was more often wrong than right. Of course, if you rename files without any good reason, then you may have more often situations where the automatic merge will be more often right, but I always rename for _some_ reason. So, significant re-write of some file and then its rename did not happen for no reason, and in most cases, no automatic merge can handle that merge correctly. And in trivial cases, it is not a problem to resolve conflict manually.
The merge problem is not new, it is extensively studied in CS. There are some very "smart" algorithms that reduce the number of automatic merge failures. Unfortunately, except some specialized cases, all of them increased the number of correct merges insignificantly and only in trivial cases, which any developer with proper tools will handle without any problem, but the downside is the increase of wrong merge results in far more complex cases. So, this trade-off is simple wrong, and "stupid" 3-way is usually the best approach for general case.
If you are interested in the subject, you should read the discussion that took place between Bram Cohen and Linus Torvalds, which took in May 2005. (Probably, rename also discussed there or maybe it was another thread around that time.)
It is a fully distributed version control system (you might say with Subversion-like centralised support tacked on as an optional feature).
I have never claimed that Bazaar is not truly distributed, but it feels to me like a DVCS that is optimized for a centralized workflow. You certainly can use in other ways too, but it is not so s
the only thing it has going for it is a larger community
Not just a larger user active community, but also larger and more active developer community. It means that even you can find some similar features in Hg or Bzr, they are available as additional plugins, which are less tested and do not get the same support as core features.
I've argued to wit's end that Bazaar is superior to Git in a multitude of ways
Well, same things can be advantages in one but disadvantages in another, because it depends on your workflow.
If you try to stick to SVN-like workflow, Bazaar probably works better, but if you try to use a workflow that more similar to what Linux kernel developers use, you will see that Git is _much_ better -- it is more intuitive and all defaults are right for that case.
Then some other features like "explicit moves/renames" may sound great for novices, but it does not work well in truly distributed workflow. If every branch gets merged to "trunk" of the central repo, it is not a problem. However, this is not a distributed workflow (just being able to work offline does not make it distributed).
When you try to work in really distributed fashion, things can be merged in different directions before ending up in the upstream, the history graph is far more complex and your explicit tracking does not work well. Linus had this experience with BitKeeper, which had explicit tracking for moves/renames, and one lesson that he learned from it was that explicit tracking introduces more problems than it solves. So, by design, Git does not explicitly track rename/copy but uses heuristic instead.
Git lacks commit metadata
This is not true. By definition metadata is "data about data", and Git stores its own metadata in the commit object, but it does not store foreign metadata. There is two reasons for that. First, Git may not know how to deal with them during some operations (e.g. git-rebase). Second, Git does not hide anything from the user. If you want extra information, you can store it in the commit message, in additional file, or as git-notes. However, if this information does not make sense to the user and only necessary for inteeroperability, you should store it separately as git-svn does.
it is impossible to meaningfully use any other revision control system in conjunction with Git
What about git-svn or hg-git?
Yet all I ever hear is "Git is better than all the other revision control systems because [generic reasons why DVCSes are better than centralised ones]."
IMHO, Bazaar got all its defaults for _centralized_ (SVN-like) workflow, but with ability to work offline on feature branches.
However if you try to work with many repositories and with many small features branches, which oftentimes take months before they are merged to the main upstream branch (during which they go through a few intermediate merges and internal testing by other developers), you will see that Git handles this case much better. Most people who complain that Git is difficult or not intuitive just have not grasped _distributed_ workflow. Once you have understood distributed workflow, everything in Git becomes very natural. Mercurial is close to Git in this respect, but Bazaar appears to be counter-intuitive.
Git command line is far more intuitive and easy to use than SVN. Trying to use SVN from the command-line is like to use COMMAND.COM -- no completion for names commands or branches (in fact, there is no branches, you got to type f*cking long URLs and of course there is no completion for them either), and there are many other annoying things with SVN. Every time when I tried to write a simple convenience scripts to automatize some routine, it lead to utter frustration how ugly and inconvenient SVN command line is...
When I tried Git first time, my experience where the same as moving moving from the ugly and insanely irregular command.com prompt to bash. You can do almost anything from the command line with Git. In fact, the initial version of Git was mostly shell scripts on top a few C written programs. And Git is nicely integrated with bash, so you have completion not only command names but also branches, options, etc...
Their error, as stated in the linked abstract, is less than 0.3%.
It usually means that with 70% probability the value lies with this interval, but if you want to have 90% probability, it is going to be thrice more. So it could be said that the chance that this difference is significant is about 90%. However, it could be some other errors that were not taken into account properly. I would say that without independent confirmation is too early to say that it is an established fact and not a random fluke.
The answer is politics, politics, and politics...
The subject of a modern VCS was brought by Eric Raymond, and he clearly favored to Mercurial. It seems most developers on the Emacs ML who were familiar with any DVCS were more inclined to choosing Git. I don't remember if anyone even mentioned Bazaar, before RMS announced that Emacs would migrate to Bazaar. As to justification for this decision, he said that Bazaar agreed to become a Gnu Project, and Gnu Projects should support one another.
Slashdot Mirror
https://gcc.gnu.org/bugzilla/s...
GCC 4.5.0 was released in April 2010, so I wonder how many kernel oops it has caused.
From what I've read cultists also seriously kludged their deployment resulting in a good bit of the gas ending up in the ventilation shafts rather than in the subway tunnels.
Though deployment of Sarin was far from perfect, the gas was released mostly inside of trains, so I am not sure why ventilation shafts playing any important role in that. In any case, despite a huge number of people who were exposed to the sarin, only very few of them died, because of impurity.
There was another attacked conducted by Aum Shinrikyo just 9 months prior to the attack on the Tokyo subway. In that attack sarin was released in one neighbourhood on unsuspected people late in the vening, which caused seven deaths (plus one more victim, who suffered severe brain damage, died 14 years later). So, this is a scale that a well orgganized terrorirst group can achieve.
The death toll in the Ghouta attacks in Syria clearly indicates that military-grade gas and delivery systems were used. I think there will be more evidences when the UN report will be released.
Heck some cults have done it in the past, and used them, I just can't for the life of me remember their name(s) at the moment.
I guess you mean Aum Shinrikyo. They released sarin in five coordinated attacks on the Tokyo subway at the peak of the rush hour. As result, 13 people died and about 50 people were severly injured. The death toll was not as high as one might expect because of impurity, which caused its quick degradation.
To kill over 1400 people over a large area of open air requires completely different expertise in chemical weaponry and much larger amount of the nerve gas.
I think most programmers know English well enough to comprehend technical messages in English. Some of them who used to having English UI may prefer English to their native language as it makes easier to search for the solution. Still some other programmers may strongly prefer to have the UI in their native language, as it makes the UI of the program more consistent with the rest of applications that they are running.
In fact, being able to use the UI in English is not same as being comfortable with English when it comes to reading. For example, many programmers in Russia find rather challenging to read any large documentation in English. For that reason alone, they switch to the UI in Russian as it makes all documentation to appear in Russian if it is available. Now if you switch between two or more programs using the UI in different languages, it can be slightly annoying, but usually it is not a dealbreaker.
So when you start a new tool, I do not think it makes sense to spend much time thinking about localization. If your tool gets really popular among developers then you will have more time to think about the issue. If it is an open source project, you are likely to be offered a helping hand by someone who has more experience in localization than you.
Google Translate usually works better translating from Russian into English than in the opposite direction, because English has more ambiguity. People use common sense when they read, so they do not notice any problem in most cases, but any automatic translation tool has neither common sense nor understanding of the context in which the phrase was used.
There are many reasons why malware is so rampant in poor countries.
1. If majority of population cannot afford buying software legally, even those who can afford do not buy it, because they see no reason to pay relatively huge money for something that almost everyone gets for free. Piracy creates increases the risk not only because some pirated software may include malware, but automatic update is often disabled to prevent the pirated version being detected by the vendor.
2. Old computers often mean that they cannot run new software, which means a lot of software in use is no longer supported by the vendor, and there is no security updates for it (even if it was bought legally).
3. Sharing a PC among many people is very common. This dramatically increases a chance of some virus being introduced, because it feels like no one responsible. If something bad happened, anyone can claim it is someone else's fault. Thus anyone feels free to do whatever damn thing comes to his or her mind.
4. There is no police to fight cyber crime, so cyber criminals can do whatever they want with virtual immunity. In fact, common attitude is to blame victims (they should not have installed some pirated software, they should not have visited such sites, etc).
5. Most people do not use their computer to store or transmit any private sensible information (such as credit card numbers), so as long as malware does not interfere with their work, they are reluctant to take any action to remove it. Usually they do not have any antivirus software except perhaps a demo, which can only scan but does not remove malware. So they have to pay some money a local "guru" to clean up their computer, but only to find the computer infected again in less than a week later (probably, due to some unpatched software, infected an USB stick, or some other reason).
6. Very low computer literacy means that people have less understanding about how computers work and how to use them safely. So they may download and install programs that make some completely unrealistic promises (such as making your computer or Internet connection twice faster). In general, they have no clue about the source from which they download software.
Therefore, an intruder or "hacker" can only learn that the tag serial number is, for example, #69872331, but that does not provide any useful information.
Yes, it is just a serial number, like SSN, and we are going to use it for authentication. What can possible go wrong?
Productivity in the US has steadily increased over the past 40 years, but real wages have been stagnant.
This is not exactly correct, because both median and average wages grew over that period, it is just that wages failed to grow nearly as fast as productivity.
Accordingly statistics, productivity grew more than 80% between 1973 and 2011, while the median hourly compensation (adjusted to inflation) grew 10.7%. The only way to argue that wages were stagnant over that period is too look only at the median male wage, which grew 0.1% (while the female median wage, which grew 33.2% over that period).
Of course, this is in sharp contrast with what it was before 1973 when productivity and hourly compensation grew at about the same rate. So what did it happen in 1973? The only plausible explanation that I see is that the initial impetus for wage stagnation came from the 1973 oil crisis. US economy was vastly energy inefficient and suffered far more than many other countries. For example, Japan that did not have their own natural resources, but it recovered from the oil crisis much faster and overall Japan economy experienced fast grow in the 1970s (despite two oil crises in 1973 and 1979).
In the 1980s, the US found yourself in competition with fast growing Asian economy. Initially, it was mostly Japan, but later with other Asian countries. To state competitive against Japan, it was crucial for the US to keep its wages low. Many Reagan's policies that were enacted at that time intended made US labor force really cheap, which helped to attract investments and make the US goods more competitive. The downside of these policies was a larger US debt and a growing gap between the rich and poor.
The 1990s were defined by collapsed the Soviet Union, which opened many new markets to large international corporations. While many American companies clearly benefited from new markets, it had mostly negative impact on American wages. All former Soviet countries had very low capital per worker ratio, therefore competition for investments depressed wages in most Western countries. German reunification is a good example of that, because it became a single country without any economic barriers. So between 1990 and 1995, wages in Eastern Germany grew more than twice but still remain about 74% of wages in West Germany, where wages were stagnant over that period. So you could see Eastern workers were unhappy about being paid less for the same job even after 5 years of reunification, while Western workers are unhappy about stagnation in their wages despite raise in productivity.
Finally, in the 2000s, we can see the largest speculation bubble in US history since the Great Depression. The US experienced significant reduction in manufacturing jobs over decades (some of them were outsourced and others were lost to automation) while new jobs (in consumer electronics, etc) were mostly created in Asia. At the same time, low taxes on capital gains and some other incentives together with perceived stability of US economy made it very attractive for foreign investors. This created perfect conditions for a speculative bubble. When it burst, it obliterated gains that most Americans had over last two decades.
While closing loopholes and more sensible rate on capital gains is important to promote social stability, this cannot solve the underlying problem. Currently, the US has an unsustainable rate of consumption. It is estimated that the Earth can support approximately 1.5 billion people who consume as much as the average American, and there is close to 7 billion people on the planet today. In the global market, differences in wages between the US and other countries will eventually level out. So those people will have money to buy their fare share of natural resources. Therefore, prices on natural resources are likely to grow making many everyday products more costly, which will offset any future increases in the medium wage in the US. In other words, the medium wage adjusted to inflation is unlikely to grow significantly until overconsumption of natural resources is fixed somehow.
I guess it has come time to tell the truth.
First of all, the bug has never been bisected, and the whole story that hit Slashdot and some other news sites was based solely on Ted's speculation, which was never confirmed. In fact, at the of the same day, Ted admitted that his hypothesis was wrong.
After a few days of investigation, the problem was traced to an experimental mounting option, which is not turned on by default and was intended for developers only. Accidentally, this option was not marked as "experimental", so it is available to users. https://lkml.org/lkml/2012/10/26/570
Windows 8 is very easy to use unless you try to do something that 3 year old would never do... you know, like trying to get your work done...
If you don't budget for upgrades, you'd better either plan to be gone by then or be fortunate enough to be able to toss the whole thing.
You seem do not realize that in many industries the traditional upgrade cycle for expensive equipment is 15-25 years! So they did plan for upgrade, but that time may be 10 or more years away from now.
So if anyone has the Wal-Mart Shopper mentality here, it is those who think that the typical PC update cycle is suitable for everyone. It is not about updating PC, but updating the whole infrastructure (which relies on a lot of crappy third-party software) and re-training the whole personal to use it. It is completely unrealistic to do that every 3-5 years as you do in the IT-world...
If I tell you that you need to buy a new PC and replace all software (which you got used to) every 6 months, how would you like this idea?
There is no reason to think that it is part of hacker culture, but women always face a lot of challenges when they try to enter to any male dominated group.
First of all, among a large enough group of men, there will be at least one asshole who acts very disrespectfully to women. Let's suppose that on average there is one such an asshole per 100 men, and you have 100 attendees on some conference. If there is only one woman among them then probability is very high that she is going to experience sexual harassment (roughly speaking 99%). On the other hand, if you have 50 men and 50 women then probability for any woman to experience sexual harassment is about 1%. (The above numbers are just for demonstration of the point and not based on any actual statistics). Not surprisingly, most women feel much more comfortable in more gender mixed groups.
Aside the issue of sexual harassment, some women are put aback by high stress on competitiveness instead of co-operation in hacker culture. This often makes them feel uncomfortable or unwelcome. However, this is not because men dislike women, but a typical male-bonding ritual includes a lot of arguing even in those cases when both men may be mostly agreed on the issue. I want to underscore that this men's behavior is not specific to hacker culture, in fact, it is even more profoundly expressed in pubs and other places where young men socialize among themselves. When women socialize among themselves (without men), they tend to focus more on co-operation around some shared interests, as well as sharing their emotions about related events. Usually gender mixed groups tend to take the middle ground, so both extremes are eliminated.
The bottom line is that any group that consists mostly of men (for whatever reason) acts quite differently than more gender mixed groups, and that presents a lot of challenges to women who want to be part of them. This has nothing to do with hacker culture.
I would imagine google is running tens of thousands of identical servers running the same server daemon, so why would Virtualization make sense and save energy there?
Who said that Google uses virtualization to run identical servers?
Just running "git log --grep=virtualization" on the Linux kernel, you can see that Google does not contributed much to virtualization in the Linux lernel, in sharp contrast to other part of the kernel such as ext4.
By definition, explicit renames will work 100% of the time
No merge algorithm works correctly all time, and any merge relies on certain heuristics to find where to make changes inside of files. Just tracking some abstract file-ids does not mean that the merge will find the right place or even the right file for those changes. It is much better to look at the _context_ to find the correct place when changes are applied.
That means you need to manually compare two files
If you do that it only shows that you do not know how to use Git. There is a much better way to merge than that.
But can Git actually track that?
As with file rename, Git does not track those things, but it can easily _find_ them. Git log's pickaxe allows easy to find where some function (or just some line) were introduced.
The point of a VCS is to track the history of development.
but the question is what history is worth saving. Should every version of each file to be saved in history every time when you hit "Save" in your editor? Or maybe even each your move during editing those files? Obviously, those intermediate steps are not interesting!
So, the question is what is the right moment when you say that it worths saving in history. In Bazaar (and many other VCS), it is the time when a new commit is created, which means that you cannot commit your changes unless you have passed all reviews, or you end up with a _lot_ intermediate changes that just pollute history and make it difficult to understand bisect later. Storying your patches outside of your VCS and sharing them by other means than the normal "fetch" is additional burden to all developers, and it may cause mistakes and confusion.
Git gives you freedom to choose when you want to make your history immutable. Typically, a patch series becomes immutable when it is merged to the 'next' branch. But as long as your patches are going through reviews, you can modify your patches based on feedback that you received.
So the goal is _not_ to make the history perfect, but to avoid the development history being fill with crap, which obliterates actual changes through a lot of small errors in commits and fix-ups to them. Also, many developers do not write good commit messages initially, because they consider somethings as self-obvious at the moment when they look at the problem. However, when someone else is going through those changes a few years later, it makes difficult to understand what are motivations behind of those changes or why it was implemented in this way and not some other. Then you may want to add additional information to those commits, like who have reviewed and tested those changes.
Now if you do not really care about history, like you never go back to study what was changed and why then those fix-ups and other crappy commits are not going to hurt you much. But if you try to bisect more than a year worth history of some active project to find the cause of some tricky bug, you will see that having cleaner history makes huge difference.
I have argued for a long time, done experiments, collected data on both real and trivial repositories, and I have convinced hardcore Git fans that explicit is the way to go.
I don't know anything about your experiments, but it would be interesting to see that on real-life repositories, such as the Linux kernel or Git itself. I doubt that it will work any better than what Git does based on heuristic, but it would be interesting to see.
As to your artificial example, it is not convincing, because it is not what you normally have during development, and the conflict is easy to resolve anyway.
We had the freedom to rename or change the files as much as we wanted, and we did so.
Let's suppose, I move a few functions to another file. Now how is your explicit rename/copy tracking is going to help here?
In my experience, moving code around refactoring is much more common than renaming or copying files. With Git, it is easy to find where some function came from. Somehow I have not found similar functionality in Bazaar, but maybe I did not try hard enough to find it.
I don't want my tool to fail just because I am not following best practices.
Git does not fail, it is just that it works better in some cases than in others. Best practices describe how to take most advantage of it. It does not mean that you cannot do in other ways.
but the pieces of the file that changed in both branches get a >>> <<<< conflict marker).
In simple cases, those markers are really useful, but relying on them in complex merges leads to mistakes, because they do not mark all places that has to be changed (regardless whether rename/copy is involved or not). So, much better way to handle complex merges is to use "gitk --merge", where you can see what was changed and why.
Now, for trivial changes, rename heuristic in Git works pretty well. In cases, where you have substantial changes to some files (=>50%), I primary rely on "gitk --merge" anyway, so those markers are not so important. Not to mentioned that in many cases, those markers can be around the wrong lines.
Personally, I don't have much experience with explicit rename tracking (except SVN but it does not do branches well, so it does not count), but accordingly to Linus, explicit rename in BitKeeper caused more confusion than being helpful.
It is entirely possible to apply the same workflow in both tools.
I have not said that is impossible, but it may not be as easy. And this is the reason why people tend to use one tool in one way, and the other in another.
If we speak about Bazaar, a typical approach is to create a feature branch, to do your work on it. When everything is fine and tested to merge it to "trunk". The problem is that intermediate steps may contain mistakes.
One of key features of Git is interactive rebase. It means that you can amend any commit later. You may want to do that due to some mistakes that you did not notice initially, or based on feedback from other developers, or result of testing the same code on another platform. In my experience, it is rare that the initial series of patches is perfect, especially if we speak about not very experience developers or those who work on the code that they do not know well.
Sure, you can use some patch management system instead, but if it is not integrated with your VCS, it is a real pain. But even if it is integrated, it is more complex than you really want in most cases. Obviously, if you maintain some patches on the top of another code, then you need a patch management system. But if you only want to be able to correct your initial series of patches, interactive rebase is much easier to use.
that you can commit part of a changeset without having tested that it compiles
You can always do that with any VCS. The index just gi
I have never heard this argument before
A question about explicit rename was raised so many times on the Git ML, and Linus and then many other developers answered it extensively, so I suggest you look-up their explnations.
the old mantra "explicit is better than implicit" applies here
A mantra is not a logical argument, and while it may be true for many cases, it tends to be oversimplification of reality.
When you say, explicit is better than implicit, does it mean than the C language is better than Python, because allocation memory in C is _explicit_? And then following this line of reasoning, one may conclude than the Assembler language is even better than C, because register allocation is explicit.
The principle explicit is better than implicit only applies to things that matters, while those that do not matter are better to be implicit, so they won't be distraction.
Now, if we speak about renames, what it matters is the end state and how source code was moved, so file content is far more important than some abstract file-id. In other words, it does not matter whether you rename some file or moved most content to a new file. If you are not convinced, then take a look how the "diff" command works. It does not show how lines were actually, moved, but it shows the difference between two states. And, yes, "diff" uses some heuristics to detect this difference, so it does not always produce the perfect result.
The following is all that is required to trigger a complete merge failure on Git
So what? It seems you believe that if something merged automatically then it is good otherwise it is not.
In practice, failure of automatic merge can be a _good_ thing, because it can make a developer to think and resolve the conflict correctly. Definitely, we do not want to bother developers with trivial failures, but when a file is mostly re-written and then it is renamed, then there are some reasons for it. So, a good VCS should be to make obvious the cause of the conflict, and provide means to resolve it easily.
Based on my experience, in practice, the situation that you describe will lead to the wrong merge result anyway. I mean even with less extensive changes to one file when the merge detected automatically and there was a trivial change on the other branch, the end result was more often wrong than right. Of course, if you rename files without any good reason, then you may have more often situations where the automatic merge will be more often right, but I always rename for _some_ reason. So, significant re-write of some file and then its rename did not happen for no reason, and in most cases, no automatic merge can handle that merge correctly. And in trivial cases, it is not a problem to resolve conflict manually.
The merge problem is not new, it is extensively studied in CS. There are some very "smart" algorithms that reduce the number of automatic merge failures. Unfortunately, except some specialized cases, all of them increased the number of correct merges insignificantly and only in trivial cases, which any developer with proper tools will handle without any problem, but the downside is the increase of wrong merge results in far more complex cases. So, this trade-off is simple wrong, and "stupid" 3-way is usually the best approach for general case.
If you are interested in the subject, you should read the discussion that took place between Bram Cohen and Linus Torvalds, which took in May 2005. (Probably, rename also discussed there or maybe it was another thread around that time.)
It is a fully distributed version control system (you might say with Subversion-like centralised support tacked on as an optional feature).
I have never claimed that Bazaar is not truly distributed, but it feels to me like a DVCS that is optimized for a centralized workflow. You certainly can use in other ways too, but it is not so s
the only thing it has going for it is a larger community
Not just a larger user active community, but also larger and more active developer community. It means that even you can find some similar features in Hg or Bzr, they are available as additional plugins, which are less tested and do not get the same support as core features.
I've argued to wit's end that Bazaar is superior to Git in a multitude of ways
Well, same things can be advantages in one but disadvantages in another, because it depends on your workflow. If you try to stick to SVN-like workflow, Bazaar probably works better, but if you try to use a workflow that more similar to what Linux kernel developers use, you will see that Git is _much_ better -- it is more intuitive and all defaults are right for that case. Then some other features like "explicit moves/renames" may sound great for novices, but it does not work well in truly distributed workflow. If every branch gets merged to "trunk" of the central repo, it is not a problem. However, this is not a distributed workflow (just being able to work offline does not make it distributed). When you try to work in really distributed fashion, things can be merged in different directions before ending up in the upstream, the history graph is far more complex and your explicit tracking does not work well. Linus had this experience with BitKeeper, which had explicit tracking for moves/renames, and one lesson that he learned from it was that explicit tracking introduces more problems than it solves. So, by design, Git does not explicitly track rename/copy but uses heuristic instead.
Git lacks commit metadata
This is not true. By definition metadata is "data about data", and Git stores its own metadata in the commit object, but it does not store foreign metadata. There is two reasons for that. First, Git may not know how to deal with them during some operations (e.g. git-rebase). Second, Git does not hide anything from the user. If you want extra information, you can store it in the commit message, in additional file, or as git-notes. However, if this information does not make sense to the user and only necessary for inteeroperability, you should store it separately as git-svn does.
it is impossible to meaningfully use any other revision control system in conjunction with Git
What about git-svn or hg-git?
Yet all I ever hear is "Git is better than all the other revision control systems because [generic reasons why DVCSes are better than centralised ones]."
IMHO, Bazaar got all its defaults for _centralized_ (SVN-like) workflow, but with ability to work offline on feature branches. However if you try to work with many repositories and with many small features branches, which oftentimes take months before they are merged to the main upstream branch (during which they go through a few intermediate merges and internal testing by other developers), you will see that Git handles this case much better. Most people who complain that Git is difficult or not intuitive just have not grasped _distributed_ workflow. Once you have understood distributed workflow, everything in Git becomes very natural. Mercurial is close to Git in this respect, but Bazaar appears to be counter-intuitive.
Git command line is far more intuitive and easy to use than SVN. Trying to use SVN from the command-line is like to use COMMAND.COM -- no completion for names commands or branches (in fact, there is no branches, you got to type f*cking long URLs and of course there is no completion for them either), and there are many other annoying things with SVN. Every time when I tried to write a simple convenience scripts to automatize some routine, it lead to utter frustration how ugly and inconvenient SVN command line is... When I tried Git first time, my experience where the same as moving moving from the ugly and insanely irregular command.com prompt to bash. You can do almost anything from the command line with Git. In fact, the initial version of Git was mostly shell scripts on top a few C written programs. And Git is nicely integrated with bash, so you have completion not only command names but also branches, options, etc...
Their error, as stated in the linked abstract, is less than 0.3%.
It usually means that with 70% probability the value lies with this interval, but if you want to have 90% probability, it is going to be thrice more. So it could be said that the chance that this difference is significant is about 90%. However, it could be some other errors that were not taken into account properly. I would say that without independent confirmation is too early to say that it is an established fact and not a random fluke.
The answer is politics, politics, and politics... The subject of a modern VCS was brought by Eric Raymond, and he clearly favored to Mercurial. It seems most developers on the Emacs ML who were familiar with any DVCS were more inclined to choosing Git. I don't remember if anyone even mentioned Bazaar, before RMS announced that Emacs would migrate to Bazaar. As to justification for this decision, he said that Bazaar agreed to become a Gnu Project, and Gnu Projects should support one another.