Even if you were right, that's a failing of the interweb media -- the Wii is kicking ass in the marketplace, showing that people would rather have a fun game than insane eye candy.
And you're not right. The Wii is also a media darling.
Pop quiz, what are the minimum requirements for the most popular PC game ever?
Answer: XP, half a gig of RAM, and a Radeon 7200 or Geforce 2. Oh, and it works on Macs, too.
The definition of "people who spend money on games" is changing. I'd much rather get 50% of a demographic of thousands than 100% of a demographic of hundreds.
Also, they're more likely to pirate games, because the other people have already proven themselves willing to dump quite a bit of cash to play.
Well, hardware can't be pirated. To the pirate, it might be as simple as a choice between a $500 video card or legitimately buying ten games.
MMOs cater to a market that is hardcore in a different way, so they are the exception.
And I suppose Wii Fit is also an exception?
Targeting only the "hardcore" is broken economics.
Git would be inappropriate in situations where you have developers that are either unwilling or incapable of learning how to use the command line and how to manage source control. In that kind of situation...
...you should fire them and hire competent developers.
Not wanting to use the commandline is one thing. It's somewhat understandable, and tools are being developed.
But not wanting to learn how to manage source control? That's as bad as a programmer who doesn't know how to use a text editor, and instead either dictates, or writes code in Word, or writes it by hand and uses OCR...
You think I'm joking, but quite a lot of these stories are about people who didn't want to learn how to use version control (search for "developmestruction"), and at least a couple are about abominations apparently written for programmers who can't or won't use a text editor (and yes, someone actually did write code in Word, using things like font color instead of curly braces).
any time you're in a situation where using physical media is a better option, you've got a broken protocol.
Or you're trying to make it do something it wasn't designed for. Or it actually does need that bandwidth.
Maybe not in the case of Git, but consider what you've just said: If I want to download, say, two or three hours of 1080p video, that's going to take some time. If I'm on dialup, physical media is very likely a real solution, especially if I need more than one.
Having history in EVERY copy that accesses it is like copying an entire relational database to every client that accesses it.
I think this is intrinsic to DVCS -- that is, your metaphor is broken. It is not like a client accessing a relational database.
It is like multimaster replication in a relational database.
That is, in part, why Git is so much easier to work with, when your version history isn't big enough to care about the problem you're having. Working with SVN is very much like using a client to a relational database somewhere -- if that database was running on a floppy drive. It really is that bad, frequently -- I can't remember when I've had an SVN command finish in under a second, usually two or three, sometimes twenty or thirty. I can't remember when I've had a Git command finish in over a second, even "expensive" operations like gc.
Now, you're right, it would be very nice for Git to be able to only pull what it needs. In fact, I'm sure this is what it does on disk -- so, here's a brutal hack, which still won't do everything you asked for, but at least matches SVN: Keep your "local" copy on the server, and mount it via a network-accessible filesystem, like NFS or sshfs. Do the initial clone/branch over ssh, so that you get a hardlink'd copy. And I'm not sure if it's supported, but you should be able to just do it for the.git folder, so that your working copy is local.
That said, both of them are equally brain-dead in the ways in which they're brain dead. But working on source code, in a textual format, I tend to run into SVN's limitations on a daily basis -- in fact, I'd be lucky if an hour went by when I wasn't fighting with it. At least, that's how it used to be. Now, with Git, I tend to run into your particular limitation... never.
If I don't/want/ 12GB of history for images I'm not using (even if someone else might), I should not have that data at all.
Which is why it's not great for binary data.
There are specific reasons why the complete version history is needed -- technical reasons. I'm guessing that the minimum penalty will be, you can't merge with anyone who's made changes against history you don't have.
git solves this problem by simply not caring about the ramifications
No, it solves this problem by making you deal directly with the ramifications.
Specifically, if you want something actually removed from the history, all commits after that point will have to be changed -- they'll have a different SHA -- which will make life hell for anyone who doesn't make the exact same change to their repository.
In other words, if you want something purged from history, the cleanest way I can think of is to tell everyone to run a certain set of commands, with the exact same arguments in the exact same way -- or force everyone to re-clone, which means potentially pulling down that 12 gigs of history again.
The Canada I live in has a levy on blank CDs, just like the USA. [neil.eton.ca] However none of the money goes to the RIAA or MPAA - it goes to the CPCC (Canadian Private Copying Collective)
Yes, like the USA, Canada likes to tax things. Unlike the USA, they've taken that tax on blank media and distributed it to something called the CPCC. From their propaganda,
The CPCC distributes the money to its four member collectives which claim royalties for their members. The member collectives are then responsible for distributing the money to rights holders. To date over 97,000 rights holders have received private copying royalties.
In other words, a lot of people! But we're not going to say who.
I've looked at the distribution FAQ -- it's a list of other organizations that they distribute to. No mention of what an artist would actually have to do to get themselves paid.
I don't see where the money in the US goes, but I'm guessing it's not a specific tax on piracy, to be sent to artists. Certainly no indemnity of any kind for copying.
In other words, suppose we had a system like Magnatune -- 50% goes to Magnatune, 50% to the artist. Only now, if I download a song from there and burn a CD (in Canada), I'm also paying a few more cents to a bunch of artists, most of which probably have nothing to do with Magnatune, or the album I actually paid for.
Not all developers. In fact, historically, there's the classic Carmack attack on DirectX. There was certainly a period of time for which OpenGL was faster.
Apple 3D Card selection have been historically pretty worthless. Linux is infamous for its 3D Card support.
Neither of which matters -- if your game only runs on the very latest, $500 worth of SLI goodness, with more RAM on the video card than a computer had two years ago, you're targeting a much smaller audience than Linux or OS X users.
Your pipeline should be able to scale, both up and down, especially if you intend to use that engine for other games in the future. And, looking up, this is another point in favor of OpenGL -- DirectX 10 currently runs on exactly one platform (Vista), which is perhaps the most universally hated platform since Windows ME, maybe even Microsoft Bob. Even if you're only going to be targeting older versions of Windows, with OpenGL, it's up to the manufacturers, and they tend to keep at least 2K and XP up to date with GL support.
The other funny part of this is that Linux video support actually has more working than OS X, as far as I can tell -- SLI on nvidia, for example.
So not only do developers need an openGL renderer but they also have to develop for a less refined driver base.
Once they've got an OpenGL renderer, I'll argue that they don't need a DirectX one. And you need a less refined driver base anyway, unless you force everyone to upgrade to Vista + SLI/Crossfire + OMGULTRABBQ 3000 PCI-EXPRESS.
The people who hold the money in gaming are all about avoiding risk by stampeding to the same place as everyone else.
Except in 2008, apparently. We got Mirror's Edge, Spore, and Dead Space, all from EA.
And don't forget, Portal came from Valve. Shows how if you really want to test an idea without too much risk, build a smaller game and use digital distribution.
The problem here is, it also translates into a culture of shareware. Things which are freeware on Windows, and open source everywhere else, are shareware on a Mac.
Maybe it's just me, but that's what I've seen. You could argue that it's because the Mac version is so different, unique, and so much better than the free alternatives that it deserves to be paid for. I think it's because of exactly what you've said -- someone who just paid $1k for a dev machine is unlikely to gripe about $50 for TextMate.
(I'm lazy, so those numbers are almost certainly wrong, but they're close to right.)
As a user, that is one thing I really hate about the Mac. It's not that I don't believe in paying for software, just that I don't think every little file management tool or MP3 player needs to ask $20. Put up a donation page and be grateful someone hasn't replaced you already.
But hey, if you're going for that angle, target Mac users because they spend more money and are grateful for any decent games, and target Linux users because they might buy one just to up the Linux stats.
You mean the same Canada that taxes anything even vaguely related to music or movies -- including blank media and concert halls -- and sends that tax money straight to the RIAA/MPAA?
We're kind of running out of "enlightened" countries to run to. We need to make a stand and fix things, here and now.
Kwin alone is so improved, so much faster, so much more feature-rich, that I'd be using KDE 4 if that were the only improvement.
And yet, I believe Compiz can do everything Kwin can. Why am I using KDE again?
Plasma is a giant leap forward into the future of the desktop metaphor.
Pure marketspeak.
It's light-years beyond anything anyone else is doing,
Unless you count Vista or the OS X Dashboard.
and already more functional than kicker and kdesktop were.
Just a simple example: With KDE 3, I could right-click on the panel, go to "properties", and I would have a nice dropdown to choose the panel size. I also have a nice slider to choose translucency of the background, and I can make it go 100% transparent, while the foreground (widgets and all) are entirely opaque.
Koffice 2, bugs, weird layout and all, is the only place where any innovation is happening in office suites at all, anywhere by anyone.
Can't speak to that, as it's not in Intrepid. If it was recently released, I guess I'll wait for 2.1 -- no, make that 2.2 -- maybe by then it'll be functional, if the rest of the desktop is any indication.
On a more general level, the whole desktop just feels faster than KDE 3 ever was on this hardware.
In some ways, it does feel faster, yes. In other ways, much slower.
One example: Alt+F2. While Katapult was weird, I never had the problem where if I type "kons<enter>" it would open konqueror, because "kon" completed to Konqueror, and it hadn't finished the last search by the time I hit "enter".
That's not just inconvenient, but actually broken -- it's doing the wrong thing because of its slowness, not just the right thing, slower.
Yeah, there's problems. Some fairly glaring ones, still, that frustrate the hell out of me every day. But the pros are totally worth it.
See, that's what's generally referred to as a beta -- it's got some really awesome new features, but it hasn't stablized yet.
And again, it's reminiscent of Vista -- with Microsoft spouting the same hyperbole about how much more advanced it was, with fanboys talking about it being faster, and yet, at the end of the day, it's huge, bloated, buggy, and annoying.
The difference is, at least you have the option of going back to XP, which is supported, and still gets bugfixes. With KDE, you either get bleeding-edge or obsolete.
And for cryin' out loud, somebody's got to take some risks here. Somebody's got to try to move forward even if hurts a little bit.
Moving forward doesn't have to hurt, not even a little bit.
Look, it's not the metaphor-changing that bothers me. It's the shit that doesn't work, it's the shit that isn't obvious when a fucking tooltip -- an almost 15-year-old invention -- would have cleared things up. It's the functionality that's dropped on the floor because it was keeping you from making a release -- as another poster points out, how the fuck does an audio player release a 2.0 which doesn't have a fucking pause button that works?
It's the audacity to call an alpha a dot-oh release, and a beta a dot-one release -- and then trying to blame everyone but yourselves when we expect a sane, smooth upgrade.
Look at other successful projects. Firefox 3 was usable at launch, and Firefox 2 kept getting patches for six months after launch, whereas KDE4 (and associated projects, like Amarok) dropped support before the new version was even released, even in dot-oh status.
At the end of the day, what you're doing is making a very interesting platform for people who like to experiment, which also absolutely sucks for anyone who just wants things to work, who just wants to get things done. The sad thing is, those aren't even mutually exclusive, as Firefox shows.
I've used Fluxbox, so yes, I realize that. But until kde4, I could honestly recommend people just pick up Kubuntu. Now, it's back to "Well, there are tradeoffs..."
I'm guessing I would have to at least be using kwin, by now.
Regardless, we shouldn't be having this discussion. KDE should not be that broken.
I'm also still waiting for perl5 to be written for parrot.
Ponie is written. I'm guessing it's not complete.
A similar problem is that although I can write things for Perl6 (pugs or parrot) I cannot expect other people to have pugs or parrot in their distro, and thus be able to use them.
Coming from Perl, that is a problem. But that's also true of Ruby, and until recently, Python. As it is, parrot is available in Ubuntu, and you don't need pugs to run a bitecode-compiled Parrot app -- I believe pugs can compile it, though. And I don't see that as a huge problem -- after all, if you were writing a Perl5 app, and doing it right, you would be relying on tons of CPAN modules too.
The development is still decentralized. And Github makes it that much easier to handle the social aspects -- it's like a social network of software development.
Aside from that, it's not really centralized. In a social sense, it's one click on Github to fork it, or you can manually fork it and push it to another service. In a technical sense, everyone's checkout is also a full repository/backup, so if Github ever implodes, there will likely be at least one backup for every active project on there.
Don't get me wrong, I plan to roll my own anyway. But even then, I see no reason not to also mirror it on Github, since it's so trivial to maintain multiple repositories.
The main things I like about git are its raw speed, its ubiquity (everyone and their dog has a git tutorial), and how simple its primitives are.
That is: I actually started with bzr, and I found that while there were some things that were much easier (bzr uncommit comes to mind), it's a lot easier to actually understand Git under the hood, in case I need to do some deep surgery on some history, say.
Then, too, there just seem to be more tools available -- gitk, git-cherry-pick, even git-stash, are things I don't remember from bzr or hg, but it's been awhile.
I see the point about Python, and I'm absolutely with you there. The reason it's not an issue is, I can't ever remember having to dig into Git source -- the most I might have to do is write a shell-script frontend to some of the tools already there. It's actually somewhat UNIX-y that way -- when was the last time you had to dig into the source of fileutils?
What's more, there are language bindings -- personally, I've used grit in Ruby. Easier than trying to talk to SVN with its XML output.
The main advantage of bzr, by the way, is its handling of directories -- it actually records renames. Git tries to detect them, but it works at the level of file contents, not directory structure -- so, for example, it'll detect if you move a function from one file to another, but it might have trouble if you rename a directory. For example:
mv a b mkdir a
And, in another branch:
touch a/c
When they merge, where should c go? Git would probably put it in a, since the file's name is 'a/c'. Bzr would probably put it in b, since a was renamed to b, unless the same rename somehow made it into that other branch.
There is another reason I didn't mention -- I use Ruby. I believe Ruby itself is done on SVN, but it seems that every Ruby project ever has moved from SVN to Git, and most of them to Github. And it's just awesome to work with Github projects.
Only if you actually *want* the whole project. If on the other side you just want a single file or subdirectory, say in a large gigabyte size repo with graphics, textures and stuff, you have kind of a problem with git.
Yes, Git really isn't great for large, binary data.
Other than that, if you're really only wanting a subdirectory of a project most of the time, maybe it's a good idea to split that subdirectory out into its own project?
But I was just pointing out how ridiculous it is that in repositories full of text, an SVN checkout -- which barely contains any metadata at all, or at least, insists on going to the server for just about anything -- can be as big or bigger than a Git checkout, which contains every version, ever. And even that initial git-clone is likely to be faster, if you have the bandwidth for it -- there seem to be far fewer blocking roundtrips, and far less CPU needed.
The other point of note is that Git seems to have a much lighter, faster wire protocol than SVN. So, if it gets really bad, and your bandwidth really makes it that impractical to do the initial checkout, it might be a valid option to find someone who has a full checkout and have them burn you a DVD. After that, it's going to be less bandwidth to stay up to date, and certainly less to work offline.
Other posters have gotten the main ones, but a few points you may have missed:
First, yes, you can use it in a centralized manner. It does that much better than Subversion does. For a taste, use git-svn -- crippled, but in many ways better than vanilla subversion.
To address your actual concerns, though:
I'm reluctant to have repositories sprouting like mushrooms everywhere and everybody having their own little "trunk,"
The fact that everyone has their own "repository" as a working copy doesn't mean there have to be "repositories sprouting like mushrooms". You can do that, and it works well -- see Github -- or you can just have one "canonical" repo that everyone pushes to, or both.
Or you can have other models -- I believe Linux is hierarchical, such that various subsystems each have their own maintainers, with their own subsystem-specific repository. Some large patches, like suspend2 or the Ubuntu patches, certainly maintain their own repositories. But it's actually quite easy to send relevant changes back up the chain -- Linus can pull from whichever of those he wants, and apply them to the official tree.
In fact, that's something much more difficult to do on Subversion -- having only one person with commit access would be stifling. On the other hand, with Git, commit access can be based on trust, not on productivity.
Just as an example: When I want to make a non-trivial change to a project on Github, I just fork it. Then, when I'm satisfied with my changes, I send a pull-request back. There's no question as to which is the "official" version -- on the other hand, if my change really is a good idea, and they refuse to merge, maybe I'll just keep developing on my own, merging in their changes, and before long people are seeing me as the "official" version.
and developers arguing who should have to merge with whom before each release.
But the problem of which version is official, and who needs to merge with whom, is a social, not a technical problem. You have the exact same problems with SVN, if you use it properly -- we tried this for a bit, with everyone working on their own branch. Merging was impossible, even though there was a "real" trunk. (Or, I should say: It was possible, but expect to wait a half hour or more for SVN 1.5 to figure it out -- or expect to spend a half hour or more of your own time giving SVN 1.4 the right revision ranges.)
Then we started using git-svn, everyone working off trunk, and keeping their own private Git branches locally. This way, merging was trivial, because Git is awesome at merging. The downside is, local Git commits get turned into git-svn commits when you send them to SVN, which changes the sha, which makes it that much harder to merge any other local branches you might have -- it was definitely an upgrade to start some new projects on pure Git.
And is no longer maintained, to the point where big, obvious, probably easy-to-fix bugs are ignored, because it's in 3.5, not 4.x.
Either one is going to give me showstopper bugs.
in 4.1 is was rather "hidden": there's a little strip at the top of the panel controller (right click on the panel -> Panel Settings, or click the toolbox button on the far right of the panel) that you can click and drag on.
Thanks, someone else just pointed that out to me.
I've also noticed how when I do this, it breaks the clock applet more than it was before.
the fake translucency in kicker was an insane hack (trust me, i did the bulk of the coding to get it to work;) and it of course wasn't perfect: it only showed your wallpaper, not windows and heaven forbid if the wallpaper was animated or anything like that.
Yes, I understand that. It would be nice if the real translucency/transparency at least provided the same features, though.
I said "adjust" its translucency, not "make it translucent by whatever the theme designer wants it to be."
use a completely transparent SVG. =)
Great, thanks. You realize in 3.5, this was a slider control. I should not have to build a fucking SVG to get basic functionality back.
i do hope you've filed a feature request on bugs.kde.org.
What, "Please support everything Amarok 1 did"? This seems kind of obvious. Maybe I should post it just so they realize there are people with iPods who have files other than mp3s to put on them.
No, I'm done. I'll keep using kde4 until I find something better -- at which point, I hope to be done with KDE.
oh, and if you're tempted to say "they should have just held 2.0 until January, then", don't bother: making releases from the code repository is an absolutely requirement to keep open source projects moving
Yes, that's why we call them "release candidates", or "betas", and most importantly, don't break the old one while you're working on the new one.
that's why there is another step in row, e.g. distributions. not that they seem to always be doing their users the best favours lately in that regard. *shrug*
True, plenty of blame to pass around, but this sounds a bit like passing the buck. KDE screwed up, in many spectacular ways. There is currently no consumer-grade version of KDE. But of course, let's blame the distros for not holding back to a sufficiently old version of 3 so as to keep things working until 4 is really ready.
Not that they are blameless -- I place the blame for my current lack of Bluetooth squarely on Kubuntu's shoulders. But when most open source projects make a dot-oh release, it's ready for general consumption. Firefox was.
Slashdot Mirror
Even if you were right, that's a failing of the interweb media -- the Wii is kicking ass in the marketplace, showing that people would rather have a fun game than insane eye candy.
And you're not right. The Wii is also a media darling.
No DirectX means no Xbox 360.
True. But OpenGL means PS3 and Wii ports almost for free. And the Wii still has the largest marketshare.
Those are the people who spend money on games.
Yes, all five of them.
Pop quiz, what are the minimum requirements for the most popular PC game ever?
Answer: XP, half a gig of RAM, and a Radeon 7200 or Geforce 2. Oh, and it works on Macs, too.
The definition of "people who spend money on games" is changing. I'd much rather get 50% of a demographic of thousands than 100% of a demographic of hundreds.
Also, they're more likely to pirate games, because the other people have already proven themselves willing to dump quite a bit of cash to play.
Well, hardware can't be pirated. To the pirate, it might be as simple as a choice between a $500 video card or legitimately buying ten games.
MMOs cater to a market that is hardcore in a different way, so they are the exception.
And I suppose Wii Fit is also an exception?
Targeting only the "hardcore" is broken economics.
Ok, that's a cool little video clip... Notice how the ad in front of it was longer than the clip itself, though?
OMGWTFBBC?
Git would be inappropriate in situations where you have developers that are either unwilling or incapable of learning how to use the command line and how to manage source control. In that kind of situation...
...you should fire them and hire competent developers.
Not wanting to use the commandline is one thing. It's somewhat understandable, and tools are being developed.
But not wanting to learn how to manage source control? That's as bad as a programmer who doesn't know how to use a text editor, and instead either dictates, or writes code in Word, or writes it by hand and uses OCR...
You think I'm joking, but quite a lot of these stories are about people who didn't want to learn how to use version control (search for "developmestruction"), and at least a couple are about abominations apparently written for programmers who can't or won't use a text editor (and yes, someone actually did write code in Word, using things like font color instead of curly braces).
Also, for what it's worth:
any time you're in a situation where using physical media is a better option, you've got a broken protocol.
Or you're trying to make it do something it wasn't designed for. Or it actually does need that bandwidth.
Maybe not in the case of Git, but consider what you've just said: If I want to download, say, two or three hours of 1080p video, that's going to take some time. If I'm on dialup, physical media is very likely a real solution, especially if I need more than one.
Having history in EVERY copy that accesses it is like copying an entire relational database to every client that accesses it.
I think this is intrinsic to DVCS -- that is, your metaphor is broken. It is not like a client accessing a relational database.
It is like multimaster replication in a relational database.
That is, in part, why Git is so much easier to work with, when your version history isn't big enough to care about the problem you're having. Working with SVN is very much like using a client to a relational database somewhere -- if that database was running on a floppy drive. It really is that bad, frequently -- I can't remember when I've had an SVN command finish in under a second, usually two or three, sometimes twenty or thirty. I can't remember when I've had a Git command finish in over a second, even "expensive" operations like gc.
Now, you're right, it would be very nice for Git to be able to only pull what it needs. In fact, I'm sure this is what it does on disk -- so, here's a brutal hack, which still won't do everything you asked for, but at least matches SVN: Keep your "local" copy on the server, and mount it via a network-accessible filesystem, like NFS or sshfs. Do the initial clone/branch over ssh, so that you get a hardlink'd copy. And I'm not sure if it's supported, but you should be able to just do it for the .git folder, so that your working copy is local.
That said, both of them are equally brain-dead in the ways in which they're brain dead. But working on source code, in a textual format, I tend to run into SVN's limitations on a daily basis -- in fact, I'd be lucky if an hour went by when I wasn't fighting with it. At least, that's how it used to be. Now, with Git, I tend to run into your particular limitation... never.
If I don't /want/ 12GB of history for images I'm not using (even if someone else might), I should not have that data at all.
Which is why it's not great for binary data.
There are specific reasons why the complete version history is needed -- technical reasons. I'm guessing that the minimum penalty will be, you can't merge with anyone who's made changes against history you don't have.
git solves this problem by simply not caring about the ramifications
No, it solves this problem by making you deal directly with the ramifications.
Specifically, if you want something actually removed from the history, all commits after that point will have to be changed -- they'll have a different SHA -- which will make life hell for anyone who doesn't make the exact same change to their repository.
In other words, if you want something purged from history, the cleanest way I can think of is to tell everyone to run a certain set of commands, with the exact same arguments in the exact same way -- or force everyone to re-clone, which means potentially pulling down that 12 gigs of history again.
Quite a lot of them, actually, for the specific thing you're wanting to do right now.
In fact, the official Git book isn't bad, either.
Most of my work is in spaces where enterprise distributions are much more likely to be present.
So distribute Perl with them.
Google has been learning that lesson the hard way with their Goobuntu project
Citation needed. First few Google results indicate just a rumor, which is probably a hoax.
If the module does use XS, but you can use a version a year or 2 old you can instruct the user how to install the relevant RPMs.
And if you can't?
Any of these solutions requires a stable implementation to rely on.
True. But I wouldn't use "included in RHEL" as a gauge of "stable".
The Canada I live in has a levy on blank CDs, just like the USA. [neil.eton.ca] However none of the money goes to the RIAA or MPAA - it goes to the CPCC (Canadian Private Copying Collective)
Yes, like the USA, Canada likes to tax things. Unlike the USA, they've taken that tax on blank media and distributed it to something called the CPCC. From their propaganda,
The CPCC distributes the money to its four member collectives which claim royalties for their members. The member collectives are then responsible for distributing the money to rights holders. To date over 97,000 rights holders have received private copying royalties.
In other words, a lot of people! But we're not going to say who.
I've looked at the distribution FAQ -- it's a list of other organizations that they distribute to. No mention of what an artist would actually have to do to get themselves paid.
I don't see where the money in the US goes, but I'm guessing it's not a specific tax on piracy, to be sent to artists. Certainly no indemnity of any kind for copying.
In other words, suppose we had a system like Magnatune -- 50% goes to Magnatune, 50% to the artist. Only now, if I download a song from there and burn a CD (in Canada), I'm also paying a few more cents to a bunch of artists, most of which probably have nothing to do with Magnatune, or the album I actually paid for.
True.
Probably in front of witnesses, who they presumably did not smash up. And you've got the tape itself, which has clearly been smashed.
And, especially, if you've got a photo ahead of time, there's a good chance they don't know how to smash it -- the memory card is probably fine.
Developers like DirectX.
Not all developers. In fact, historically, there's the classic Carmack attack on DirectX. There was certainly a period of time for which OpenGL was faster.
Apple 3D Card selection have been historically pretty worthless. Linux is infamous for its 3D Card support.
Neither of which matters -- if your game only runs on the very latest, $500 worth of SLI goodness, with more RAM on the video card than a computer had two years ago, you're targeting a much smaller audience than Linux or OS X users.
Your pipeline should be able to scale, both up and down, especially if you intend to use that engine for other games in the future. And, looking up, this is another point in favor of OpenGL -- DirectX 10 currently runs on exactly one platform (Vista), which is perhaps the most universally hated platform since Windows ME, maybe even Microsoft Bob. Even if you're only going to be targeting older versions of Windows, with OpenGL, it's up to the manufacturers, and they tend to keep at least 2K and XP up to date with GL support.
The other funny part of this is that Linux video support actually has more working than OS X, as far as I can tell -- SLI on nvidia, for example.
So not only do developers need an openGL renderer but they also have to develop for a less refined driver base.
Once they've got an OpenGL renderer, I'll argue that they don't need a DirectX one. And you need a less refined driver base anyway, unless you force everyone to upgrade to Vista + SLI/Crossfire + OMGULTRABBQ 3000 PCI-EXPRESS.
The people who hold the money in gaming are all about avoiding risk by stampeding to the same place as everyone else.
Except in 2008, apparently. We got Mirror's Edge, Spore, and Dead Space, all from EA.
And don't forget, Portal came from Valve. Shows how if you really want to test an idea without too much risk, build a smaller game and use digital distribution.
The problem here is, it also translates into a culture of shareware. Things which are freeware on Windows, and open source everywhere else, are shareware on a Mac.
Maybe it's just me, but that's what I've seen. You could argue that it's because the Mac version is so different, unique, and so much better than the free alternatives that it deserves to be paid for. I think it's because of exactly what you've said -- someone who just paid $1k for a dev machine is unlikely to gripe about $50 for TextMate.
(I'm lazy, so those numbers are almost certainly wrong, but they're close to right.)
As a user, that is one thing I really hate about the Mac. It's not that I don't believe in paying for software, just that I don't think every little file management tool or MP3 player needs to ask $20. Put up a donation page and be grateful someone hasn't replaced you already.
But hey, if you're going for that angle, target Mac users because they spend more money and are grateful for any decent games, and target Linux users because they might buy one just to up the Linux stats.
Then sue them for the price of the camera, plus some obscure police brutality charge, plus a good measure of emotional distress.
You mean the same Canada that taxes anything even vaguely related to music or movies -- including blank media and concert halls -- and sends that tax money straight to the RIAA/MPAA?
We're kind of running out of "enlightened" countries to run to. We need to make a stand and fix things, here and now.
Kwin alone is so improved, so much faster, so much more feature-rich, that I'd be using KDE 4 if that were the only improvement.
And yet, I believe Compiz can do everything Kwin can. Why am I using KDE again?
Plasma is a giant leap forward into the future of the desktop metaphor.
Pure marketspeak.
It's light-years beyond anything anyone else is doing,
Unless you count Vista or the OS X Dashboard.
and already more functional than kicker and kdesktop were.
Just a simple example: With KDE 3, I could right-click on the panel, go to "properties", and I would have a nice dropdown to choose the panel size. I also have a nice slider to choose translucency of the background, and I can make it go 100% transparent, while the foreground (widgets and all) are entirely opaque.
Koffice 2, bugs, weird layout and all, is the only place where any innovation is happening in office suites at all, anywhere by anyone.
Can't speak to that, as it's not in Intrepid. If it was recently released, I guess I'll wait for 2.1 -- no, make that 2.2 -- maybe by then it'll be functional, if the rest of the desktop is any indication.
On a more general level, the whole desktop just feels faster than KDE 3 ever was on this hardware.
In some ways, it does feel faster, yes. In other ways, much slower.
One example: Alt+F2. While Katapult was weird, I never had the problem where if I type "kons<enter>" it would open konqueror, because "kon" completed to Konqueror, and it hadn't finished the last search by the time I hit "enter".
That's not just inconvenient, but actually broken -- it's doing the wrong thing because of its slowness, not just the right thing, slower.
Yeah, there's problems. Some fairly glaring ones, still, that frustrate the hell out of me every day. But the pros are totally worth it.
See, that's what's generally referred to as a beta -- it's got some really awesome new features, but it hasn't stablized yet.
And again, it's reminiscent of Vista -- with Microsoft spouting the same hyperbole about how much more advanced it was, with fanboys talking about it being faster, and yet, at the end of the day, it's huge, bloated, buggy, and annoying.
The difference is, at least you have the option of going back to XP, which is supported, and still gets bugfixes. With KDE, you either get bleeding-edge or obsolete.
And for cryin' out loud, somebody's got to take some risks here. Somebody's got to try to move forward even if hurts a little bit.
Moving forward doesn't have to hurt, not even a little bit.
Look, it's not the metaphor-changing that bothers me. It's the shit that doesn't work, it's the shit that isn't obvious when a fucking tooltip -- an almost 15-year-old invention -- would have cleared things up. It's the functionality that's dropped on the floor because it was keeping you from making a release -- as another poster points out, how the fuck does an audio player release a 2.0 which doesn't have a fucking pause button that works?
It's the audacity to call an alpha a dot-oh release, and a beta a dot-one release -- and then trying to blame everyone but yourselves when we expect a sane, smooth upgrade.
Look at other successful projects. Firefox 3 was usable at launch, and Firefox 2 kept getting patches for six months after launch, whereas KDE4 (and associated projects, like Amarok) dropped support before the new version was even released, even in dot-oh status.
At the end of the day, what you're doing is making a very interesting platform for people who like to experiment, which also absolutely sucks for anyone who just wants things to work, who just wants to get things done. The sad thing is, those aren't even mutually exclusive, as Firefox shows.
I've used Fluxbox, so yes, I realize that. But until kde4, I could honestly recommend people just pick up Kubuntu. Now, it's back to "Well, there are tradeoffs..."
I'm guessing I would have to at least be using kwin, by now.
Regardless, we shouldn't be having this discussion. KDE should not be that broken.
I'm also still waiting for perl5 to be written for parrot.
Ponie is written. I'm guessing it's not complete.
A similar problem is that although I can write things for Perl6 (pugs or parrot) I cannot expect other people to have pugs or parrot in their distro, and thus be able to use them.
Coming from Perl, that is a problem. But that's also true of Ruby, and until recently, Python. As it is, parrot is available in Ubuntu, and you don't need pugs to run a bitecode-compiled Parrot app -- I believe pugs can compile it, though. And I don't see that as a huge problem -- after all, if you were writing a Perl5 app, and doing it right, you would be relying on tons of CPAN modules too.
The development is still decentralized. And Github makes it that much easier to handle the social aspects -- it's like a social network of software development.
Aside from that, it's not really centralized. In a social sense, it's one click on Github to fork it, or you can manually fork it and push it to another service. In a technical sense, everyone's checkout is also a full repository/backup, so if Github ever implodes, there will likely be at least one backup for every active project on there.
Don't get me wrong, I plan to roll my own anyway. But even then, I see no reason not to also mirror it on Github, since it's so trivial to maintain multiple repositories.
The main things I like about git are its raw speed, its ubiquity (everyone and their dog has a git tutorial), and how simple its primitives are.
That is: I actually started with bzr, and I found that while there were some things that were much easier (bzr uncommit comes to mind), it's a lot easier to actually understand Git under the hood, in case I need to do some deep surgery on some history, say.
Then, too, there just seem to be more tools available -- gitk, git-cherry-pick, even git-stash, are things I don't remember from bzr or hg, but it's been awhile.
I see the point about Python, and I'm absolutely with you there. The reason it's not an issue is, I can't ever remember having to dig into Git source -- the most I might have to do is write a shell-script frontend to some of the tools already there. It's actually somewhat UNIX-y that way -- when was the last time you had to dig into the source of fileutils?
What's more, there are language bindings -- personally, I've used grit in Ruby. Easier than trying to talk to SVN with its XML output.
The main advantage of bzr, by the way, is its handling of directories -- it actually records renames. Git tries to detect them, but it works at the level of file contents, not directory structure -- so, for example, it'll detect if you move a function from one file to another, but it might have trouble if you rename a directory. For example:
mv a b
mkdir a
And, in another branch:
touch a/c
When they merge, where should c go? Git would probably put it in a, since the file's name is 'a/c'. Bzr would probably put it in b, since a was renamed to b, unless the same rename somehow made it into that other branch.
There is another reason I didn't mention -- I use Ruby. I believe Ruby itself is done on SVN, but it seems that every Ruby project ever has moved from SVN to Git, and most of them to Github. And it's just awesome to work with Github projects.
Only if you actually *want* the whole project. If on the other side you just want a single file or subdirectory, say in a large gigabyte size repo with graphics, textures and stuff, you have kind of a problem with git.
Yes, Git really isn't great for large, binary data.
Other than that, if you're really only wanting a subdirectory of a project most of the time, maybe it's a good idea to split that subdirectory out into its own project?
But I was just pointing out how ridiculous it is that in repositories full of text, an SVN checkout -- which barely contains any metadata at all, or at least, insists on going to the server for just about anything -- can be as big or bigger than a Git checkout, which contains every version, ever. And even that initial git-clone is likely to be faster, if you have the bandwidth for it -- there seem to be far fewer blocking roundtrips, and far less CPU needed.
The other point of note is that Git seems to have a much lighter, faster wire protocol than SVN. So, if it gets really bad, and your bandwidth really makes it that impractical to do the initial checkout, it might be a valid option to find someone who has a full checkout and have them burn you a DVD. After that, it's going to be less bandwidth to stay up to date, and certainly less to work offline.
Other posters have gotten the main ones, but a few points you may have missed:
First, yes, you can use it in a centralized manner. It does that much better than Subversion does. For a taste, use git-svn -- crippled, but in many ways better than vanilla subversion.
To address your actual concerns, though:
I'm reluctant to have repositories sprouting like mushrooms everywhere and everybody having their own little "trunk,"
The fact that everyone has their own "repository" as a working copy doesn't mean there have to be "repositories sprouting like mushrooms". You can do that, and it works well -- see Github -- or you can just have one "canonical" repo that everyone pushes to, or both.
Or you can have other models -- I believe Linux is hierarchical, such that various subsystems each have their own maintainers, with their own subsystem-specific repository. Some large patches, like suspend2 or the Ubuntu patches, certainly maintain their own repositories. But it's actually quite easy to send relevant changes back up the chain -- Linus can pull from whichever of those he wants, and apply them to the official tree.
In fact, that's something much more difficult to do on Subversion -- having only one person with commit access would be stifling. On the other hand, with Git, commit access can be based on trust, not on productivity.
Just as an example: When I want to make a non-trivial change to a project on Github, I just fork it. Then, when I'm satisfied with my changes, I send a pull-request back. There's no question as to which is the "official" version -- on the other hand, if my change really is a good idea, and they refuse to merge, maybe I'll just keep developing on my own, merging in their changes, and before long people are seeing me as the "official" version.
and developers arguing who should have to merge with whom before each release.
But the problem of which version is official, and who needs to merge with whom, is a social, not a technical problem. You have the exact same problems with SVN, if you use it properly -- we tried this for a bit, with everyone working on their own branch. Merging was impossible, even though there was a "real" trunk. (Or, I should say: It was possible, but expect to wait a half hour or more for SVN 1.5 to figure it out -- or expect to spend a half hour or more of your own time giving SVN 1.4 the right revision ranges.)
Then we started using git-svn, everyone working off trunk, and keeping their own private Git branches locally. This way, merging was trivial, because Git is awesome at merging. The downside is, local Git commits get turned into git-svn commits when you send them to SVN, which changes the sha, which makes it that much harder to merge any other local branches you might have -- it was definitely an upgrade to start some new projects on pure Git.
3.5 is still out there and used by millions.
And is no longer maintained, to the point where big, obvious, probably easy-to-fix bugs are ignored, because it's in 3.5, not 4.x.
Either one is going to give me showstopper bugs.
in 4.1 is was rather "hidden": there's a little strip at the top of the panel controller (right click on the panel -> Panel Settings, or click the toolbox button on the far right of the panel) that you can click and drag on.
Thanks, someone else just pointed that out to me.
I've also noticed how when I do this, it breaks the clock applet more than it was before.
the fake translucency in kicker was an insane hack (trust me, i did the bulk of the coding to get it to work ;) and it of course wasn't perfect: it only showed your wallpaper, not windows and heaven forbid if the wallpaper was animated or anything like that.
Yes, I understand that. It would be nice if the real translucency/transparency at least provided the same features, though.
I said "adjust" its translucency, not "make it translucent by whatever the theme designer wants it to be."
use a completely transparent SVG. =)
Great, thanks. You realize in 3.5, this was a slider control. I should not have to build a fucking SVG to get basic functionality back.
i do hope you've filed a feature request on bugs.kde.org.
What, "Please support everything Amarok 1 did"? This seems kind of obvious. Maybe I should post it just so they realize there are people with iPods who have files other than mp3s to put on them.
No, I'm done. I'll keep using kde4 until I find something better -- at which point, I hope to be done with KDE.
oh, and if you're tempted to say "they should have just held 2.0 until January, then", don't bother: making releases from the code repository is an absolutely requirement to keep open source projects moving
Yes, that's why we call them "release candidates", or "betas", and most importantly, don't break the old one while you're working on the new one.
that's why there is another step in row, e.g. distributions. not that they seem to always be doing their users the best favours lately in that regard. *shrug*
True, plenty of blame to pass around, but this sounds a bit like passing the buck. KDE screwed up, in many spectacular ways. There is currently no consumer-grade version of KDE. But of course, let's blame the distros for not holding back to a sufficiently old version of 3 so as to keep things working until 4 is really ready.
Not that they are blameless -- I place the blame for my current lack of Bluetooth squarely on Kubuntu's shoulders. But when most open source projects make a dot-oh release, it's ready for general consumption. Firefox was.