The only mistake they made with 4 was treating 4.0 as a release. If they had waited longer for an actual release, or been serious in indicating to people that it was really 4.0 tech preview, then a lot of the bad feelings towards KDE 4 would not have arisen.
Re:Each major release is taking longer
on
KDE 4.7.0 Released
·
· Score: 1
"I dispute the notion that it's "progress" to copy what everyone else is doing, but implement it with your own little twist."
How is KDE 3.5 any different? KDE 3.5 copied Windows 2000 and KDE 4 is copying Vista. Aside from superficial things like that, the KDE way is just as present in KDE 4 as in KDE 3.5. For the things that have changed, and you don't like, you very easily can change it to be like KDE 3.5: the K menu, the desktop, the file manager can all be configured to be like KDE 3.5. You can even use Plastik as your theme if that makes you feel more at home. On the plus side, everything works better and is actually being updated.
I'm saying this as a former die-hard KDE 3.5 fan who did not switch to KDE 4 until KDE 4.5.
I keep seeing people post these kinds of attacks on KDE, yet they are never followed up with any substantial explanation of what the clutter and bloat actually is. I guess compared to GNOME, where having two checkboxes in a single window is considered advanced and confusing, KDE might look "cluttered". Personally, I like being able to actually do things with my computer. Every other OS lets you do that, why shouldn't Linux?
Don't forget QtCurve, which I find to be considerably better than the ugly and garish Oxygen theme.
Re:Is this a production release or another alpha?
on
KDE 4.7.0 Released
·
· Score: 1
Short answer: yes. Longer answer: yeah, it's pretty usable, actually seems more polished and complete than KDE 3.5 was. I was a hold-out, too, lest you accuse me of being some KDE 4 fanboi.
Re:Each major release is taking longer
on
KDE 4.7.0 Released
·
· Score: 1
It was three and a half years ago. Get over it.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
That's what tags are for. As for getting a sense of "how far", a proper version numbering scheme would impart just as much, if not more, information. However, if you still want something like that, you could easily count the commits and append that to your version number. Some projects like to use the SHA1 hash as the tail of the version number. You could combine both easily.
Git submodules and the git subtree add-on take care of a lot of that, actually. You can also do a shallow clone, so you don't get the entire history. I'll admit it's easier in SVN because it's the default (and indeed, only) way to do things.
Re:because the others still suck
on
The Rise of Git
·
· Score: 1
You can use git show and git archive to spit out individual files or directories of the repo for any previous commit. While it's one slightly extra step, it's pretty flexible and applies not just to branches, but to all commits.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
What problem do the revision numbers solve that tags or just using SHA1 ids (including the abbreviated ones) don't?
Then don't commit stuff to a branch you intend to push? Seems pretty straightforward to me...
Re:Data, Images, Binary builds etc.
on
The Rise of Git
·
· Score: 3, Informative
I store binary data in my Git repos and it doesn't seem to balloon as badly these days as people make it out to be.
In fact, Git seems to be good enough at it that I use it to do application releases. It's faster for me to build an app, commit it to a special Git repo and push the new commit, than to send it via SFTP over the VPN (a few hundred KB vs dozens of MB). In that repo, I have hundreds of new versions, but it's only a few hundred megabytes. The equivalent in file storage would be easily ten times as much.
I don't doubt that other VCSes do better, but Git is not awful.
What's the problem with 150+ repos? What's hard to manage? How is that any harder than managing 150+ separate projects (which you have to do anyway no matter what VCS you use)?
Both SVN and Git can handle only checking in a few changes, although Git has nicer tools built-in for committing only particular changes you've made (git add -p, for example). So I'm not sure what you're talking about in your last sentence.
Re:Large, complex projects require good source con
on
The Rise of Git
·
· Score: 1
I use Git on my project which has only one developer (me, of course). I can't imagine working without source control.
Why would homeopathy work for anything? The mechanism is completely bogus. If anyone gets better after a homeopathic treatment, it's entirely placebo or luck (which is actually true of a lot of things -- we tend to naturally get over viruses like the cold and allergies wax and wane, etc.).
In Old English, the past tense of "cuman" was either "com" (with long o) or "cam" (with long a), neither of which would have produced "came". You can consult any book on Old English to find the conjugation of such a common verb. My one Middle English book only gives "com" and "come" as the past tense of that verb, although with no textual citations. So I went and found an online Middle English dictionary and looked up "comen" (http://quod.lib.umich.edu/cgi/m/mec/med-idx?size=First+100&type=headword&q1=comen&rgxp=constrained) and found this: "ME p. sg. cam, com & p. pl. ca:men, ke:me(n are analogical formations, modeled largely on the type of stal, ste:len." (a: and e: are my edits to indicate long a and e, respectively). Note that it lists "com" as the normal past tense. I don't know what the frequency of "cam" vs. "co:m", but my guess is that the former must have eventually become frequent enough to take over for most dialects.
Now on to your second point. It's true that just because one sees the morpheme "come" does not mean the verb necessarily conjugates (not declines) like the base verb "come". However, in the case of "become", we know that it does in fact conjugate the same as the base. In fact, pretty much all verbs that are formed by adding a prefix like be- and for- are conjugated the same as the base verb. You only get a different conjugation when the stem in question is laundered through another part of speech. In the case of "welcome", there is a noun "welcome" and that is the basis for the verb "to welcome", which is thus conjugated like a weak verb (as all verbs derived from nouns are conjugated). The derivation seems to go back to Old English, where the verb was "wilcumian" (http://www.bosworthtoller.com/035723) and thus a weak verb derived from a noun.
Final point: it's entirely possible that it was just a typographic or spelling error. Not knowing whether the writer of the sentence in question is from an area where they speak a dialect that has "come" as the past tense of "come", I cannot say for sure which is the actual case. Either way, it's really just not that big a deal.
It might be the dialectical past tense of "come" which is "come", not "came". "come" as the past tense is more etymologically correct, but the alternate form "came" took over in most places and is now the standard.
Slashdot Mirror
Which things would those be? I'm serious. What's really missing?
The only mistake they made with 4 was treating 4.0 as a release. If they had waited longer for an actual release, or been serious in indicating to people that it was really 4.0 tech preview, then a lot of the bad feelings towards KDE 4 would not have arisen.
"I dispute the notion that it's "progress" to copy what everyone else is doing, but implement it with your own little twist."
How is KDE 3.5 any different? KDE 3.5 copied Windows 2000 and KDE 4 is copying Vista. Aside from superficial things like that, the KDE way is just as present in KDE 4 as in KDE 3.5. For the things that have changed, and you don't like, you very easily can change it to be like KDE 3.5: the K menu, the desktop, the file manager can all be configured to be like KDE 3.5. You can even use Plastik as your theme if that makes you feel more at home. On the plus side, everything works better and is actually being updated.
I'm saying this as a former die-hard KDE 3.5 fan who did not switch to KDE 4 until KDE 4.5.
I keep seeing people post these kinds of attacks on KDE, yet they are never followed up with any substantial explanation of what the clutter and bloat actually is. I guess compared to GNOME, where having two checkboxes in a single window is considered advanced and confusing, KDE might look "cluttered". Personally, I like being able to actually do things with my computer. Every other OS lets you do that, why shouldn't Linux?
Don't forget QtCurve, which I find to be considerably better than the ugly and garish Oxygen theme.
Short answer: yes. Longer answer: yeah, it's pretty usable, actually seems more polished and complete than KDE 3.5 was. I was a hold-out, too, lest you accuse me of being some KDE 4 fanboi.
It was three and a half years ago. Get over it.
That's what tags are for. As for getting a sense of "how far", a proper version numbering scheme would impart just as much, if not more, information. However, if you still want something like that, you could easily count the commits and append that to your version number. Some projects like to use the SHA1 hash as the tail of the version number. You could combine both easily.
Git submodules and the git subtree add-on take care of a lot of that, actually. You can also do a shallow clone, so you don't get the entire history. I'll admit it's easier in SVN because it's the default (and indeed, only) way to do things.
You can use git show and git archive to spit out individual files or directories of the repo for any previous commit. While it's one slightly extra step, it's pretty flexible and applies not just to branches, but to all commits.
What problem do the revision numbers solve that tags or just using SHA1 ids (including the abbreviated ones) don't?
Then don't commit stuff to a branch you intend to push? Seems pretty straightforward to me...
I store binary data in my Git repos and it doesn't seem to balloon as badly these days as people make it out to be.
In fact, Git seems to be good enough at it that I use it to do application releases. It's faster for me to build an app, commit it to a special Git repo and push the new commit, than to send it via SFTP over the VPN (a few hundred KB vs dozens of MB). In that repo, I have hundreds of new versions, but it's only a few hundred megabytes. The equivalent in file storage would be easily ten times as much.
I don't doubt that other VCSes do better, but Git is not awful.
What's the problem with 150+ repos? What's hard to manage? How is that any harder than managing 150+ separate projects (which you have to do anyway no matter what VCS you use)?
Both SVN and Git can handle only checking in a few changes, although Git has nicer tools built-in for committing only particular changes you've made (git add -p, for example). So I'm not sure what you're talking about in your last sentence.
I use Git on my project which has only one developer (me, of course). I can't imagine working without source control.
He missed one comma and that's an egregious violation of English? Calm the fuck down, dude.
I think you a good point on this one.
Why would homeopathy work for anything? The mechanism is completely bogus. If anyone gets better after a homeopathic treatment, it's entirely placebo or luck (which is actually true of a lot of things -- we tend to naturally get over viruses like the cold and allergies wax and wane, etc.).
Some of the PDP's were 36-bit and I think 18-bit as a half-sized version wasn't uncommon either. This would be back in the 70s and before.
It's pretty snappy for me on Linux.
When was the last time you used an 18-bit application?
In Old English, the past tense of "cuman" was either "com" (with long o) or "cam" (with long a), neither of which would have produced "came". You can consult any book on Old English to find the conjugation of such a common verb. My one Middle English book only gives "com" and "come" as the past tense of that verb, although with no textual citations. So I went and found an online Middle English dictionary and looked up "comen" (http://quod.lib.umich.edu/cgi/m/mec/med-idx?size=First+100&type=headword&q1=comen&rgxp=constrained) and found this: "ME p. sg. cam, com & p. pl. ca:men, ke:me(n are analogical formations, modeled largely on the type of stal, ste:len." (a: and e: are my edits to indicate long a and e, respectively). Note that it lists "com" as the normal past tense. I don't know what the frequency of "cam" vs. "co:m", but my guess is that the former must have eventually become frequent enough to take over for most dialects.
Now on to your second point. It's true that just because one sees the morpheme "come" does not mean the verb necessarily conjugates (not declines) like the base verb "come". However, in the case of "become", we know that it does in fact conjugate the same as the base. In fact, pretty much all verbs that are formed by adding a prefix like be- and for- are conjugated the same as the base verb. You only get a different conjugation when the stem in question is laundered through another part of speech. In the case of "welcome", there is a noun "welcome" and that is the basis for the verb "to welcome", which is thus conjugated like a weak verb (as all verbs derived from nouns are conjugated). The derivation seems to go back to Old English, where the verb was "wilcumian" (http://www.bosworthtoller.com/035723) and thus a weak verb derived from a noun.
Final point: it's entirely possible that it was just a typographic or spelling error. Not knowing whether the writer of the sentence in question is from an area where they speak a dialect that has "come" as the past tense of "come", I cannot say for sure which is the actual case. Either way, it's really just not that big a deal.
It might be the dialectical past tense of "come" which is "come", not "came". "come" as the past tense is more etymologically correct, but the alternate form "came" took over in most places and is now the standard.
I think they want the Perl approach, where every page has seven different ways to do the same thing, even for stuff on other pages.