That, or he fears pain more than death. Most people fear pain, a lot.
He, instead of fighting the pain and clinging as long as he could (and affording himself the possibility of a medical breakthrough or a medical miracle), like many of us would, simply gave up and took his ball home.
From a certain perspective, that is cowardice.
Death is a complete unknown. Rather than face the pain he knows, clinging to another few years, days, hours with loved ones, he instead walked headfirst into what could very well be worse pain and debilitation (think any religion's hell), yet clearly in a desire to avoid the pain and debilitation that he knew.
From a certain perspective, that is stupidity.
I don't think we can really judge one way or the other, though. At a certain point, it's a choice between being a burden to your family as you slowly drift into a coma and then death, or cutting off all medical treatment (and thus bills).
I don't get whats so difficult about merging with SVN.
That's like saying, "I don't get what's so difficult about piping wget through less." It's not really difficult, per se, and it can be done -- and, in fact, I've had reason to do so -- but would you really prefer that to a modern web browser?
You may think I'm exaggerating. I'm not. SVN really is that bad, and Git really is that much better.
You checkout the branch where you want the merge applied. You get the changes from the branch you want to merge.
Right. How do you know which changes you want?
Well, either you run 'svn log' in both branches, trying to figure out when they were last merged, and write down the revision numbers in question, then paste those, along with the repository URL, into something like: "svn merge http://example.com/app/branches/foo -r1234:5678"
Or you turn on merge tracking and let SVN take 20 minutes or more to find out the same information. And then take another 20 minutes or more if you don't successfully resolve conflicts as it's trying to merge.
You run your tests to make sure everything works.
You left out "spend 5-10 minutes sifting through conflicts that Git would've avoided." Sure, Git has conflicts, but you end up with much fewer than with SVN.
And for the record, yes, I am comparing apples to apples. I worked on a system in SVN for over a year. Then I migrated to git-svn. It was like night and day, even still syncing to the SVN server, even with the exact same project.
How likely is it you will introduce at least one new, probably worse bug while trying to fix this bug in code you have never seen before - unlike the guy who originally added it, and all those who checked the code since?
Considering I'll submit it to be checked, chances are small that such a bug would survive.
Also, what are the chances that this code is so insanely complex and fragile that this is likely?
With Windows and OS X, those are the only two choices.
With Linux, there's a third option: Fix it myself.
Now, granted, you're still going to have all kinds of people who go with option #1 and option #2. But if I had the skills to find and debug kernel exploits, for instance, I'd probably want to fix them at least to secure my own systems.
Also worth mentioning -- with Windows and OS X, developers can know about a bug and ignore it, hoping no one notices. This is an obvious example:
To make this disclosure full: I discovered the kernel panic in August 2008. I wrote to Apple but the only reply I got was indicating that they are investigating the problem. In July 2009 I finally spent some time and debug the problem. After I found that it could be used to write arbitrary data in memory I wrote again to Apple. This time they wrote back asking me if I want to be credited in the Security Update. They kept their promise.:-)
And, looking at that page:
About the security content of Security Update 2009-003.... Last Modified: August 05, 2009
So it was at least four or five months, and it looks like a year, between the initial report and the fix. This can only really happen with closed software -- open source tends to fix security issues within days, if not hours, of being reported.
And again, despite this being a very knowledgeable guy who knows how to step through the kernel with a debugger, the proprietary nature of it means that he couldn't even fix it on his own machine until Apple finally got off their asses and released a patch.
Problem is, Linux existed for the PC hardware before Windows did.
So, really, who chooses DOS over any sort of Unix?
And Windows, well, that fits nearly perfectly. X11 existed, and so did Mac OS. But Windows was quicker to market, cheaper than the Mac, and by the time anything like a usable desktop Linux existed, it was ubiquitous. So now, even though Windows is the worst OS in common use in so many ways, it's also better in that everything works on Windows.
Rarely, you get something both better and widespread. The web is an example -- Javascript is actually a really nice language, for one. Would I rather use another language? Sure, but true "worse is better" fashion would've had something like Java or Visual Basic in that role.
I can't believe no one's mentioned "worse is better" yet. An excerpt:
I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing
Another example would be Linux. It can be argued that Minix and Gnu HURD both likely had superior designs -- in fact, at the time, Linus fully expected Linux to become irrelevant once HURD was released. It never happened -- because Linux was available now, and was free and freely modifiable now, even though it was worse, it attracted enough developers so that it ultimately became more practical for most tasks.
And of course, the most obvious example is Windows. This follows the pattern:
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
DOS was an abomination, especially considering real OSes existed at the time. Windows 3.1 was barely more than a multiplexer for DOS, and Windows 95/98/ME were similarly backward abominations. Windows NT was unusable by ordinary users until Windows 2000, and why would power users prefer it over Unix?
Yet they were half the right thing, and they were usable by ordinary people, on the PC, faster and cheaper than anyone else.
The story mentions netbooks, but that's just the latest iteration of this. Remember, the original PCs weren't as powerful as minicomputers, which weren't as powerful as mainframes.
If you could duplicate that key you could decrypt the per-channel keys on any device, though you'd still need to have a valid subscription for the original card; you could share a subscription, but not avoid the bill altogether.
Not a problem.
And of course, there's still the Pirate Bay problem -- it only takes one person who's willing to pay the bill and record a given show.
But it's not trivial to to pull private keys out of the smart card
Would it be possible, then, to instead create a device which talks to the smart card?
it's probably feasible to crack, but not cheap and easy,
Granted. Most things aren't.
and therefore it's indifferent from impossible
Unless cracking it once can be replicated.
Anyway, thanks. That was informative -- lots of things I didn't know at all.
I think if the device is cheap enough to use single DES, it's not also going to be fast enough with that single DES to decrypt the entire multiplexed stream.
And how, exactly, are they distributing the new keys?
If the new keys are distributed encrypted with the old cipher, then my TV is delayed by exactly however long it takes to decrypt the first one -- and once I do that, I can still fastforward to the end.
If they're using a common shared key on the device, we only need to crack open one such device.
About the only way I could see this working is if each model had an individual private key and was tamper-proof -- but it seems to me that having to send so much data unicast to a single subscriber may break their network. Even then, it's for some value of "work" -- all we need is one person to either get around the tamper-proof-ness, or exploit an analog hole, and then record and upload their TV to the Internet -- then everyone gets it for free.
That, or the one inside man who can get access to the original recording before it's encrypted...
You're using 1k blocks. That's going to be much slower. Here's your test (shortened, because I didn't want to wait):
> dd if=/dev/zero of=test bs=1024 count=20000 20000+0 records in 20000+0 records out 20480000 bytes (20 MB) copied, 1.33289 s, 15.4 MB/s
> dd if=/dev/zero of=test bs=1048576 count=20 20+0 records in 20+0 records out 20971520 bytes (21 MB) copied, 0.469102 s, 44.7 MB/s
Slightly more data, yet faster. And it does somewhat sustain that:
> dd if=/dev/zero of=test bs=1048576 count=2048 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 65.6037 s, 32.7 MB/s
Keep in mind, this is on my external hard drive. It likes to buffer a lot (not sure if it's Linux, the drive, or ntfs-3g), so it makes sense that it's slower when sustained. But it's nowhere near as bad as your results.
I suppose it's possible I simply have a faster CPU, but it does seem like the killer here is the number of writes, not the size of them. I've certainly copied gigabytes onto and off of this drive without much issue.
Then again, I mostly use it for just that -- an external hard drive to throw movies onto. I'd never try to run a VM on top of it.
MOST companies force you to sign a contract at time of employment that basically claims that anything you create while you are employed by the company is legally theirs.
These aren't always enforceable, and I certainly never signed one.
One is to protect their own asses... while you're busy coding at Adobe for their Great New Photoshop, you can't go home and use the ideas, even those YOU came up with at work, to create "Joe's Photomall" and suddenly turn around and start undercutting photoshop.
Then they should put a noncompete clause in -- which still isn't always enforceable.
In any case, this is why I read the more important contracts (like employment), and strike the stuff I don't agree with.
The SHA1 hashes may look scary at first, but it really is the best approach.
This is the only thing I'm not sure I agree with -- SHA1 is kind of weak by now, and it was already old-ish when Git was written.
But I definitely agree on that much -- I prefer a globally unique number (though maybe a GUID would be better?) to a kludgy attempt at preserving revision numbers.
There was actually another reason I preferred bzr -- it's written in Python. Git is written in C, Bash, and Perl, which means a lot steeper of a learning curve if I were to ever hack on it. But I'm starting to realize I'm about as likely to hack on Git as I am to hack on my filesystem -- rather than link against it, I can always write a script that calls git commands.
Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer?
No, but I could tell with a quick 'git log' of each.
Can you tell me when I would ever, ever need this? I never look at revision numbers outside of a log anyway. The last time I can remember caring what those numbers were, or holding them in my head for longer than a copy/paste (if that), is when I had to manually feed revision numbers into 'svn merge'.
Well, guess what? 'git merge' is smart enough to not need that. The "merge tracking" feature of SVN that's supposed to give it similar functionality also slows it down insanely -- merges should take seconds, not half an hour.
To me, it would make more sense if there was an incremental part to a git changelist id, even if it was "number of seconds since 2000" or something else unreadable,
Congrats! Two coders have now created exactly the same revision number, by committing on the same second!
Never mind that those are not exactly easy to tell, at a glance, which is greater. The epoch time now is 1251278556. Now it's 1251278604. Can you tell "at a glance" which is greater?
In fact, want to race? I bet I can run two 'git log' commands in the time your "glance" takes, with numbers like that.
you could ask someone "which revision crashed" and get back an answer you could easily use to tell if they were up-to-date or miles out of date.
If you're talking about programmers, just tell them to pull and try again -- it won't take long, and it won't break anything. Or ask them to run 'git log', and you'll get a date and time.
If you're talking about end-users, may as well put a date and time in the build, as part of the "version" information.
You can branch to your heart's content in Subversion.
Which is useless if you can't merge.
Git branches are not only much lower cost at the beginning (the command runs faster and is easier to use, and other users don't have to know about your branch until it's ready), but they merge much more easily.
The only difference is that Subversion is centralized, so you need a network connection to the server to commit.
Well, and that if the network connection or the server goes down, I can't work.
But to say that distributed is the only good thing about Git would be like saying that centralized is the only good thing about SVN.
Which would you rather use, SVN or CVS?
Then you can understand why I'd rather use Git, even in a centralized environment. In fact, I'd say the productivity gains for Git over SVN are probably greater than those of SVN over CVS.
It has changed, somewhat -- but mostly, I think there's just better documentation.
But, for example...
Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things
That is pretty fundamental to the design -- it's a SHA1 hash. It's also not incredibly difficult -- cut and paste. When your SVN revisions hit four and five digits, they don't really have much more meaning than that hash, do they?
Generally, you learn to use relative terms, instead -- for example, HEAD^ to refer to the revision just behind HEAD.
mercurial was much more straightforward
I thought so, too...
I think I tried mercurial, and then bzr, and eventually settled on Git for three reasons:
It's obscenely fast
Everyone's doing it, which has a network effect (github)
I can hold its data model comfortably in my head.
I should clarify that last part... Maybe some things are cryptic, and I'm sure I don't know all of the possible commands I could run -- but at a very basic level, I know exactly what's going on, just like I did in SVN.
Just for fun, here's the data model in a paragraph: There are commits. Each commit has a parent commit that it includes, except for merges, which have two parents. A branch is just a pointer to a commit.
That's it.
And knowing that, everything else starts to make sense... but it's more than I want to get into in a Slashdot post.
There is an occasional conflict, but you can't always avoid that.
Git avoids that a lot better than Subversion does. Yes, there's an "occasional" conflict, but much more rarely.
Call me a die hard, but I wouldn't trust Subversion's automatic merge feature. I do it all by hand
Yes, I've done that...
Doing it all by hand sucks -- it's a lot of manual effort to make sure you know exactly what you should be merging, and it still takes far longer to do that. Doing it with SVN's merge tracking sucks -- we had it to where it was taking half an hour, and could still fail.
I mean, I liked the model. I liked having a deep understanding of what it was doing.
But even by hand, even trying to disable all the merge tracking stuff, it still took minutes. And that's after doing the 'svn log' myself, trying to figure out exactly what should be merged...
In Git, I haven't found an operation that takes longer than seconds. Having five branches per developer is actually a perfectly sane and workable situation on Git -- having one branch per developer was a nightmare in SVN.
I doubt that anyone who's actually used a modern SCM can say with confidence that SVN merging doesn't suck. Half an hour for SVN vs one second for Git.
Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works.
Ok, yes, some tools do. For example, subversion supports trivial branching, but sucks at merging, so it encourages people to work on a common "trunk" branch. It also only supports a central server, so it "encourages" developing with a central server.
Git, on the other hand, "encourages" people to not put multi-gigabyte files in version control.
However, Git can be used to talk to an SVN repository. It can also talk to a central repository, or work purely via ssh between workstations, or with something like Gitjour, in a truly distributed fashion. Github is a strange and wonderful mutation of the two.
Perhaps, by making branches and merges so awesomely fast, Git "encourages" lots of little local branches, and keeping a neat patch history. But to sum it up:
SVN can handle large binary files and Windows better than Git, and is better integrated into IDEs.
Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.
First, just enabling "power saver" isn't what I want. That laptop got those 9-12 hours of battery life, and was also fast and responsive when I needed it. Not incredibly fast (it was still Transmeta), but fast. So, this would be closer to "dynamic" if there's something similar.
Second, this isn't what I recommend, nor did I mean to imply that it's the only way to do things on Linux. I currently use KDE4, and I can point-and-click power management like the rest of you.
And finally, it was fun and hackish -- aside from the performance boost I got, I challenge you to show me as easy a method to have a Windows laptop scold people for pushing the power button.
These days, I have my priorities a bit saner. I run a Dell with Ubuntu, and while I am occasionally prone to scripting away annoyances, I spend far more time actually using my laptop than hacking it.
But then, I'm not particularly sure why I should have to prove myself to an Anonymous Coward. Ladies like confidence, too.
With recent laptops, I haven't noticed or cared, but I had a netbook before it was called a netbook -- the Sharp Actius MM10. And while I never tried it on Windows, it had one battery that supposedly lasts two and a half hours hours (that I remember lasting 3 hours), and another that supposedly lasts seven and a half hours (that I remember lasting 8-12 hours).
It's worth mentioning that I don't remember half the tweaks I did to this machine. With only a 15 gig hard drive and 256 megs of RAM, I installed Gentoo and used CFLAGS=-Os, custom-compiled my kernel complete with suspend patches and Reiser4 (practically a laptop mode all by itself), and otherwise modded it in every way known to man. I mean, I had a Fluxbox desktop with no menu, only the equivalent of alt+f2; because I didn't have any advanced power management running, I wrote my own Perl scripts to check the battery state, and to respond to ACPI events (lid closing locked it but didn't suspend, power button at various times would hibernate, or display a giant message saying "PLEASE DON'T PUSH THE POWER BUTTON, KTHNX"...
Also worth mentioning that Reiser4 wasn't the only prerelease software I used -- and it was prerelease, at the time. I backed it up frequently.
Still, I'm fairly surprised to learn that Linux battery life sucks on modern notebooks. My current machine was not built for battery life, so I've never actively run a test.
I suppose what's worse than that, though, is how much battery life sucks on modern notebooks, period, including netbooks. I admit the Transmeta chip felt sluggish, but on the other hand, can you buy any laptop today that'll run for nine hours on a charge, to where you can simply leave the power adapter plugged in at home for the day?
To me, Firefox feels like IE with most of the confusing graphics and stupid menu options taken out.
Well, and with more security. And decent support for web standards. And a huge collection of addons.
I mean, I agree with the disadvantages, but I don't agree that it's anywhere near as bad as IE.
One thing that annoyed me with Google Chrome is that they suddenly decide to design this Chrome OS thing based on Linux, yet Chrome browser seems to be continuously stuck on some kind of preview version and Windows version is always bang up-to-date.
Well, if the Linux version is anything like Android, I don't blame them. Android uses a non-standard libc, and it just gets weirder from there -- it's not X, for instance. Chrome OS is likely going to be very different than Linux -- at least as much as any one distro is from another, probably much worse.
There's a few things they've done very well with the Linux version:
First, it's actually open source. If you really don't like it, there's always Chromium. Example: I'm typing this on a 32-bit Google Chrome, because I decided to get it directly from Google. But Chromium already has a 64-bit version out.
Second, they actually made a Debian package. Just about every other piece of proprietary software for Linux is either a zip/tarball (which I can tolerate), or a script/executable, which is just irritating. I guess non-Debian distros will be annoyed...
And finally, rather than include some crappy auto-updater of their own, on Linux, they simply provided a repository -- thus integrating with system updates.
I don't really see much improvement over the previous years models at all.
Most of them are the same, it's true. But:
Sure in very recent history there have been improvements in fuel economy (hybrids, etc) but prior to that there hadn't been much difference in cars for 20 years.
And airbags. And side impact airbags. And minivans. And minivans with automatic doors.
I'm not saying a new car is a reason to get excited, but let me put it this way:
First of all, if you didn't have a car, would you refuse to buy one?
Second, if you had a good car from 20 years ago, would you refuse to buy one today, even if your old car ran just fine? (Some would, some wouldn't. But cars from 10, 20, 30 years ago represent about the change in looks you'd expect in a first person shooter over 5-10 years.)
And finally, even if it's just a slightly different body style and paint job, wouldn't you rather have, say, this car, or maybe this one, than the one you've got? Even if you answered "no", you probably see my point -- the reason you answered "no", I'll bet, has more to do with not liking those particular cars than with not being able to think of any car better than the one you've got.
Slashdot Mirror
Well, and if it does, they'll believe it's the Rapture.
That, or he fears pain more than death. Most people fear pain, a lot.
He, instead of fighting the pain and clinging as long as he could (and affording himself the possibility of a medical breakthrough or a medical miracle), like many of us would, simply gave up and took his ball home.
From a certain perspective, that is cowardice.
Death is a complete unknown. Rather than face the pain he knows, clinging to another few years, days, hours with loved ones, he instead walked headfirst into what could very well be worse pain and debilitation (think any religion's hell), yet clearly in a desire to avoid the pain and debilitation that he knew.
From a certain perspective, that is stupidity.
I don't think we can really judge one way or the other, though. At a certain point, it's a choice between being a burden to your family as you slowly drift into a coma and then death, or cutting off all medical treatment (and thus bills).
I don't get whats so difficult about merging with SVN.
That's like saying, "I don't get what's so difficult about piping wget through less." It's not really difficult, per se, and it can be done -- and, in fact, I've had reason to do so -- but would you really prefer that to a modern web browser?
You may think I'm exaggerating. I'm not. SVN really is that bad, and Git really is that much better.
You checkout the branch where you want the merge applied. You get the changes from the branch you want to merge.
Right. How do you know which changes you want?
Well, either you run 'svn log' in both branches, trying to figure out when they were last merged, and write down the revision numbers in question, then paste those, along with the repository URL, into something like: "svn merge http://example.com/app/branches/foo -r1234:5678"
Or you turn on merge tracking and let SVN take 20 minutes or more to find out the same information. And then take another 20 minutes or more if you don't successfully resolve conflicts as it's trying to merge.
You run your tests to make sure everything works.
You left out "spend 5-10 minutes sifting through conflicts that Git would've avoided." Sure, Git has conflicts, but you end up with much fewer than with SVN.
And for the record, yes, I am comparing apples to apples. I worked on a system in SVN for over a year. Then I migrated to git-svn. It was like night and day, even still syncing to the SVN server, even with the exact same project.
But some setups are better with a centralized setup.
So you run Git on a centralized server. Why are we still talking about this?
Subversion can do centralized or centralized. Git can do centralized or distributed, and it does centralized much better than SVN does.
How likely is it you will introduce at least one new, probably worse bug while trying to fix this bug in code you have never seen before - unlike the guy who originally added it, and all those who checked the code since?
Considering I'll submit it to be checked, chances are small that such a bug would survive.
Also, what are the chances that this code is so insanely complex and fragile that this is likely?
With Windows and OS X, those are the only two choices.
With Linux, there's a third option: Fix it myself.
Now, granted, you're still going to have all kinds of people who go with option #1 and option #2. But if I had the skills to find and debug kernel exploits, for instance, I'd probably want to fix them at least to secure my own systems.
Also worth mentioning -- with Windows and OS X, developers can know about a bug and ignore it, hoping no one notices. This is an obvious example:
To make this disclosure full: I discovered the kernel panic in August 2008. I wrote to Apple but the only reply I got was indicating that they are investigating the problem. In July 2009 I finally spent some time and debug the problem. After I found that it could be used to write arbitrary data in memory I wrote again to Apple. This time they wrote back asking me if I want to be credited in the Security Update. They kept their promise. :-)
And, looking at that page:
About the security content of Security Update 2009-003.... Last Modified: August 05, 2009
So it was at least four or five months, and it looks like a year, between the initial report and the fix. This can only really happen with closed software -- open source tends to fix security issues within days, if not hours, of being reported.
And again, despite this being a very knowledgeable guy who knows how to step through the kernel with a debugger, the proprietary nature of it means that he couldn't even fix it on his own machine until Apple finally got off their asses and released a patch.
Problem is, Linux existed for the PC hardware before Windows did.
So, really, who chooses DOS over any sort of Unix?
And Windows, well, that fits nearly perfectly. X11 existed, and so did Mac OS. But Windows was quicker to market, cheaper than the Mac, and by the time anything like a usable desktop Linux existed, it was ubiquitous. So now, even though Windows is the worst OS in common use in so many ways, it's also better in that everything works on Windows.
Rarely, you get something both better and widespread. The web is an example -- Javascript is actually a really nice language, for one. Would I rather use another language? Sure, but true "worse is better" fashion would've had something like Java or Visual Basic in that role.
I can't believe no one's mentioned "worse is better" yet. An excerpt:
I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing
Another example would be Linux. It can be argued that Minix and Gnu HURD both likely had superior designs -- in fact, at the time, Linus fully expected Linux to become irrelevant once HURD was released. It never happened -- because Linux was available now, and was free and freely modifiable now, even though it was worse, it attracted enough developers so that it ultimately became more practical for most tasks.
And of course, the most obvious example is Windows. This follows the pattern:
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
DOS was an abomination, especially considering real OSes existed at the time. Windows 3.1 was barely more than a multiplexer for DOS, and Windows 95/98/ME were similarly backward abominations. Windows NT was unusable by ordinary users until Windows 2000, and why would power users prefer it over Unix?
Yet they were half the right thing, and they were usable by ordinary people, on the PC, faster and cheaper than anyone else.
The story mentions netbooks, but that's just the latest iteration of this. Remember, the original PCs weren't as powerful as minicomputers, which weren't as powerful as mainframes.
If you could duplicate that key you could decrypt the per-channel keys on any device, though you'd still need to have a valid subscription for the original card; you could share a subscription, but not avoid the bill altogether.
Not a problem.
And of course, there's still the Pirate Bay problem -- it only takes one person who's willing to pay the bill and record a given show.
But it's not trivial to to pull private keys out of the smart card
Would it be possible, then, to instead create a device which talks to the smart card?
it's probably feasible to crack, but not cheap and easy,
Granted. Most things aren't.
and therefore it's indifferent from impossible
Unless cracking it once can be replicated.
Anyway, thanks. That was informative -- lots of things I didn't know at all.
I think if the device is cheap enough to use single DES, it's not also going to be fast enough with that single DES to decrypt the entire multiplexed stream.
And how, exactly, are they distributing the new keys?
If the new keys are distributed encrypted with the old cipher, then my TV is delayed by exactly however long it takes to decrypt the first one -- and once I do that, I can still fastforward to the end.
If they're using a common shared key on the device, we only need to crack open one such device.
About the only way I could see this working is if each model had an individual private key and was tamper-proof -- but it seems to me that having to send so much data unicast to a single subscriber may break their network. Even then, it's for some value of "work" -- all we need is one person to either get around the tamper-proof-ness, or exploit an analog hole, and then record and upload their TV to the Internet -- then everyone gets it for free.
That, or the one inside man who can get access to the original recording before it's encrypted...
You're using 1k blocks. That's going to be much slower. Here's your test (shortened, because I didn't want to wait):
> dd if=/dev/zero of=test bs=1024 count=20000
20000+0 records in
20000+0 records out
20480000 bytes (20 MB) copied, 1.33289 s, 15.4 MB/s
> dd if=/dev/zero of=test bs=1048576 count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 0.469102 s, 44.7 MB/s
Slightly more data, yet faster. And it does somewhat sustain that:
> dd if=/dev/zero of=test bs=1048576 count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 65.6037 s, 32.7 MB/s
Keep in mind, this is on my external hard drive. It likes to buffer a lot (not sure if it's Linux, the drive, or ntfs-3g), so it makes sense that it's slower when sustained. But it's nowhere near as bad as your results.
I suppose it's possible I simply have a faster CPU, but it does seem like the killer here is the number of writes, not the size of them. I've certainly copied gigabytes onto and off of this drive without much issue.
Then again, I mostly use it for just that -- an external hard drive to throw movies onto. I'd never try to run a VM on top of it.
I haven't had NTFS-3G do this.
Granted, it's not always fast, but I haven't had it freeze.
MOST companies force you to sign a contract at time of employment that basically claims that anything you create while you are employed by the company is legally theirs.
These aren't always enforceable, and I certainly never signed one.
One is to protect their own asses... while you're busy coding at Adobe for their Great New Photoshop, you can't go home and use the ideas, even those YOU came up with at work, to create "Joe's Photomall" and suddenly turn around and start undercutting photoshop.
Then they should put a noncompete clause in -- which still isn't always enforceable.
In any case, this is why I read the more important contracts (like employment), and strike the stuff I don't agree with.
The SHA1 hashes may look scary at first, but it really is the best approach.
This is the only thing I'm not sure I agree with -- SHA1 is kind of weak by now, and it was already old-ish when Git was written.
But I definitely agree on that much -- I prefer a globally unique number (though maybe a GUID would be better?) to a kludgy attempt at preserving revision numbers.
There was actually another reason I preferred bzr -- it's written in Python. Git is written in C, Bash, and Perl, which means a lot steeper of a learning curve if I were to ever hack on it. But I'm starting to realize I'm about as likely to hack on Git as I am to hack on my filesystem -- rather than link against it, I can always write a script that calls git commands.
Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer?
No, but I could tell with a quick 'git log' of each.
Can you tell me when I would ever, ever need this? I never look at revision numbers outside of a log anyway. The last time I can remember caring what those numbers were, or holding them in my head for longer than a copy/paste (if that), is when I had to manually feed revision numbers into 'svn merge'.
Well, guess what? 'git merge' is smart enough to not need that. The "merge tracking" feature of SVN that's supposed to give it similar functionality also slows it down insanely -- merges should take seconds, not half an hour.
To me, it would make more sense if there was an incremental part to a git changelist id, even if it was "number of seconds since 2000" or something else unreadable,
Congrats! Two coders have now created exactly the same revision number, by committing on the same second!
Never mind that those are not exactly easy to tell, at a glance, which is greater. The epoch time now is 1251278556. Now it's 1251278604. Can you tell "at a glance" which is greater?
In fact, want to race? I bet I can run two 'git log' commands in the time your "glance" takes, with numbers like that.
you could ask someone "which revision crashed" and get back an answer you could easily use to tell if they were up-to-date or miles out of date.
If you're talking about programmers, just tell them to pull and try again -- it won't take long, and it won't break anything. Or ask them to run 'git log', and you'll get a date and time.
If you're talking about end-users, may as well put a date and time in the build, as part of the "version" information.
You can branch to your heart's content in Subversion.
Which is useless if you can't merge.
Git branches are not only much lower cost at the beginning (the command runs faster and is easier to use, and other users don't have to know about your branch until it's ready), but they merge much more easily.
The only difference is that Subversion is centralized, so you need a network connection to the server to commit.
Well, and that if the network connection or the server goes down, I can't work.
But to say that distributed is the only good thing about Git would be like saying that centralized is the only good thing about SVN.
Which would you rather use, SVN or CVS?
Then you can understand why I'd rather use Git, even in a centralized environment. In fact, I'd say the productivity gains for Git over SVN are probably greater than those of SVN over CVS.
It has changed, somewhat -- but mostly, I think there's just better documentation.
But, for example...
Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things
That is pretty fundamental to the design -- it's a SHA1 hash. It's also not incredibly difficult -- cut and paste. When your SVN revisions hit four and five digits, they don't really have much more meaning than that hash, do they?
Generally, you learn to use relative terms, instead -- for example, HEAD^ to refer to the revision just behind HEAD.
mercurial was much more straightforward
I thought so, too...
I think I tried mercurial, and then bzr, and eventually settled on Git for three reasons:
I should clarify that last part... Maybe some things are cryptic, and I'm sure I don't know all of the possible commands I could run -- but at a very basic level, I know exactly what's going on, just like I did in SVN.
Just for fun, here's the data model in a paragraph: There are commits. Each commit has a parent commit that it includes, except for merges, which have two parents. A branch is just a pointer to a commit.
That's it.
And knowing that, everything else starts to make sense... but it's more than I want to get into in a Slashdot post.
There is an occasional conflict, but you can't always avoid that.
Git avoids that a lot better than Subversion does. Yes, there's an "occasional" conflict, but much more rarely.
Call me a die hard, but I wouldn't trust Subversion's automatic merge feature. I do it all by hand
Yes, I've done that...
Doing it all by hand sucks -- it's a lot of manual effort to make sure you know exactly what you should be merging, and it still takes far longer to do that. Doing it with SVN's merge tracking sucks -- we had it to where it was taking half an hour, and could still fail.
I mean, I liked the model. I liked having a deep understanding of what it was doing.
But even by hand, even trying to disable all the merge tracking stuff, it still took minutes. And that's after doing the 'svn log' myself, trying to figure out exactly what should be merged...
In Git, I haven't found an operation that takes longer than seconds. Having five branches per developer is actually a perfectly sane and workable situation on Git -- having one branch per developer was a nightmare in SVN.
I doubt that anyone who's actually used a modern SCM can say with confidence that SVN merging doesn't suck. Half an hour for SVN vs one second for Git.
Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works.
Ok, yes, some tools do. For example, subversion supports trivial branching, but sucks at merging, so it encourages people to work on a common "trunk" branch. It also only supports a central server, so it "encourages" developing with a central server.
Git, on the other hand, "encourages" people to not put multi-gigabyte files in version control.
However, Git can be used to talk to an SVN repository. It can also talk to a central repository, or work purely via ssh between workstations, or with something like Gitjour, in a truly distributed fashion. Github is a strange and wonderful mutation of the two.
Perhaps, by making branches and merges so awesomely fast, Git "encourages" lots of little local branches, and keeping a neat patch history. But to sum it up:
SVN can handle large binary files and Windows better than Git, and is better integrated into IDEs.
Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.
Misses the point by quite a ways.
First, just enabling "power saver" isn't what I want. That laptop got those 9-12 hours of battery life, and was also fast and responsive when I needed it. Not incredibly fast (it was still Transmeta), but fast. So, this would be closer to "dynamic" if there's something similar.
Second, this isn't what I recommend, nor did I mean to imply that it's the only way to do things on Linux. I currently use KDE4, and I can point-and-click power management like the rest of you.
And finally, it was fun and hackish -- aside from the performance boost I got, I challenge you to show me as easy a method to have a Windows laptop scold people for pushing the power button.
What's funny is, girls did like that laptop.
These days, I have my priorities a bit saner. I run a Dell with Ubuntu, and while I am occasionally prone to scripting away annoyances, I spend far more time actually using my laptop than hacking it.
But then, I'm not particularly sure why I should have to prove myself to an Anonymous Coward. Ladies like confidence, too.
With recent laptops, I haven't noticed or cared, but I had a netbook before it was called a netbook -- the Sharp Actius MM10. And while I never tried it on Windows, it had one battery that supposedly lasts two and a half hours hours (that I remember lasting 3 hours), and another that supposedly lasts seven and a half hours (that I remember lasting 8-12 hours).
It's worth mentioning that I don't remember half the tweaks I did to this machine. With only a 15 gig hard drive and 256 megs of RAM, I installed Gentoo and used CFLAGS=-Os, custom-compiled my kernel complete with suspend patches and Reiser4 (practically a laptop mode all by itself), and otherwise modded it in every way known to man. I mean, I had a Fluxbox desktop with no menu, only the equivalent of alt+f2; because I didn't have any advanced power management running, I wrote my own Perl scripts to check the battery state, and to respond to ACPI events (lid closing locked it but didn't suspend, power button at various times would hibernate, or display a giant message saying "PLEASE DON'T PUSH THE POWER BUTTON, KTHNX"...
Also worth mentioning that Reiser4 wasn't the only prerelease software I used -- and it was prerelease, at the time. I backed it up frequently.
Still, I'm fairly surprised to learn that Linux battery life sucks on modern notebooks. My current machine was not built for battery life, so I've never actively run a test.
I suppose what's worse than that, though, is how much battery life sucks on modern notebooks, period, including netbooks. I admit the Transmeta chip felt sluggish, but on the other hand, can you buy any laptop today that'll run for nine hours on a charge, to where you can simply leave the power adapter plugged in at home for the day?
To me, Firefox feels like IE with most of the confusing graphics and stupid menu options taken out.
Well, and with more security. And decent support for web standards. And a huge collection of addons.
I mean, I agree with the disadvantages, but I don't agree that it's anywhere near as bad as IE.
One thing that annoyed me with Google Chrome is that they suddenly decide to design this Chrome OS thing based on Linux, yet Chrome browser seems to be continuously stuck on some kind of preview version and Windows version is always bang up-to-date.
Well, if the Linux version is anything like Android, I don't blame them. Android uses a non-standard libc, and it just gets weirder from there -- it's not X, for instance. Chrome OS is likely going to be very different than Linux -- at least as much as any one distro is from another, probably much worse.
There's a few things they've done very well with the Linux version:
First, it's actually open source. If you really don't like it, there's always Chromium. Example: I'm typing this on a 32-bit Google Chrome, because I decided to get it directly from Google. But Chromium already has a 64-bit version out.
Second, they actually made a Debian package. Just about every other piece of proprietary software for Linux is either a zip/tarball (which I can tolerate), or a script/executable, which is just irritating. I guess non-Debian distros will be annoyed...
And finally, rather than include some crappy auto-updater of their own, on Linux, they simply provided a repository -- thus integrating with system updates.
I don't really see much improvement over the previous years models at all.
Most of them are the same, it's true. But:
Sure in very recent history there have been improvements in fuel economy (hybrids, etc) but prior to that there hadn't been much difference in cars for 20 years.
And airbags. And side impact airbags. And minivans. And minivans with automatic doors.
I'm not saying a new car is a reason to get excited, but let me put it this way:
First of all, if you didn't have a car, would you refuse to buy one?
Second, if you had a good car from 20 years ago, would you refuse to buy one today, even if your old car ran just fine? (Some would, some wouldn't. But cars from 10, 20, 30 years ago represent about the change in looks you'd expect in a first person shooter over 5-10 years.)
And finally, even if it's just a slightly different body style and paint job, wouldn't you rather have, say, this car, or maybe this one, than the one you've got? Even if you answered "no", you probably see my point -- the reason you answered "no", I'll bet, has more to do with not liking those particular cars than with not being able to think of any car better than the one you've got.