"Kids in general" != "your 5 year old". Just because your kid can do something, it doesn't mean that everyone else that age can, or even that it's common that other kids that age can.
Then I suggest you fail to understand the purpose of versioning systems. Their purpose is not to store perfect code. The purpose is to store the latest changes to code. No, I'm not failing to understand anything here. My point has *nothing* to do with the purpose of versioning systems. My point is that there are sloppier programmers, and there are neater programmers. As sloppy programmer might carelessly check in code without testing it (or without testing it thoroughly), believing that it works. A sloppy programmer might take 10 iterations to get something right, while a neater programmer might only need 3 iterations to get that same thing right.
Sure, sometimes I commit code that I know doesn't work when I want to stop working on something, but I want to store the code in a 'safer' place than on my laptop. This merely reinforces the idea that using commit count as a metric of programmer quality is worthless.
But my point still remains: a better programmer will, in general write more correct code than a sloppy/poor/novice programmer. This more correct code might require X bug fixes later, while some less-correct code might require Y bug fixes later, where Y > X. This particular situation will likely result in a greater number of commits being made by the sloppier programmer. My wild guess would be that the number of commits out there that are done to fix bugs due to sloppy programming is *far* greater than the number of commits that are the result of someone intentionally committing broken code that's a work in progress.
In summary: you can't really tell anything about a programmer solely by their commit frequency/quantity, aside from temporal information about when they were working on the project. Advogato had it (at least partially) right: your best source of information on programmer quality is through word of mouth and peer review. Ohloh's foray in this direction (their "kudos" system) is pretty weak at this.
I think its a much bigger issue that all those people sending patches will be ignored, since there isn't really a standard way in most version tracking systems to keep track of the patch submitter instead of those that actually commit it into the repository. That's one of the cool things about git (and maybe others). Each commit has both a "committer name" and "author name" field.
That was the first thing I thought of as well when I noticed their "kudos" system. Then I looked it up, and it turns out that kudos actually is the plural of kudo, and you can use them either way. I've never heard of it used in the singular form before, though.
No, you're also a bad (or perhaps just "sloppy") coder if you constantly make mistakes. Sure, everyone makes mistakes. But some mistakes are "stupid" and some aren't. If you commit broken code that doesn't even compile (and you didn't even test it), and then make another commit to make it compile, then was that first commit a "stupid" mistake? I'd say yes.
This commit count thing is meaningless anyway. Some people commit more or less often, depends on personal preference. Just about the only things you can say are things like "this project has had no commits in 4 years, therefore it hasn't been very active in a while." You can't even make a good/bad value judgement from that statement.
Agreed. And note that Oholoh appears to, by default, only track 'trunk' branches for subversion repositories. So if I spend 6 months and 500 commits working on something on a branch, which I later merge into trunk (one commit), that history isn't tracked. Sure, you can add the branches/ dir to the Ohloh 'enlistment' (what a stupid word), but it seems to be at least frowned upon.
And not all commits are code. A decent percentage of the commits in my projects are i18n/l10n-related. Those are even harder to track as 'contributions' because we have fewer committers than contributors -- many translators just send patches to our i18n mailing list, which those with commit access commit to the repository.
Also, for a while we had a translations maintainer who periodically (it might have been every day) ran 'make update-po' in the po/ directories of all our modules, which updates all the translation files to account for changes in the code, and then committed those changes. Probably the majority of those commits were just for trivial line-number comment changes in the.po files. Regardless, an automated script making daily commits would artificially inflate that committer's stats.
I know one developer who, when working on a new module, codes on it in private (possibly using a private svn repository, but maybe not) until he thinks it'ss ready (and he has very high standards), and then just imports the current state into the public repo as a single commit. So that's more history lost.
I guess this is also a question of how project/server maintainers are about preserving project history. Some people might not have cared so much in the past, and might have thrown away history when (for example) switching SCMs.
So yeah... going by commits in a restricted set of branches of public repositories is a bit questionable, and that's even ignoring the question of "does having more commits really mean you're a better or more valuable developer/contributor?" And I'd even say the answer to that question is "no" or at best "it depends," anyway.
Having said that, it's still a fun site to play with.
Oh, please. Grow up. I release all of my OSS code under the GPL, but I'll be the first to admit it's not the be-all end-all of licenses. The reality of the situation is that many companies have issues with the GPL, whether real or imagined. Hell, people (see: most of the *BSD contingent) consider the GPL not to be a particularly "free" license. Are you saying your opinion is somehow worth more than theirs? How arrogant.
When you consider private sector salaries, and compare with the apparent prestige and "importance" of being a Congressperson, Senators and Representatives don't get paid all that much (just $169,300 for 2008). If you lower their salary, you'll attract the following kinds of people to Congress: a) incredibly stupid people who can't hold a decent job (hmmm... no, that joke's too easy), and b) independently-wealthy people who won't care about the low salary, and likely have in mind the interests of similarly-rich people. Your average American who "just wants to make a difference" won't be able to afford being in Congress.
I don't know that increasing the salary would be a great choice, either, but it would likely attract many of the great minds who currently do much better for themselves working in the private sector. That's something, at least.
Retroactive laws aren't always a bad thing in cases where they forgive crimes. No, that's not the correct way of looking at this. If you want to create a law that makes something legal that was previously illegal, fine. That law itself does not affect the X number of people in jail for committing that illegal act in the past. If you want, then you can issue those X people pardons, but, depending on the circumstances, you may not want to.
Look at it the other way. Say you want to create a law that makes something illegal that was previously legal. Does that mean that everyone who had engaged in this previously-legal act (and, presumably, stopped once it was made illegal) should now be prosecuted for something they did, which, when they did it, was legal?
Retroactive laws are bad, mmkay? They're also expressly prohibited by the US Constitution, not that the current administration cares all that much about that.
NAYs ---67 (Give the telecoms immunity) To be fair, a vote of 'nay' for this amendment doesn't necessarily equate to 'give the telecoms immunity'. There are (or at least have been) other amendments on the table that dealt with this in a different way (e.g., allowing the cases to be heard by a secret FISA court). A senator who voted 'nay' on this particular amendment may have just preferred a different amendment.
Having said that, I'm pissed that only one of my senators (CA) voted 'yea' on this one. (And yes, I did write to both of them about this issue.)
I did a "grep -i" on the term "splice" in my/usr/src/linux/.config and it came up empty. vmsplice is not a kernel option. All kernels from 2.6.17 on have it regardless of configuraion, I believe. grep through your System.map file instead to check for the symbol.
(eg. ARM which probably runs the majority of Linux systems out there... all the phones etc). Not sure if it's true that ARM systems are the majority where Linux is concerned (I'd doubt it), but, regardless, most ARM systems that run Linux probably run uCLinux 2.4, which isn't affected. Only recently has 2.6 been useful on MMU-less systems (most ARM CPUs in actual use in embedded applications don't have an MMU). And even then, I doubt an embedded device would be using a very recent kernel. At work we just started development on a new embedded system with a MIPS processor, and the chipset vendor's recommended 2.6 kernel (i.e., what they did their SDK development on) is 2.6.15.
Would you like to be the pilot who - half way across the pacific - tries to explain "we have no way of opening this door from inside the plane" to the - mostly arab speaking... erm, yelling - terrorist who informs you that one passenger will be executed each minute until the door is opened? Why, yes, actually, in that situation, I would. After 9/11, airplane passengers seem to understand the idea that when a hijacker says, "just cooperate and you'll be safe," it's probably not true. I'd bet the passengers would overpower the hijacker(s) at some point, though likely not without deaths. Were I a pilot, I'd just be happy that, without opening the door, the hijacker "only" has 300-odd people he can kill. If I open the door, he could have many more hundreds, if not thousands. As a frequent flyer, I would not, under any circumstances, want the pilot to open the cockpit door to hijackers.
Would you like to be the official trying to explain the policy that got that door in place to the families of those who were executed because the door was not opened? Where have you been the past 6.5 years? No explanation should be necessary. Cockpit door policy should be common knowledge for anyone who flies these days.
How about when it turns out that the terrorist was the old-fashioned "take me to Syria/Iran/Cuba" kind, who wouldn't have killed anyone if not for that door? That would suck, but there's no way to tell beforehand.
That's not going to help. It doesn't change the regressive nature of a consumption tax for anyone who is not payed. Why not? You make under $W, you get $X in credit. You make under $Y, you get $Z in credit. If your income is zero, I imagine you aren't buying anything, so the point is moot. I'm not saying it's simple (in fact, I specifically said it wasn't), but there are likely ways to eliminate our current income tax, which is fraught with problems and unnecessarily complex, and replace it with a consumption-tax based system that is just as (if not more) fair and is much simpler.
It also makes smuggling a lot more lucrative. That's an enforcement problem, and has little to do with whether or not the system is economically or fiscally sound, aside from the cost of enforcement, which is already quite high with our current income tax system.
Maybe your moral code is dictated to you by what is and isn't legal, but mine isn't. Whoa there, no need for the personal attacks. Taxes are an artificial construct designed to raise revenue for the government, and, in some cases, are used to modify economic behavior. How are taxes (and the act of paying them) inherently moral (or immoral for that matter)?
There are tax loopholes which are unfortunate, but are usually there for some other reason and are mostly compensated for. Look at it on a larger level. Tax loopholes like these are pretty obvious and well known. They could certainly be closed by the federal government if they wanted to do so. They can also be worked around by state governments if they chose to do so. The state of WA could, for example, eliminate corporate profit/income taxes entirely, and raise property taxes on commercial property to make up for the shortfall. But do they do this? No. This sort of thing just amounts to competition between states. Washington makes itself attractive (more competitive) to business owners by not requiring all income to be reported in-state.
This really seems like a massive tax evasion that's not entirely kosher (30%!). The article also questions whether it is actually legal. Ok, I didn't read that (c'mon, this is/.; who RTFAs?). If it's not legal, then sure, MS should be required to pay the tax that is owed, plus the applicable penalties and interest.
Otherwise, I find it hard to assign moral value to taking or not taking advantage of a tax loophole such as this. There's no "right" or "wrong" here. It's just how the tax system works. You can either pay the minimum required in taxes by understanding the tax code and making use of these tricks, or you can pay more than is required and throw your money away.
Also, given that public corporations are required by law to take actions in the best interests of their shareholders, I'd imagine that MS would be opening itself up to massive legal liability if it knew about a (legal) way to save a half billion per year and didn't take advantage of it without good reason.
The web is basically a way of sending invalid markup and tag soup pretending to be XML to users. There, fixed that for you. XHTML hasn't quite caught on just yet.
although the discipline is no less rigorous than any other kind of engineering Oh? Your wall has fallen down? That just seems to happens sometimes. Well, just push it up, go outside your house and come back in. Hopefully it won't happen again. Yeah, no kidding. As a software developer with electrical engineering training, I can say software development is much, much less rigorous than other forms of engineering. Hell, most software I see explicitly avoids accepting any kind of liability for use of the software. A "real" engineering profession shouldn't allow that. But, of course, standards have fallen... I know several people who have "engineer" in their title who are really just glorified project managers.
How is it "stealing" when it's legal? It's not that MS is the only company to take advantage of friendlier tax laws in other states. Hell, Nevada actively *advertises* their tax-friendliness to companies. This isn't anything even remotely new or newsworthy. The only reason it gets an article on Slashdot is because it's about MS, and of course anything MS does is evil.
If I could do something similar -- legally -- with my income taxes, I'd do so in a heartbeat, and I imagine most other people would too. Why give the government money when you can keep it for yourself and they're ok with that?
Why are you blaming Microsoft for this? In this case, they're just doing what they're supposed to do: finding legal means to increase shareholder value. If you want to blame anyone, blame the state of Washington for not finding better ways to tax Microsoft that don't rely on income, which can be easily shifted to friendlier jurisdictions. I imagine MS pays property tax to WA, and probably payroll tax as well. Perhaps those figures should be increased to make up the shortfall from the income tax not being collected? WA has the power to do that.
Impossible? No, certainly not. I've read about schemes whereby people in lower income brackets can be reimbursed for a portion of their consumption tax. It's impossible to be completely fair with a simple flat consumption tax, sure, but, with some added complexity, it can be made more fair. The question is just whether such a system is simpler than the current income tax mess we have right now. If done correctly, I think it could be. But it'll never happen, at least not in the US.
On profits, no, because in publicly owned companies, those profits go to their shareholders. As it stands now, those people are essentially getting taxed twice. First there's a tax on the profits, which reduces that revenue. Then when the revenue is given in dividends to those shareholders, they're taxed individually on that money as well. True, for the (usually small) subset of profit that end up going to a dividend. Many public companies don't even pay a dividend. Those that do generally spend a relatively small percentage of their profits on dividends. In some jurisdictions, profits are taxed, and in others, income is taxed (more like a personal income tax). In some jurisdictions, profits paid out as dividends actually aren't taxed at the corporate level. It's all very confusing.
Not only is their income, which includes those dividends taxed, if they make a lot, they're also hit with another tax, a capital gains tax. So some of them are in reality being taxed three times for that companies revenue. Further, they're also paying taxes on the value of the stock they own in most cases. I think you're misunderstanding how this works. Maybe you're thinking of AMT and not capital gains taxes. Dividends (in the US at least) are usually not considered regular income for an individual, and aren't taxed as regular income. They're taxed as capital gains, and "qualified" dividends, at least, are subject to a lower tax rate (effectively, a long-term capital gains rate) than regular income.
Personally, I'd prefer lower (and simpler!) personal taxes on income, with tighter taxation on corporations, perhaps not even an income tax, since income is easy to shift between locations. There should not be all these tax loopholes that companies can take advantage of. Being able to doge a half-billion in state taxes by opening a 10-person accounting office in a state with fewer or no taxes is ridiculous. I really hold the various US and state governments at fault here, not Microsoft. In this case, they're merely doing what they're required to do by law -- identifying and exploiting all legal means to increase shareholder value.
And have you ever wondered how is it possible that simple text messages can jam the system every New Year? Yes, I have, so I read up on it a few weeks ago. Apparently, on GSM networks, at least, SMS messages are sent on control channels, not on channels used for voice calls, nor on channels dedicated for SMS traffic. There's apparently very limited bandwidth on these control channels, which are also used to *set up* voice calls, so when SMS traffic peaks, not only are you unable to send texts, but you're unable to make or receive new calls. Appalling that the system is designed so poorly. I don't recall where I read this, but I'm sure some googling will turn it up if you're interested.
Ah, I assumed the parent meant "Linux-native" in the sense that it's considered an integral part of the OS, like the Win32 API on Windows, or Cocoa on MacOS X. Meaning that, to have a "native" look on that platform, you'd want to either use those interfaces directly, or use a higher-level interface that makes use of those interfaces internally. Linux really has no "native look," hence my assertion that there isn't really a Linux-native GUI toolkit.
At any rate, back to using the parent's definition, I still wouldn't consider GTK all that much more "Linux-native" than Qt. You mention GTK's Windows and MacOS X backends: I doubt new features/architecture would be accepted into GTK that would break the Windows backend. Ditto for the Mac backend, though it's nowhere near as mature as either the X11 or Windows backends. And similarly (as someone who reads gtk-devel-list regularly), I doubt new functionality would be added to GTK that didn't seem useful in some way on all platforms. I know discussions regarding this have come up in the past.
I couldn't find that much on Qt's early history, but it seems the X11 port of Qt is at least as old as the Windows port, if not older. So I doubt any one platform can drive Qt's development in such a way that would ignore the others. And I'd tend to think that a toolkit designed from the start to be multi-platform would be much better-designed than one that targets only one platform.
Anyhow, just the humble opinion of a developer who's worked with GTK, Qt, Win32 (unfortunately), Cocoa, and a few of others at various times.
That's a big strike against Qt as well: I want a Linux-native toolkit, not a cross-platform toolkit. There's no such thing as a Linux-native toolkit. Given their popularity, though, GTK and Qt are as close as you can get to "Linux-native." (GTK would probably win the popularity contest, though I'm not sure what the margin would be.)
Slashdot Mirror
"Kids in general" != "your 5 year old". Just because your kid can do something, it doesn't mean that everyone else that age can, or even that it's common that other kids that age can.
Sure, sometimes I commit code that I know doesn't work when I want to stop working on something, but I want to store the code in a 'safer' place than on my laptop. This merely reinforces the idea that using commit count as a metric of programmer quality is worthless.
But my point still remains: a better programmer will, in general write more correct code than a sloppy/poor/novice programmer. This more correct code might require X bug fixes later, while some less-correct code might require Y bug fixes later, where Y > X. This particular situation will likely result in a greater number of commits being made by the sloppier programmer. My wild guess would be that the number of commits out there that are done to fix bugs due to sloppy programming is *far* greater than the number of commits that are the result of someone intentionally committing broken code that's a work in progress.
In summary: you can't really tell anything about a programmer solely by their commit frequency/quantity, aside from temporal information about when they were working on the project. Advogato had it (at least partially) right: your best source of information on programmer quality is through word of mouth and peer review. Ohloh's foray in this direction (their "kudos" system) is pretty weak at this.
That was the first thing I thought of as well when I noticed their "kudos" system. Then I looked it up, and it turns out that kudos actually is the plural of kudo, and you can use them either way. I've never heard of it used in the singular form before, though.
No, you're also a bad (or perhaps just "sloppy") coder if you constantly make mistakes. Sure, everyone makes mistakes. But some mistakes are "stupid" and some aren't. If you commit broken code that doesn't even compile (and you didn't even test it), and then make another commit to make it compile, then was that first commit a "stupid" mistake? I'd say yes.
This commit count thing is meaningless anyway. Some people commit more or less often, depends on personal preference. Just about the only things you can say are things like "this project has had no commits in 4 years, therefore it hasn't been very active in a while." You can't even make a good/bad value judgement from that statement.
Agreed. And note that Oholoh appears to, by default, only track 'trunk' branches for subversion repositories. So if I spend 6 months and 500 commits working on something on a branch, which I later merge into trunk (one commit), that history isn't tracked. Sure, you can add the branches/ dir to the Ohloh 'enlistment' (what a stupid word), but it seems to be at least frowned upon.
.po files. Regardless, an automated script making daily commits would artificially inflate that committer's stats.
And not all commits are code. A decent percentage of the commits in my projects are i18n/l10n-related. Those are even harder to track as 'contributions' because we have fewer committers than contributors -- many translators just send patches to our i18n mailing list, which those with commit access commit to the repository.
Also, for a while we had a translations maintainer who periodically (it might have been every day) ran 'make update-po' in the po/ directories of all our modules, which updates all the translation files to account for changes in the code, and then committed those changes. Probably the majority of those commits were just for trivial line-number comment changes in the
I know one developer who, when working on a new module, codes on it in private (possibly using a private svn repository, but maybe not) until he thinks it'ss ready (and he has very high standards), and then just imports the current state into the public repo as a single commit. So that's more history lost.
I guess this is also a question of how project/server maintainers are about preserving project history. Some people might not have cared so much in the past, and might have thrown away history when (for example) switching SCMs.
So yeah... going by commits in a restricted set of branches of public repositories is a bit questionable, and that's even ignoring the question of "does having more commits really mean you're a better or more valuable developer/contributor?" And I'd even say the answer to that question is "no" or at best "it depends," anyway.
Having said that, it's still a fun site to play with.
Oh, please. Grow up. I release all of my OSS code under the GPL, but I'll be the first to admit it's not the be-all end-all of licenses. The reality of the situation is that many companies have issues with the GPL, whether real or imagined. Hell, people (see: most of the *BSD contingent) consider the GPL not to be a particularly "free" license. Are you saying your opinion is somehow worth more than theirs? How arrogant.
When you consider private sector salaries, and compare with the apparent prestige and "importance" of being a Congressperson, Senators and Representatives don't get paid all that much (just $169,300 for 2008). If you lower their salary, you'll attract the following kinds of people to Congress: a) incredibly stupid people who can't hold a decent job (hmmm... no, that joke's too easy), and b) independently-wealthy people who won't care about the low salary, and likely have in mind the interests of similarly-rich people. Your average American who "just wants to make a difference" won't be able to afford being in Congress.
I don't know that increasing the salary would be a great choice, either, but it would likely attract many of the great minds who currently do much better for themselves working in the private sector. That's something, at least.
Look at it the other way. Say you want to create a law that makes something illegal that was previously legal. Does that mean that everyone who had engaged in this previously-legal act (and, presumably, stopped once it was made illegal) should now be prosecuted for something they did, which, when they did it, was legal?
Retroactive laws are bad, mmkay? They're also expressly prohibited by the US Constitution, not that the current administration cares all that much about that.
Having said that, I'm pissed that only one of my senators (CA) voted 'yea' on this one. (And yes, I did write to both of them about this issue.)
Probably a speed trap, or some retarded anti-illegal-immigrant thing. That's certainly not a common practice in the US.
Otherwise, I find it hard to assign moral value to taking or not taking advantage of a tax loophole such as this. There's no "right" or "wrong" here. It's just how the tax system works. You can either pay the minimum required in taxes by understanding the tax code and making use of these tricks, or you can pay more than is required and throw your money away.
Also, given that public corporations are required by law to take actions in the best interests of their shareholders, I'd imagine that MS would be opening itself up to massive legal liability if it knew about a (legal) way to save a half billion per year and didn't take advantage of it without good reason.
How is it "stealing" when it's legal? It's not that MS is the only company to take advantage of friendlier tax laws in other states. Hell, Nevada actively *advertises* their tax-friendliness to companies. This isn't anything even remotely new or newsworthy. The only reason it gets an article on Slashdot is because it's about MS, and of course anything MS does is evil.
If I could do something similar -- legally -- with my income taxes, I'd do so in a heartbeat, and I imagine most other people would too. Why give the government money when you can keep it for yourself and they're ok with that?
Why are you blaming Microsoft for this? In this case, they're just doing what they're supposed to do: finding legal means to increase shareholder value. If you want to blame anyone, blame the state of Washington for not finding better ways to tax Microsoft that don't rely on income, which can be easily shifted to friendlier jurisdictions. I imagine MS pays property tax to WA, and probably payroll tax as well. Perhaps those figures should be increased to make up the shortfall from the income tax not being collected? WA has the power to do that.
Impossible? No, certainly not. I've read about schemes whereby people in lower income brackets can be reimbursed for a portion of their consumption tax. It's impossible to be completely fair with a simple flat consumption tax, sure, but, with some added complexity, it can be made more fair. The question is just whether such a system is simpler than the current income tax mess we have right now. If done correctly, I think it could be. But it'll never happen, at least not in the US.
Personally, I'd prefer lower (and simpler!) personal taxes on income, with tighter taxation on corporations, perhaps not even an income tax, since income is easy to shift between locations. There should not be all these tax loopholes that companies can take advantage of. Being able to doge a half-billion in state taxes by opening a 10-person accounting office in a state with fewer or no taxes is ridiculous. I really hold the various US and state governments at fault here, not Microsoft. In this case, they're merely doing what they're required to do by law -- identifying and exploiting all legal means to increase shareholder value.
Ah, I assumed the parent meant "Linux-native" in the sense that it's considered an integral part of the OS, like the Win32 API on Windows, or Cocoa on MacOS X. Meaning that, to have a "native" look on that platform, you'd want to either use those interfaces directly, or use a higher-level interface that makes use of those interfaces internally. Linux really has no "native look," hence my assertion that there isn't really a Linux-native GUI toolkit.
At any rate, back to using the parent's definition, I still wouldn't consider GTK all that much more "Linux-native" than Qt. You mention GTK's Windows and MacOS X backends: I doubt new features/architecture would be accepted into GTK that would break the Windows backend. Ditto for the Mac backend, though it's nowhere near as mature as either the X11 or Windows backends. And similarly (as someone who reads gtk-devel-list regularly), I doubt new functionality would be added to GTK that didn't seem useful in some way on all platforms. I know discussions regarding this have come up in the past.
I couldn't find that much on Qt's early history, but it seems the X11 port of Qt is at least as old as the Windows port, if not older. So I doubt any one platform can drive Qt's development in such a way that would ignore the others. And I'd tend to think that a toolkit designed from the start to be multi-platform would be much better-designed than one that targets only one platform.
Anyhow, just the humble opinion of a developer who's worked with GTK, Qt, Win32 (unfortunately), Cocoa, and a few of others at various times.