Dieter Reiter has attacked the Limux project from day one he was in office, starting to spread FUD like his inability to access his mobile mail was due to Limux flaws instead of workflow issues. His head of IT publicly denied Reiter's claims and refuted them.
Mr. Reiter has "outed" himself as a Microsoft fan in the past (before he became mayor) and was personally involved in moving Microsoft Germany's headquarters from the Munich suburb to the city of Munich itself.
So this is more of a personal/political issue. Munich's IT staff still thinks Limux is a good solution and luckily there is opposition to Reiters FUD in the town hall. Going back to Microsoft would be very costly but now that Microsoft has its HQ in Munich, I'm pretty sure the lobbying has taken up steam and there's going to be "deals benefiting both sides" here.
Over the years, I've worked with about 20 different languages. I learned a lot of them purely out of interest. Even if you won't need it for any "serious" or paying work, it can be useful to learn a new language that is different from the languages you know. For example, if you know C# you won't learn that much by working with Java; they're too similar. By contrast, if you try learning a language like Haskell or Go instead you'll get introduced to new ways of thinking.
In almost all languages, there are things you can do easily or "naturally" in it. These language (and framework) features usually influence how you would design a program in that language. And it's these concepts that are worth learning. For example, when I learned Ruby and later Haskell, I learned how powerful concepts like map/select or working with closures are.
This knowledge then transferred to the languages I usually work with; my designs in my "traditional" languages changed because of the things I learned while working with other languages.
So even if the new language is not "one the rise" it might pay off by indirectly improving your skills in the languages that you do get paid for.
Dang, me using the incorrect case of the "v" suddenly destroyed several years of experience? Oh gosh, and I thought actually following the mailing-list for several years since the betas and reading about how and why those people designed the tool would give me some understanding about it, but you're right: spelling is way more important.
I've worked on a SubVersion project for several years where the smallest useful checkout was 5GB (it was an in-house Linux distribution I've built and maintained). On a local network, SubVersion works pretty well for these things but you're right, I wouldn't want to do this over a poor Internet connection. It's pretty space efficient with binary files and handles things like copies and renames very well, so if you need to deal with them a lot then SubVersion is a good choice. Git and SubVersion work very differently, each have features the other doesn't have, by design. Believe it or not, SubVersion was also *designed* for large projects, but different use-cases. I really, really wouldn't want to maintain my distribution with Git. Now that I'm a "normal" developer again, we're using Mercurial and Git since they're better suited for these tasks, handling source/text files with lots of branching and merging.
Have you ever split a large project into several components stored in different repositories and tried to keep them in a consistent state? Like, trying to rebuild a version exactly as it was one year ago because a customer needs a very specific fix for that version? I've come to learn that especially with huge projects it can be a very good idea to have everything in one repository.
With SubVersion, you can check out subtrees instead of the whole repository (even non-recursively, so you can check out a directory "in the middle"). That's something that Git or Mercurial can't do by design; IIRC it's because the always-complete-repository approach makes merging and other tasks much, much easier. In your SVN working copy, only the data of commit you've checked out are stored. For everything else SVN needs to contact the server which depending on the requirements and workflow, is either a good or bad thing. On the other hand, Git and Mercurial do have the complete history locally which allows them to perform a lot of tasks without contacting a server that SubVersion could not do (simple example: get log history of a file).
But it's actually besides the point: all of these things won't matter to an office user. Ease-of-use and chances-to-screw-up do.
Now you've got into rant-mode, sorry. I really hope non-technical people are never forced to actually type in commands but use a GUI instead, no matter which VCS they use. But especially with Git. I think Git is a very powerful tool and have come to like it for its features, but I still hate it for its commands and what I feel are inconsistencies and "fuck how other VCS are naming it, we use something different".
For example, discard changes on a single file: "git reset foo.bar". Discard changes on all files: "git checkout --.". WTF? Just a few days ago, I wanted Git to give me the diff of specific commit, the equivalent to "svn diff -c revision" or "hg diff -c revision". In git? "git diff revision^ revision" or "git diff revision^!" (which I overread when I was reading the man page and needed to look it up on Ye Olde Interweb). Or "git diff-tree -p revision" or "git whatchanged -m -n 1 -p revision" since why not? And "git add" both adds a new file to the repository but also picks a modified file to be included in the next commit (but only the parts that have not changed between add and commit. The add behaviour does make sense when you think "from the inside" of the VCS, but I was confused at first and I'm a technical guy. Normal people will have trouble with this stuff. Seriously, I've been using various VCS in last two decades and still am doing a lot in the shell, especially VCS stuff since I feel to be more in control this way. But Git is the first VCS that I use almost exclusively in a GUI because it's CLI is too cumbersome.
I've been using SubVersion since it was in beta and have used it at work and in private in multi-gigabyte projects. SubVersion was always rock-solid for us, and it's handling binary files very well (which was the prime reason we decided to switch use SVN back then in about 2003). Git is an excellent tool for us developers, but I feel it's way too complicated for non-technical people who don't need these bells and whistles.
That's exactly how I started as well. The manuals I had were in english (plus DOS; that's how I picked up basic english) but we had books in our library that were in German. So not knowing english doesn't stop you, but I guess it would've been easier/nicer if I would've been able to start in my native tongue.
Why not use the time to learn English first. It will be more useful to her than programming.
Learning a whole language first isn't much fun. Also, lots of people I know (me included) learned programming first, then (through programming) english. I started with GW-BASIC at age of 7 and almost everything was in english: the programs I had, even the manuals. I picked up basic english from this (after some trial and error you understand what certain words or phrases mean; I was pretty surprised when I learned at school that these words are pronounced totally differently than I imagined;-)
I even knew a pretty good programmer who still does not speak english. He couldn't ask for directions if he'd get lost. Yet he manages to do hold up as a professional. Couldn't believe it at first, but it shows that knowing english does help when developing but it's not strictly necessary. The good thing about programming is that the syntax rules are so much more strict and easier to understand than natural language.
This is encouraging, not forcing. So I'm all for it. If a friend of my father hadn't introduced me to programming at age of 7, I would have missed something that soon turned into a passion and is now my day job. That was the most important event in my life, second only to my birth. You have to give kids the chance to try something to see whether they like it, like chemistry or electronic kits. If they like it, great! If not, so what.
Interesting. The linked Wikipedia article talks about speaking and reading, and the later is indeed way harder to learn in asian languages. It would be interesting to see how this list turned out if you ignore the reading/writing. In Japanese, you can also write everything in Hiragana, for example; that's easy to learn but not as exact due to homonyms, words that are pronounced the same but have different meaning. These words usually have different Kanji, so you can distinguish them when using Kanji but not when using Hiragana. My experience is this: I'm German, have learned English and French at school (though I can't talk the later now) and have learned Japanese in an evening school (though I can't speak that one either now). I found that while Japanese has a totally different grammar than the others, it was easier to learn due to the grammar being not as complex and not having so many exceptions like european languages usually do (irregular verbs and the like). But it seems I'm the exception here.
I second this. There's going to be a huge demand for Westerners who can talk and even write Chinese. The market is large and growing fast. An alternative to that would be Russian. But beware, although it's easier to learn the cyrillic alphabet than chinese characters, the language itself seems to actually be harder to learn from what I've heard so far: it seems to have lots of irregularities. A former colleague, who's Russian, said that after living a few years in Germany and speaking almost no Russian during that time had him forget a few of those irregularities in the Russian language and his Russian friends immediately noticed when he visited them. My father wanted to learn Russian and gave up because there are words that have flections that don't seem to be related to the original word at all and you need to learn a lot of vocabulary due to the grammar. By contrast, AFAIK the chinese grammar is "odd" for westerners but not hard to learn.
I find it a bit strange that these trading systems don't seem to use some kind of identification (like signed certificates). How is it possible that some system did these things and the stock exchange doesn't immediately know whose system this was? This sounds like a disaster waiting to happen.
The law-blogger Florian Müller has a more in-depth explanation of this issue. He especially explains how this is not an US court interfering with a German court's decision. The US court merely prevents Motorola from enforcing the injunction, should it win it.
In Germany, if the court grants you an injunction it is not automatically enforced immediately. The winning party needs to explicitly enforce it.
Now a US court decided that the company Motorola may not enforce this injunction should it win it, since there are ongoing actions that have not been decided (like, whether the patent in question is actually invalid). So if Motorola were to enforce this injunction it would have an unfair disadvantage.
So the US court has not interfered with German courts: it only ruled what the company Motorola may do should it win this battle in Germany.
We spent about 20% of our total man-hours last year dealing with Android in one way or another - porting, platform specific bug fixes, customer service, etc. [] Meanwhile, Android sales amounted to around 5% of our revenue for the year, and continues to shrink. Needless to say, this ratio is unsustainable.
While you quote from the blog (even from an older entry), you seemed to didn't really read his other blog entry about Android. And BTW, their opinion is important because their apps are successful and of high quality.
The most frustrating part about developing for android is actually just dealing with the deluge of support e-mail, most of which is related to download and installation problems which have nothing to do with the app itself, and everything to do with the android OS and market having innate technical problems. Do some googling for "can't download apps from android market" or similar wording, and you'll see that this is a widespread chronic issue for all devices and all OS versions. There are numerous possible causes, and there's nothing I can really do about it as a developer, since its essentially just a problem with the market itself. Based on the amount of e-mails I get every day, download problems effect 1-2% of all buyers, or in more practical terms, somewhere between two and three shit-loads. I have an FAQ posted which offers solutions for the most common problems, but lots of people can't be troubled to read it before sending off an e-mail demanding a refund.
I don't think Bill was threatened by the patents since, as Steve himself said, Apple wouldn't have had the endurance to fight this war. But during this time (1997) was already eyed for abusing its almost-monopoly, and losing the only "serious" competitor (which, compared to MS at that time, was still tiny) wouldn't have helped Microsoft on that front. So I guess it was more valuable for MS to avoid additional antitrust trouble. Also, despite their competition, Bill respected Steve (but the other way round I'm not so sure; Steve said he respected Bill, but while reading the bio I'm sure he lied).
For Apple, it really was an act of desperation that in hindsight payed off. But at the Macworld Expo, there was this famous presentation where Apple announced the deal, that MS would do Office for Mac and made a kind of teleconference with Bill. Bill appeared super-big on the screen, with a grin. The audience booed, which Bill didn't hear. Steve later described this as his biggest failure on stage: it made Steve look little and weak, at the mercy of the Evil Overlord Bill.
Slashdot Mirror
Dieter Reiter has attacked the Limux project from day one he was in office, starting to spread FUD like his inability to access his mobile mail was due to Limux flaws instead of workflow issues. His head of IT publicly denied Reiter's claims and refuted them. Mr. Reiter has "outed" himself as a Microsoft fan in the past (before he became mayor) and was personally involved in moving Microsoft Germany's headquarters from the Munich suburb to the city of Munich itself. So this is more of a personal/political issue. Munich's IT staff still thinks Limux is a good solution and luckily there is opposition to Reiters FUD in the town hall. Going back to Microsoft would be very costly but now that Microsoft has its HQ in Munich, I'm pretty sure the lobbying has taken up steam and there's going to be "deals benefiting both sides" here.
Over the years, I've worked with about 20 different languages. I learned a lot of them purely out of interest. Even if you won't need it for any "serious" or paying work, it can be useful to learn a new language that is different from the languages you know. For example, if you know C# you won't learn that much by working with Java; they're too similar. By contrast, if you try learning a language like Haskell or Go instead you'll get introduced to new ways of thinking.
In almost all languages, there are things you can do easily or "naturally" in it. These language (and framework) features usually influence how you would design a program in that language. And it's these concepts that are worth learning. For example, when I learned Ruby and later Haskell, I learned how powerful concepts like map/select or working with closures are.
This knowledge then transferred to the languages I usually work with; my designs in my "traditional" languages changed because of the things I learned while working with other languages.
So even if the new language is not "one the rise" it might pay off by indirectly improving your skills in the languages that you do get paid for.
Dang, me using the incorrect case of the "v" suddenly destroyed several years of experience? Oh gosh, and I thought actually following the mailing-list for several years since the betas and reading about how and why those people designed the tool would give me some understanding about it, but you're right: spelling is way more important.
I'd love to see you explain all this to an average office lady :-)
I've worked on a SubVersion project for several years where the smallest useful checkout was 5GB (it was an in-house Linux distribution I've built and maintained). On a local network, SubVersion works pretty well for these things but you're right, I wouldn't want to do this over a poor Internet connection. It's pretty space efficient with binary files and handles things like copies and renames very well, so if you need to deal with them a lot then SubVersion is a good choice. Git and SubVersion work very differently, each have features the other doesn't have, by design. Believe it or not, SubVersion was also *designed* for large projects, but different use-cases. I really, really wouldn't want to maintain my distribution with Git. Now that I'm a "normal" developer again, we're using Mercurial and Git since they're better suited for these tasks, handling source/text files with lots of branching and merging.
Have you ever split a large project into several components stored in different repositories and tried to keep them in a consistent state? Like, trying to rebuild a version exactly as it was one year ago because a customer needs a very specific fix for that version? I've come to learn that especially with huge projects it can be a very good idea to have everything in one repository.
With SubVersion, you can check out subtrees instead of the whole repository (even non-recursively, so you can check out a directory "in the middle"). That's something that Git or Mercurial can't do by design; IIRC it's because the always-complete-repository approach makes merging and other tasks much, much easier. In your SVN working copy, only the data of commit you've checked out are stored. For everything else SVN needs to contact the server which depending on the requirements and workflow, is either a good or bad thing. On the other hand, Git and Mercurial do have the complete history locally which allows them to perform a lot of tasks without contacting a server that SubVersion could not do (simple example: get log history of a file).
But it's actually besides the point: all of these things won't matter to an office user. Ease-of-use and chances-to-screw-up do.
Now you've got into rant-mode, sorry. I really hope non-technical people are never forced to actually type in commands but use a GUI instead, no matter which VCS they use. But especially with Git. I think Git is a very powerful tool and have come to like it for its features, but I still hate it for its commands and what I feel are inconsistencies and "fuck how other VCS are naming it, we use something different".
For example, discard changes on a single file: "git reset foo.bar". Discard changes on all files: "git checkout -- .". WTF? Just a few days ago, I wanted Git to give me the diff of specific commit, the equivalent to "svn diff -c revision" or "hg diff -c revision". In git? "git diff revision^ revision" or "git diff revision^!" (which I overread when I was reading the man page and needed to look it up on Ye Olde Interweb). Or "git diff-tree -p revision" or "git whatchanged -m -n 1 -p revision" since why not? And "git add" both adds a new file to the repository but also picks a modified file to be included in the next commit (but only the parts that have not changed between add and commit. The add behaviour does make sense when you think "from the inside" of the VCS, but I was confused at first and I'm a technical guy. Normal people will have trouble with this stuff. Seriously, I've been using various VCS in last two decades and still am doing a lot in the shell, especially VCS stuff since I feel to be more in control this way. But Git is the first VCS that I use almost exclusively in a GUI because it's CLI is too cumbersome.
I've been using SubVersion since it was in beta and have used it at work and in private in multi-gigabyte projects. SubVersion was always rock-solid for us, and it's handling binary files very well (which was the prime reason we decided to switch use SVN back then in about 2003). Git is an excellent tool for us developers, but I feel it's way too complicated for non-technical people who don't need these bells and whistles.
As a first language? That's like giving a kid a Hayabusa instead of a bike with learning wheels.
That's exactly how I started as well. The manuals I had were in english (plus DOS; that's how I picked up basic english) but we had books in our library that were in German. So not knowing english doesn't stop you, but I guess it would've been easier/nicer if I would've been able to start in my native tongue.
Why not use the time to learn English first. It will be more useful to her than programming.
Learning a whole language first isn't much fun. Also, lots of people I know (me included) learned programming first, then (through programming) english. I started with GW-BASIC at age of 7 and almost everything was in english: the programs I had, even the manuals. I picked up basic english from this (after some trial and error you understand what certain words or phrases mean; I was pretty surprised when I learned at school that these words are pronounced totally differently than I imagined ;-)
I even knew a pretty good programmer who still does not speak english. He couldn't ask for directions if he'd get lost. Yet he manages to do hold up as a professional. Couldn't believe it at first, but it shows that knowing english does help when developing but it's not strictly necessary. The good thing about programming is that the syntax rules are so much more strict and easier to understand than natural language.
Give that kid a break, she already speaks two languages and you want her to force to learn a third already? How many do you speak?
You do realize that a lot of non-native english speaker read Slashdot?
This is encouraging, not forcing. So I'm all for it. If a friend of my father hadn't introduced me to programming at age of 7, I would have missed something that soon turned into a passion and is now my day job. That was the most important event in my life, second only to my birth. You have to give kids the chance to try something to see whether they like it, like chemistry or electronic kits. If they like it, great! If not, so what.
Interesting. The linked Wikipedia article talks about speaking and reading, and the later is indeed way harder to learn in asian languages. It would be interesting to see how this list turned out if you ignore the reading/writing. In Japanese, you can also write everything in Hiragana, for example; that's easy to learn but not as exact due to homonyms, words that are pronounced the same but have different meaning. These words usually have different Kanji, so you can distinguish them when using Kanji but not when using Hiragana. My experience is this: I'm German, have learned English and French at school (though I can't talk the later now) and have learned Japanese in an evening school (though I can't speak that one either now). I found that while Japanese has a totally different grammar than the others, it was easier to learn due to the grammar being not as complex and not having so many exceptions like european languages usually do (irregular verbs and the like). But it seems I'm the exception here.
You didn't read the posting at all, only the title, didn't you?
I second this. There's going to be a huge demand for Westerners who can talk and even write Chinese. The market is large and growing fast. An alternative to that would be Russian. But beware, although it's easier to learn the cyrillic alphabet than chinese characters, the language itself seems to actually be harder to learn from what I've heard so far: it seems to have lots of irregularities. A former colleague, who's Russian, said that after living a few years in Germany and speaking almost no Russian during that time had him forget a few of those irregularities in the Russian language and his Russian friends immediately noticed when he visited them. My father wanted to learn Russian and gave up because there are words that have flections that don't seem to be related to the original word at all and you need to learn a lot of vocabulary due to the grammar. By contrast, AFAIK the chinese grammar is "odd" for westerners but not hard to learn.
I find it a bit strange that these trading systems don't seem to use some kind of identification (like signed certificates). How is it possible that some system did these things and the stock exchange doesn't immediately know whose system this was? This sounds like a disaster waiting to happen.
The law-blogger Florian Müller has a more in-depth explanation of this issue. He especially explains how this is not an US court interfering with a German court's decision. The US court merely prevents Motorola from enforcing the injunction, should it win it.
s/unfair disadvantage/unfair advantage/
In Germany, if the court grants you an injunction it is not automatically enforced immediately. The winning party needs to explicitly enforce it.
Now a US court decided that the company Motorola may not enforce this injunction should it win it, since there are ongoing actions that have not been decided (like, whether the patent in question is actually invalid). So if Motorola were to enforce this injunction it would have an unfair disadvantage.
So the US court has not interfered with German courts: it only ruled what the company Motorola may do should it win this battle in Germany.
From the fine blog post (emphasize mine):
We spent about 20% of our total man-hours last year dealing with Android in one way or another - porting, platform specific bug fixes, customer service, etc. [] Meanwhile, Android sales amounted to around 5% of our revenue for the year, and continues to shrink. Needless to say, this ratio is unsustainable.
While you quote from the blog (even from an older entry), you seemed to didn't really read his other blog entry about Android. And BTW, their opinion is important because their apps are successful and of high quality.
The most frustrating part about developing for android is actually just dealing with the deluge of support e-mail, most of which is related to download and installation problems which have nothing to do with the app itself, and everything to do with the android OS and market having innate technical problems. Do some googling for "can't download apps from android market" or similar wording, and you'll see that this is a widespread chronic issue for all devices and all OS versions. There are numerous possible causes, and there's nothing I can really do about it as a developer, since its essentially just a problem with the market itself. Based on the amount of e-mails I get every day, download problems effect 1-2% of all buyers, or in more practical terms, somewhere between two and three shit-loads. I have an FAQ posted which offers solutions for the most common problems, but lots of people can't be troubled to read it before sending off an e-mail demanding a refund.
I don't think Bill was threatened by the patents since, as Steve himself said, Apple wouldn't have had the endurance to fight this war. But during this time (1997) was already eyed for abusing its almost-monopoly, and losing the only "serious" competitor (which, compared to MS at that time, was still tiny) wouldn't have helped Microsoft on that front. So I guess it was more valuable for MS to avoid additional antitrust trouble. Also, despite their competition, Bill respected Steve (but the other way round I'm not so sure; Steve said he respected Bill, but while reading the bio I'm sure he lied).
For Apple, it really was an act of desperation that in hindsight payed off. But at the Macworld Expo, there was this famous presentation where Apple announced the deal, that MS would do Office for Mac and made a kind of teleconference with Bill. Bill appeared super-big on the screen, with a grin. The audience booed, which Bill didn't hear. Steve later described this as his biggest failure on stage: it made Steve look little and weak, at the mercy of the Evil Overlord Bill.