I hardly think its fair to blame Apple for your klunky workaround when you didn't meet their minimum specs to begin with.
Yeah, what's "klunky" about my workaround?
And all of this would be trivially solved by putting a team on it for a couple of weeks and building a web interface. My less-than-a-year-old OS (Linux) doesn't run iTunes either, and it shouldn't have to.
Which kind of proves my point - look at the awful user interface on Magnatune.
You mean the one that makes it easy to search, sort, and put those songs in a playlist before they're purchased?
What the hell are you talking about? You youself said that you can use Magnatune and Amazon and others.
Except with the iTunes store.
And saying "If you don't like it, go somewhere else" is well within your rights (and Apple's), but it's still a dick move. Kind of like private clubs, some of which don't allow certain religions or skin colors, some of which don't allow women -- maybe legal, but not great.
What the hell? When did I mention IE, and what does this have to do with anything?
It's called a metaphor, dipshit. "If you don't like the fact that this site requires IE, go somewhere else. No one's forcing you to go here." And yet, we still consider it a best practice to design cross-platform sites, and we still get annoyed when we come across a broken site.
Whoops, correction: LTS is 3 years on the desktop, 5 years on the server.
It looks as though LTS releases are every 2 years, predictably. Which means that for a server product, you can skip a release, then wait a year after release of the next one before you have to switch.
Headers are easily available. Compile it locally, copy it back. Not much more than a speed bump -- and an irritating one for legitimate users, too.
And yes, Ubuntu doesn't change more often than 6 months, but I don't want to have to chase bugs during the entire 6 month cycle either (or get blind-sided when the next release comes out and my app breaks).
That's what LTS is for -- stable for 3 years.
In practice, it hasn't been a problem for server deployments, though Kubuntu's handling of KDE4 does not inspire confidence.
But many people prefer to use iTunes. The browsing and purchasing experience is much nicer than web browser based stores.
Design the browser based store properly, or at least provide an open API, and you can do the same elsewhere.
Exhibit A: Magnatune support directly in Amarok.
Do you have some sort of problem with people having different preferences than yourself?
When only their preferences are supported, yes, it's a problem.
Yeah, use IE if you really want to, so long as your site is designed to some reasonable approximation of standards, so I don't have to. If you slap on a "best viewed in IE6" disclaimer and ignore Firefox, well, 1995 called...
Point is, if they'd stuck to open standards, it wouldn't matter -- they wouldn't have to do any work to support older OSes, or other OSes. Even pre-OSX Macs, with iCab.
Well, actually, the one I had was some 256 megs of RAM and a 1 ghz Transmeta processor.
No, not a fast processor, or a fast video card. But it was backlit, had wifi, and could handle a modern browser. It could also play downloaded anime, though it had trouble with DVDs.
It was, in other words, similar to a modern netbook, only costing quite a lot more.
Can I copy from one module to another while retaining relationships and history? I can in svn (as long as it's not an external) since svn doesn't care what you declare to be a "module".
A submodule is an entirely separate project. So you can port the entire history over (with rebase), but you probably don't want to.
And these are, in fact, the equivalent of svn externals.
"It's not safe to run "git submodule update" if you've made changes within a submodule. They will be silently overwritten".
Whereas with SVN externals, it's not really safe to run 'svn update', just like with the rest of SVN, if you've made changes. Your changes may not be silently discarded, but your working copy could easily get so completely screwed up that it's faster to start over.
Oh, and you quoted that out of context. All that's needed is to check out a branch first.
Even if they are overwritten, unless you've run 'git gc', it's probably possible to recover. Contrast this with svn -- there is no way to undo an 'svn revert'.
And on top of all of that, updating the submodule wasn't really a common operation. Just as you might freeze to a specific version of a library, you probably wouldn't update the submodule very often.
Other points in your post, like claiming that editing directly on a remote share uses less bandwidth than sending periodic diffs
Again, only for the.git folder. Given that git does store periodic diffs, I don't see the difference.
Oh, wait, yes I do -- when I run 'svn merge', there's a good chance svn 1.5 will dig back through several months worth of history, reading some sort of metadata from each, wasting bandwidth, time, and CPU. And a half hour later, I might have something merged, or I might have a pile of conflicts to settle, and I might have to start the process over from scratch again.
"don't worry, we all have a copy somewhere" is a valid backup strategy for a business
I'm sorry, every workstation, plus the production servers if you use Git for deployment, will have a complete copy. Please explain how that's not a valid backup strategy.
Yes. Neither Wii Fit nor MMOs are really AAA titles, so yes, both are exceptions;
Ok, what is a AAA title, if it's not a game that has 10 million people currently playing, and paying monthly for the privilege?
I disagree that expensive hardware makes one more likely to pirate games.
I don't think it has much bearing one way or the other. Your point is valid...
gaming is worth at least $500 a year to you, so the additional cost of a game is likely to be acceptable.
Yet, if you're spending at least $500 a year on this hobby, chances are you know enough to pirate, and you may know enough about DRM to realize that for many games, the pirated copy is of higher value than the legitimate one.
But as I said before, MMOs and casual games are bad businesses.
Actually, no, you said they aren't AAA titles.
Casual Games are drowning in a sea of crap.
So are AAA titles. Sturgeon's Law applies to every demographic -- and from what I've seen, the other 10% of casual games aren't bad.
For those of us who WANT to use iTunes, that's not really a problem.
I'm on Linux, most of the time. But that's only part of the story...
My mother just bought a brand-new iPod. It doesn't work with the version of iTunes she has on her computer, and the new version of iTunes that will work requires XP (she's on 2K). So the choice is either pay for an XP upgrade, or buy her a new computer. Or, as a compromise, I've found an old computer and set up Linux and Amarok.
It's not going to be pleasant if she has to buy a song on iTunes, then transfer it over to this other box, then to her iPod.
I suppose what bothers me most about it is, how difficult is it, really, to set up a shopping cart for music? That's, what, a weekend of work? A week, maybe?
Most people can't hear the difference and don't want to take up the extra hard drive space for lossless encoding, then take the time to re-encode it when transferring to other devices.
Point is, not all devices will necessarily do AAC. For the ones that do, great, it'll probably sound good enough. For the rest, there's a generational loss.
And again, Amarok will do that transcoding for you, which means it takes none of your time, only CPU time while you sync.
The model I've seen work well is, both mp3 and Flac, and charge a little extra for the Flac. People who don't want to deal with it will buy mp3, and people who care about any format other than mp3 can do it themselves by buying Flac.
The longest battery life I've ever had -- and I still miss it -- was around 12 hours, even 15. It was a 10" Sharp subnotebook, with a small battery that lasted maybe 3 hours, and a much larger battery (probably weighed more than the notebook) that lasted nine to twelve hours.
Even if you adjust for the fact that I was running Gentoo, I still wasn't likely to get less than 9 hours, even with the thing compiling a lot.
Of course, it was less convenient -- I had to hibernate, swap batteries, and resume. When I had a Powerbook, it had a tiny internal battery, so you could swap the main battery, and as long as you did it in less than ten minutes, you'd be fine.
I think the main reason people don't do this is that batteries are usually expensive, and there's still no way to charge them except in a laptop. Imagine if you had a 7 hour usable life on that laptop, but two or three batteries. Now imagine you could plug the AC adapter directly into the battery. Now you never have to tether the laptop itself, just swap batteries every now and then.
Compare to, say, Amazon MP3, or Magnatune, or Mindawn, or Nugs.net...
What do all of these have in common?
The ability to buy songs with a web browser, and the availability of lossless music.
Yes, I realize most people can't tell the difference. But the implications of lossless (particularly FLAC) are that the studio only has to release that one format, and users can convert them into anything they want. To make it "easy", they can release an MP3, also.
So... With Amarok -- or at least, once Amarok is working again (fucking Amarok 2 broke everything, but the bug is marked WONTFIX in 1), I can buy music straight from Magnatune, in Flac, store it and play it as Flac on my hard drive, and convert it to AAC or MP3 automatically when I transfer it to an iPod -- or convert it to OGG when I transfer it to a RockBox deviec.
With iTunes, I pretty much have to use iTunes to buy the music, and I'm guessing it's still just going to be AAC.
RIAA: "Hey, our sales are down! It must be piracy!"
2. Stop going to shows of new acts
For the record, this is one place that isn't affected by piracy. If I were a legitimate artist wanting to stay out of the whole debate, I'd give away MP3s, sell physical copies for those who want them, and make the real money from touring.
3. Don't "pirate"[sic] music, just KILL the demand. P2P only lends credence, however tenuous, that they are "losing" money due to "theft"[sic].
This solves nothing. They obviously have no need for real proof, anyway, or why would they have sued dead people, and people who have never used computers? Filesharing could stop, overnight, and they wouldn't notice.
Because it was never about piracy. Piracy is just a nice scapegoat that they use as an excuse to do whatever they want. Right now, that's laws (which give them the right to hit up random people for cash), more DRM (to make it that much more difficult for third parties to compete, while opening the door for selling the same crap to you many more times), and whatever else they feel like doing.
As long as piracy exists, life is good -- they can do pretty much whatever they want, and get away with it.
So, if piracy no longer existed, they would need to create it. I have little doubt that employees of major record labels would be distributing their own files, just so they could pretend that it's still a threat.
4. Don't listen to top 40 radio
Then the question becomes, what should you listen to? Where should you get your music from, if you're to stop buying new music?
All you're doing is sending them a message that you personally no longer care about music, or movies -- and, very likely, they will assume you're a pirate. What you should be doing is sending them a message that also tells them how you want it to look. Show them demand, but on your terms.
It takes a lot of work to write a good text editor, file management tool, or mp3 player.
MP3 player? Are you fucking serious?
No, I'm talking about the kind of app that took a couple hours, at most. Or, especially, the kind of app which is now taken for granted as free on other systems -- regardless of the effort put into it, the value is also a function of demand.
I understand that there's some software for which this makes sense. I actually wouldn't mind paying for TextMate, if I was stuck on a Mac. I'd grumble, but in the end, it's worth the time it saves me.
Which would be fine, if it were just TextMate... ubt it does add up.
That shareware app may well have some ghastly adware mess (or be an outright trojan), plus they've already got your $20 and your credit card number.
The freeware app, at least you don't have to pay to be fucked over.
The open source app, on the other hand, if it's crap, it's generally because it's old and abandoned. It's still usually safe to try, and may be possible to fix, depending on how much you want to spend on it (either your time, or hire a developer).
Right. Who do you think is developing the programs that run on EC2? And who do you think is needed to manage the instances (VMs), or write software to manage them?
Kwin is so much faster than Compiz on my hardware it's not even a fair comparison.
What hardware would that be?
I can't tell the difference between kwin, on my newer, faster hardware, and Beryl (old, old fork of Compiz), on my old, slower hardware. Except for the fact that beryl was less glitchy than kwin at release. At least now it's stable enough, most of the time, but I still get random artifacts when I have desktop effects turned on.
I'm talking a desktop system that's totally built on svg graphics
$ find/usr/share/kde4 -name '*.png' | wc -l 692
*cough* Bullshit.
a system that removes the artificial barriers between application, desktop, panel, etc.
Oh, you mean like WindowMaker? Wow...
Let's see -- The desktop and the panel are still different, although the same widgets can now go in both places. And they do have to be widgets -- applications won't do.
The desktop background is not drawn by a widget. Nor are applications themselves widgets -- nor do they behave like one. A widget can be arbitrarily rotated and resized, and does not do the wobbly window effect.
Oh, and this is pretty much the OS X Dashboard, or Vista's widgets. The only difference is, you used them to build a panel, too -- which is cool. Don't get me wrong -- it's a much cleaner concept, and I'm sure it's cleaner code. It appeals to me as a user.
But at the end of the day, what does it matter? It's not revolutionary. It's not a paradigm shift. It's barely more than a toy. Let's not pretend you just invented the mouse or something.
in the interest of fairness, Amarok is a completely different team and development cycle.
True. But it seems they've both pretty much failed in the same ways -- a dot-oh release as the Next Big Thing, while leaving the stable version to completely rot. On top of which, since the NBT isn't done, and the stable version isn't being worked on, several features are completely broken or absent from both.
The KDE team told you what to expect. We all walked into this with eyes wide open. "If you want stability you want 3.5. If you want the Next Big Thing you want 4."
And they did so by perverting the meaning of version numbers in the same way Microsoft has for decades.
Dot-oh releases mean stability. If you want to tell the rest of the world that it's not ready for consumption yet, you call it alpha, or beta, or you say "Development Release".
When asked, the response I most often get is, you called it dot-oh so that people would start taking it seriously, and start using it. In other words, you released it the way you did specifically to have people try it, by causing the same kind of confusion you now complain about when people try 4.1 and expect a working system.
Firefox 3 is a web browser (and built on the same code as the earlier version to boot). KDE4 is... not.
Granted. But Firefox 3 was over two years in the making, and they still managed to pull off a solid release. KDE4 was in development at least that long, probably longer, and managed to pull off a beta release, which was called 4.0.
in this example that's used as an alternative to/transactions/.
Because for the scenarios Git was designed for, transactions aren't enough.
Would you rather tell someone who asks "where can I find this project?":
- this url: svn+ssh://path/to/repos/path/within/repos/foo; and that's all
- or, this url: ssh://path/to/master; "And within that you want the "foobar" directory.
It'll be in there along with every other project that uses libfoo, since that's the only way to share things with libfoo and other projects when using git."
Or, you can use submodules. Problem solved!
Your idea of a "brutal hack to do what svn does" would.. not at all do what svn does.
You're right. It would use less disk space, and likely be more bandwidth-efficient. And I was talking about the specific problem you were having -- that you couldn't do a shallow checkout.
Subversion's difficulties often amounted to needing to write good commit messages. When SVN failed due to my own fuck-ups, it did so in a way which hurt no one, and was easily restored.
"Easily restored" is a property of any good VCS. But no matter how descriptive my commit messages, that doesn't help with the fact that a simple merge, which would complete in under a second in Git and likely have no conflicts, will take half an hour in SVN and have tons of conflicts.
The only solution is to go back to SVN 1.4, or find the magical flags that make 1.5 behave like 1.4. Then, I can put revision numbers in my commits, and have to stare at the logs for two minutes before every merge, and the merge is still going to take another minute or two.
Keep in mind -- these were on the same repository.
It didn't import into git-svn properly, for what that's worth -- I had some namespaced tags (that is, tags/foo/1.2.3), which meant I had one "tag" called "tags/foo". That made the repo much bigger than it needed to be, but still usually smaller than an SVN checkout, and still much faster to work with.
When git fails, it can need arcane magicks to get it working right.
Same is true of SVN, IMO. The difference is how frequently SVN fails, compared to Git.
And because git encourages you to keep your "working" branches local, fucking up your local repository can mean a serious headache.
Nothing stopping you from pushing your working branch, if you want others to see it. If you don't, backup is still trivial. About to do something that you're afraid will screw up the repository?
git-clone my-project my-project-backup
Hardlinked, so that will take almost no time, but if you screw it up, you're safe. Want to protect against disk failure? Clone to another drive, or another server (anything with an SSH account will do). Don't know when you're about to screw it up? Write a cron job.
It's called "backup", and it's something you have to do with SVN also. The difference is, SVN encourages you to commit less often (because commits are slow, and you can't rewrite history), so you still keep stuff local. Only now, to back up your local copy, you need this:
cp -a my-project my-project-backup
And the server also needs to be backed up -- unlike Git, if the server implodes, all your history is gone, forever, and it'll take a lot more work to start over from everyone's working copies.
Deal with the assets separately, then. SVN might even be a good fit for that, and I believe Photoshop has something like version control built-in.
Or, maybe: When they've finished something, take the output -- the actual PNGs (or whatever you're using) -- and put those into version control. Manage the source Photoshop files with something like Time Machine.
Not everyone is a bash-tested, Linux-wielding Level 99 Code Mage, and successful software keeps this fact in mind.
No, but if you're going to be working on the software, as implied by "developer", learning to use version control is essential. Again, not knowing how to use that is like not knowing how to use a text editor, or your artists not knowing Photoshop.
And for what it's worth, everyone who builds creative works should find some VCS and learn it. If they have to collaborate, they should learn it well.
The money in the US goes to the same US version of the the CPCC. The copyright office has a program set in place for universal copyright licensing and it collects and pay royalties from radio stations, restaurants of certain sizes and so on.
Which makes sense -- these are places that will actually send statistics back on what was actually played. Which means the money is (theoretically) getting back to those artists.
I'm pretty sure the US doesn't do the same thing with CDs, and I seriously doubt Canada has developed the kind of technology you would need to track what is actually burned to which CD -- if any (consider that "data CDs" have their own taxes).
Slashdot Mirror
I hardly think its fair to blame Apple for your klunky workaround when you didn't meet their minimum specs to begin with.
Yeah, what's "klunky" about my workaround?
And all of this would be trivially solved by putting a team on it for a couple of weeks and building a web interface. My less-than-a-year-old OS (Linux) doesn't run iTunes either, and it shouldn't have to.
Which kind of proves my point - look at the awful user interface on Magnatune.
You mean the one that makes it easy to search, sort, and put those songs in a playlist before they're purchased?
What the hell are you talking about? You youself said that you can use Magnatune and Amazon and others.
Except with the iTunes store.
And saying "If you don't like it, go somewhere else" is well within your rights (and Apple's), but it's still a dick move. Kind of like private clubs, some of which don't allow certain religions or skin colors, some of which don't allow women -- maybe legal, but not great.
What the hell? When did I mention IE, and what does this have to do with anything?
It's called a metaphor, dipshit. "If you don't like the fact that this site requires IE, go somewhere else. No one's forcing you to go here." And yet, we still consider it a best practice to design cross-platform sites, and we still get annoyed when we come across a broken site.
That's already happened. We used to have a representative republic. Now we have a corporate oligarchy.
Whoops, correction: LTS is 3 years on the desktop, 5 years on the server.
It looks as though LTS releases are every 2 years, predictably. Which means that for a server product, you can skip a release, then wait a year after release of the next one before you have to switch.
Security is one reason one cannot require a compiler (makes it easier to make exploits if you can compile from source & headers).
Meh.
ssh# cat /proc/cpuinfo /proc/version
ssh# cat
ssh# ^D
local$ firefox http://kernel.org/
Headers are easily available. Compile it locally, copy it back. Not much more than a speed bump -- and an irritating one for legitimate users, too.
And yes, Ubuntu doesn't change more often than 6 months, but I don't want to have to chase bugs during the entire 6 month cycle either (or get blind-sided when the next release comes out and my app breaks).
That's what LTS is for -- stable for 3 years.
In practice, it hasn't been a problem for server deployments, though Kubuntu's handling of KDE4 does not inspire confidence.
But many people prefer to use iTunes. The browsing and purchasing experience is much nicer than web browser based stores.
Design the browser based store properly, or at least provide an open API, and you can do the same elsewhere.
Exhibit A: Magnatune support directly in Amarok.
Do you have some sort of problem with people having different preferences than yourself?
When only their preferences are supported, yes, it's a problem.
Yeah, use IE if you really want to, so long as your site is designed to some reasonable approximation of standards, so I don't have to. If you slap on a "best viewed in IE6" disclaimer and ignore Firefox, well, 1995 called...
No, it's not Apple's fault.
Point is, if they'd stuck to open standards, it wouldn't matter -- they wouldn't have to do any work to support older OSes, or other OSes. Even pre-OSX Macs, with iCab.
Well, actually, the one I had was some 256 megs of RAM and a 1 ghz Transmeta processor.
No, not a fast processor, or a fast video card. But it was backlit, had wifi, and could handle a modern browser. It could also play downloaded anime, though it had trouble with DVDs.
It was, in other words, similar to a modern netbook, only costing quite a lot more.
Can I copy from one module to another while retaining relationships and history? I can in svn (as long as it's not an external) since svn doesn't care what you declare to be a "module".
A submodule is an entirely separate project. So you can port the entire history over (with rebase), but you probably don't want to.
And these are, in fact, the equivalent of svn externals.
"It's not safe to run "git submodule update" if you've made changes within a submodule. They will be silently overwritten".
Whereas with SVN externals, it's not really safe to run 'svn update', just like with the rest of SVN, if you've made changes. Your changes may not be silently discarded, but your working copy could easily get so completely screwed up that it's faster to start over.
Oh, and you quoted that out of context. All that's needed is to check out a branch first.
Even if they are overwritten, unless you've run 'git gc', it's probably possible to recover. Contrast this with svn -- there is no way to undo an 'svn revert'.
And on top of all of that, updating the submodule wasn't really a common operation. Just as you might freeze to a specific version of a library, you probably wouldn't update the submodule very often.
Other points in your post, like claiming that editing directly on a remote share uses less bandwidth than sending periodic diffs
Again, only for the .git folder. Given that git does store periodic diffs, I don't see the difference.
Oh, wait, yes I do -- when I run 'svn merge', there's a good chance svn 1.5 will dig back through several months worth of history, reading some sort of metadata from each, wasting bandwidth, time, and CPU. And a half hour later, I might have something merged, or I might have a pile of conflicts to settle, and I might have to start the process over from scratch again.
"don't worry, we all have a copy somewhere" is a valid backup strategy for a business
I'm sorry, every workstation, plus the production servers if you use Git for deployment, will have a complete copy. Please explain how that's not a valid backup strategy.
Yes. Neither Wii Fit nor MMOs are really AAA titles, so yes, both are exceptions;
Ok, what is a AAA title, if it's not a game that has 10 million people currently playing, and paying monthly for the privilege?
I disagree that expensive hardware makes one more likely to pirate games.
I don't think it has much bearing one way or the other. Your point is valid...
gaming is worth at least $500 a year to you, so the additional cost of a game is likely to be acceptable.
Yet, if you're spending at least $500 a year on this hobby, chances are you know enough to pirate, and you may know enough about DRM to realize that for many games, the pirated copy is of higher value than the legitimate one.
But as I said before, MMOs and casual games are bad businesses.
Actually, no, you said they aren't AAA titles.
Casual Games are drowning in a sea of crap.
So are AAA titles. Sturgeon's Law applies to every demographic -- and from what I've seen, the other 10% of casual games aren't bad.
True enough. However, when the masses come to me for advice, I will mention these things.
You should not have to install a piece of software to use a fucking music store.
Do you have to install eTunes to use eBay? Do you have to install amaTunes to use Amazon?
As for the masses, a surprising number seem to prefer Winamp.
For those of us who WANT to use iTunes, that's not really a problem.
I'm on Linux, most of the time. But that's only part of the story...
My mother just bought a brand-new iPod. It doesn't work with the version of iTunes she has on her computer, and the new version of iTunes that will work requires XP (she's on 2K). So the choice is either pay for an XP upgrade, or buy her a new computer. Or, as a compromise, I've found an old computer and set up Linux and Amarok.
It's not going to be pleasant if she has to buy a song on iTunes, then transfer it over to this other box, then to her iPod.
I suppose what bothers me most about it is, how difficult is it, really, to set up a shopping cart for music? That's, what, a weekend of work? A week, maybe?
Most people can't hear the difference and don't want to take up the extra hard drive space for lossless encoding, then take the time to re-encode it when transferring to other devices.
Point is, not all devices will necessarily do AAC. For the ones that do, great, it'll probably sound good enough. For the rest, there's a generational loss.
And again, Amarok will do that transcoding for you, which means it takes none of your time, only CPU time while you sync.
The model I've seen work well is, both mp3 and Flac, and charge a little extra for the Flac. People who don't want to deal with it will buy mp3, and people who care about any format other than mp3 can do it themselves by buying Flac.
The longest battery life I've ever had -- and I still miss it -- was around 12 hours, even 15. It was a 10" Sharp subnotebook, with a small battery that lasted maybe 3 hours, and a much larger battery (probably weighed more than the notebook) that lasted nine to twelve hours.
Even if you adjust for the fact that I was running Gentoo, I still wasn't likely to get less than 9 hours, even with the thing compiling a lot.
Of course, it was less convenient -- I had to hibernate, swap batteries, and resume. When I had a Powerbook, it had a tiny internal battery, so you could swap the main battery, and as long as you did it in less than ten minutes, you'd be fine.
I think the main reason people don't do this is that batteries are usually expensive, and there's still no way to charge them except in a laptop. Imagine if you had a 7 hour usable life on that laptop, but two or three batteries. Now imagine you could plug the AC adapter directly into the battery. Now you never have to tether the laptop itself, just swap batteries every now and then.
Compare to, say, Amazon MP3, or Magnatune, or Mindawn, or Nugs.net...
What do all of these have in common?
The ability to buy songs with a web browser, and the availability of lossless music.
Yes, I realize most people can't tell the difference. But the implications of lossless (particularly FLAC) are that the studio only has to release that one format, and users can convert them into anything they want. To make it "easy", they can release an MP3, also.
So... With Amarok -- or at least, once Amarok is working again (fucking Amarok 2 broke everything, but the bug is marked WONTFIX in 1), I can buy music straight from Magnatune, in Flac, store it and play it as Flac on my hard drive, and convert it to AAC or MP3 automatically when I transfer it to an iPod -- or convert it to OGG when I transfer it to a RockBox deviec.
With iTunes, I pretty much have to use iTunes to buy the music, and I'm guessing it's still just going to be AAC.
Oh yeah, and the tiered pricing.
1. Stop buying new music
RIAA: "Hey, our sales are down! It must be piracy!"
2. Stop going to shows of new acts
For the record, this is one place that isn't affected by piracy. If I were a legitimate artist wanting to stay out of the whole debate, I'd give away MP3s, sell physical copies for those who want them, and make the real money from touring.
3. Don't "pirate"[sic] music, just KILL the demand. P2P only lends credence, however tenuous, that they are "losing" money due to "theft"[sic].
This solves nothing. They obviously have no need for real proof, anyway, or why would they have sued dead people, and people who have never used computers? Filesharing could stop, overnight, and they wouldn't notice.
Because it was never about piracy. Piracy is just a nice scapegoat that they use as an excuse to do whatever they want. Right now, that's laws (which give them the right to hit up random people for cash), more DRM (to make it that much more difficult for third parties to compete, while opening the door for selling the same crap to you many more times), and whatever else they feel like doing.
As long as piracy exists, life is good -- they can do pretty much whatever they want, and get away with it.
So, if piracy no longer existed, they would need to create it. I have little doubt that employees of major record labels would be distributing their own files, just so they could pretend that it's still a threat.
4. Don't listen to top 40 radio
Then the question becomes, what should you listen to? Where should you get your music from, if you're to stop buying new music?
All you're doing is sending them a message that you personally no longer care about music, or movies -- and, very likely, they will assume you're a pirate. What you should be doing is sending them a message that also tells them how you want it to look. Show them demand, but on your terms.
I agree with you wholeheartedly, but I'm really hard pressed to believe that the readership of Slashdot is what's driving the demand for the Big 4.
And that's if you can even convince us. I'm not convinced these steps will actually do much.
It takes a lot of work to write a good text editor, file management tool, or mp3 player.
MP3 player? Are you fucking serious?
No, I'm talking about the kind of app that took a couple hours, at most. Or, especially, the kind of app which is now taken for granted as free on other systems -- regardless of the effort put into it, the value is also a function of demand.
I understand that there's some software for which this makes sense. I actually wouldn't mind paying for TextMate, if I was stuck on a Mac. I'd grumble, but in the end, it's worth the time it saves me.
Which would be fine, if it were just TextMate... ubt it does add up.
And open source trumps both.
That shareware app may well have some ghastly adware mess (or be an outright trojan), plus they've already got your $20 and your credit card number.
The freeware app, at least you don't have to pay to be fucked over.
The open source app, on the other hand, if it's crap, it's generally because it's old and abandoned. It's still usually safe to try, and may be possible to fix, depending on how much you want to spend on it (either your time, or hire a developer).
Right. Who do you think is developing the programs that run on EC2? And who do you think is needed to manage the instances (VMs), or write software to manage them?
Adapt or die.
Kwin is so much faster than Compiz on my hardware it's not even a fair comparison.
What hardware would that be?
I can't tell the difference between kwin, on my newer, faster hardware, and Beryl (old, old fork of Compiz), on my old, slower hardware. Except for the fact that beryl was less glitchy than kwin at release. At least now it's stable enough, most of the time, but I still get random artifacts when I have desktop effects turned on.
I'm talking a desktop system that's totally built on svg graphics
$ find /usr/share/kde4 -name '*.png' | wc -l
692
*cough* Bullshit.
a system that removes the artificial barriers between application, desktop, panel, etc.
Oh, you mean like WindowMaker? Wow...
Let's see -- The desktop and the panel are still different, although the same widgets can now go in both places. And they do have to be widgets -- applications won't do.
The desktop background is not drawn by a widget. Nor are applications themselves widgets -- nor do they behave like one. A widget can be arbitrarily rotated and resized, and does not do the wobbly window effect.
Oh, and this is pretty much the OS X Dashboard, or Vista's widgets. The only difference is, you used them to build a panel, too -- which is cool. Don't get me wrong -- it's a much cleaner concept, and I'm sure it's cleaner code. It appeals to me as a user.
But at the end of the day, what does it matter? It's not revolutionary. It's not a paradigm shift. It's barely more than a toy. Let's not pretend you just invented the mouse or something.
in the interest of fairness, Amarok is a completely different team and development cycle.
True. But it seems they've both pretty much failed in the same ways -- a dot-oh release as the Next Big Thing, while leaving the stable version to completely rot. On top of which, since the NBT isn't done, and the stable version isn't being worked on, several features are completely broken or absent from both.
The KDE team told you what to expect. We all walked into this with eyes wide open. "If you want stability you want 3.5. If you want the Next Big Thing you want 4."
And they did so by perverting the meaning of version numbers in the same way Microsoft has for decades.
Dot-oh releases mean stability. If you want to tell the rest of the world that it's not ready for consumption yet, you call it alpha, or beta, or you say "Development Release".
When asked, the response I most often get is, you called it dot-oh so that people would start taking it seriously, and start using it. In other words, you released it the way you did specifically to have people try it, by causing the same kind of confusion you now complain about when people try 4.1 and expect a working system.
Firefox 3 is a web browser (and built on the same code as the earlier version to boot). KDE4 is... not.
Granted. But Firefox 3 was over two years in the making, and they still managed to pull off a solid release. KDE4 was in development at least that long, probably longer, and managed to pull off a beta release, which was called 4.0.
sometimes you will find that you have ridiculous requirements like a) don't require a compiler b) has to be installable by non-root
Never ran into trouble as non-root, but it's also been awhile since I've used CPAN.
Why aren't you allowed to require a compiler?
at least it is a implementation that can be relied upon to not change from month to month
Which Ubuntu doesn't. It changes every six months, and that's if you're not using LTS.
in this example that's used as an alternative to /transactions/.
Because for the scenarios Git was designed for, transactions aren't enough.
Would you rather tell someone who asks "where can I find this project?":
- this url: svn+ssh://path/to/repos/path/within/repos/foo; and that's all
- or, this url: ssh://path/to/master; "And within that you want the "foobar" directory.
It'll be in there along with every other project that uses libfoo, since that's the only way to share things with libfoo and other projects when using git."
Or, you can use submodules. Problem solved!
Your idea of a "brutal hack to do what svn does" would.. not at all do what svn does.
You're right. It would use less disk space, and likely be more bandwidth-efficient. And I was talking about the specific problem you were having -- that you couldn't do a shallow checkout.
Subversion's difficulties often amounted to needing to write good commit messages. When SVN failed due to my own fuck-ups, it did so in a way which hurt no one, and was easily restored.
"Easily restored" is a property of any good VCS. But no matter how descriptive my commit messages, that doesn't help with the fact that a simple merge, which would complete in under a second in Git and likely have no conflicts, will take half an hour in SVN and have tons of conflicts.
The only solution is to go back to SVN 1.4, or find the magical flags that make 1.5 behave like 1.4. Then, I can put revision numbers in my commits, and have to stare at the logs for two minutes before every merge, and the merge is still going to take another minute or two.
Keep in mind -- these were on the same repository.
It didn't import into git-svn properly, for what that's worth -- I had some namespaced tags (that is, tags/foo/1.2.3), which meant I had one "tag" called "tags/foo". That made the repo much bigger than it needed to be, but still usually smaller than an SVN checkout, and still much faster to work with.
When git fails, it can need arcane magicks to get it working right.
Same is true of SVN, IMO. The difference is how frequently SVN fails, compared to Git.
And because git encourages you to keep your "working" branches local, fucking up your local repository can mean a serious headache.
Nothing stopping you from pushing your working branch, if you want others to see it. If you don't, backup is still trivial. About to do something that you're afraid will screw up the repository?
git-clone my-project my-project-backup
Hardlinked, so that will take almost no time, but if you screw it up, you're safe. Want to protect against disk failure? Clone to another drive, or another server (anything with an SSH account will do). Don't know when you're about to screw it up? Write a cron job.
It's called "backup", and it's something you have to do with SVN also. The difference is, SVN encourages you to commit less often (because commits are slow, and you can't rewrite history), so you still keep stuff local. Only now, to back up your local copy, you need this:
cp -a my-project my-project-backup
And the server also needs to be backed up -- unlike Git, if the server implodes, all your history is gone, forever, and it'll take a lot more work to start over from everyone's working copies.
The rest are talented artists and musicians.
Deal with the assets separately, then. SVN might even be a good fit for that, and I believe Photoshop has something like version control built-in.
Or, maybe: When they've finished something, take the output -- the actual PNGs (or whatever you're using) -- and put those into version control. Manage the source Photoshop files with something like Time Machine.
Not everyone is a bash-tested, Linux-wielding Level 99 Code Mage, and successful software keeps this fact in mind.
No, but if you're going to be working on the software, as implied by "developer", learning to use version control is essential. Again, not knowing how to use that is like not knowing how to use a text editor, or your artists not knowing Photoshop.
And for what it's worth, everyone who builds creative works should find some VCS and learn it. If they have to collaborate, they should learn it well.
The money in the US goes to the same US version of the the CPCC. The copyright office has a program set in place for universal copyright licensing and it collects and pay royalties from radio stations, restaurants of certain sizes and so on.
Which makes sense -- these are places that will actually send statistics back on what was actually played. Which means the money is (theoretically) getting back to those artists.
I'm pretty sure the US doesn't do the same thing with CDs, and I seriously doubt Canada has developed the kind of technology you would need to track what is actually burned to which CD -- if any (consider that "data CDs" have their own taxes).
Microsoft ship drivers on the Windows install discs that only support Direct3D
Which Windows install discs? XP certainly doesn't have them -- it has VGA drivers. Perhaps GL is supported, but that seems really unlikely.
I think the drivers distributed through Windows Update have the same problem,
What, the problem of not existing? Yes they do.
Maybe Intel has worked something out, but I can't remember ever seeing nvidia or ati drivers through Windows Update.