Hardly. China has 1.5 million people in jail, only 0.1% of the population. The United States, by comparison, has 2.3 million people in jail, or 0.8% of the population. That's about eight times more, so let's not have the pot calling the kettle black.
>> Why is everyone so dismissive of x86_64? 64 bit is the future. > Yeah... that's some real solid, airtight logic, there.
In 2038, you might find out that "64 bit is the future" also has a literal meaning.
> 64-bit provided a modest-to-nonexistent performance improvement over x86.
I was talking about the architectural improvements, not performance. Having wider registers does not really give you any speed boost in most cases, since you seldom need more than 32bits for your numbers. Having more registers really is important, but it shows only in CPU-bound tasks, as demonstrated by the SSL tests in the link you provided. Register arguments help a lot, and the fact that floats can now be passed in SSE registers means that you can dedicate FPU registers solely to MMX, which can be a pretty darn important if you try to use MMX in generic templates. And, naturally, any assembly you hand-code is going to be far easier to write with those extra registers.
> even if you get, say, a 10% performance boost from the extra registers, it's still not even remotely worth the trouble.
Why isn't it worth the trouble? If everybody would get on board and make x64 the primary platform, as it ought to be, it's the 32bit people who'll be having trouble. Any trouble there is, exists because people ignore x64. And yes, 10% performance boost really is significant.
> back to the nineties that was the last time I used slackware. > Is it really any better for hardware support than Fedora or ubuntu?
Hardware support has nothing to do with the distribution. Hardware support is in the kernel, and the only time the distribution matters is when you're booting from it's installation CD. After that, you ought to custom compile a kernel anyway.
As for Slackware, the point is not hardware support. The point is simplicity. A Slackware install is about as close as you can get to a barebones system without doing the Linux-from-scratch thing. The configuration is very simple, if you are the type who prefers to edit files manually instead of drowning in stupid wizards. And the result is pure speed. I boot in 10 seconds, and it takes under three seconds to start X. Yes, I usually work on the console, and start X only for web browsing.
> I am amazed that all those games don't, in fact, run under Wine, or with the problems > you reported. Is it at all possible that they don't work for you as you have Slamd64?
I didn't actually try to run them, since I have not been able to get Wine to install. The results you see in the journal are what I found in Wine's AppDB, recorded by other people. I am not going to even bother trying a game until someone with an already working Wine reports it working. Until then, I simply wouldn't be able to tell if Wine doesn't support the game, or if Wine just isn't set up correctly on my machine, this latter being a very real possibility.
> BTW, I like the Fallout series myself, too.
Here's to us! Who's like us? Damn few! And they're aaall deead!
gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -w -Os -march=athlon64 -mfpmath=sse -D__i386__ -o interlocked.o interlocked.c {standard input}: Assembler messages: {standard input}:30: Error: suffix or operands invalid for `push' {standard input}:31: Error: suffix or operands invalid for `push' {standard input}:38: Error: suffix or operands invalid for `pop' {standard input}:39: Error: suffix or operands invalid for `pop' make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/home/sysadm/rpm/BUILD/wine/libs/port' make[1]: *** [port] Error 2
This means that there is unportably written assembly in there, utilizing things like push with 32bit args. Looking at the file I see a section for x86_64, but it looks like the i386 section is compiled instead. The configure message about having to define __i386__ might have something to do with this. Sure, this one is probably not too hard to fix, but if this one is there, there will be more. As I mentioned in the other thread, nobody cares about x86_64 for some reason. It is as if everyone hopes it would just go away. So if I submit this as a bug, they'll probably just hope I'll go away.
Heck, I don't even know how Wine is supposed to run 32bit Windows executables on my 64bit Linux. There might be some weird requirements of building some things as 32bit, some as 64bit and mixing the two in quaint ways. I'd also probably need to get the 32bit X libraries and whatever else Wine thinks it needs. It's just all such an unbelievable hassle, and in the end all I get is having to generate bug reports every fifteen minutes as Wine will crash again and again. Does this sound fun to you? It sounds like hard work to me. And all I really want from it is to run a game -- that is, to relax. Rather defeats the purpose, don't you think?
> more debugging info they can get and confirmation that bugs in the wine bugzilla are still valid
I think that the problem is not that they don't know how to get these games to run, but that they are a low priority. Most gamers today gravitate to Halo, HalfLife, and the like. The strategy gamers are a small minority. Almost nobody plays CTP any more, and even the more recent games, like Civ4 (which plays like garbage, coming from CTP). Same for single player RPGs like Fallout, which used to be one of the greatest games ever, but is now mostly forgotten. Sims2 is not something real men play:) And the rest are just obscure things that only I still have. Wine developers have a lot of work to do, and the more popular games work well. If you look at their bugs-to-fix list, you'll see that there are far more pressing problems to correct than getting Empire Earth to run.
> wow never heard of that distro,
www.slamd64.com. It's the 64 bit version of Slackware. You know, the one and only distribution that doesn't force you to install gigabytes of crap you'll never use that some package maintainer thought ought to be "required".
> but I think 64 bit will present you with some unique challenges. I guess you've got a reason to
Damn right I have a reason! I have a 64 bit CPU. Isn't that reason enough? I'm so sick and tired of people saying "oh, you are running 64bit? What, you need more than 4G of RAM?" Why is everyone so dismissive of x86_64? 64 bit is the future. The architecture is such an improvement over i386, it is no contest whatsoever, people. Get on the f*cking board already!
> You contribute the debug data from your attempts to assist getting them going or maintained those applications in the appDB?
Why should I? They already have the data from the person who tested them last time. The games I'm interested in do get retested occasionally without any help from me. Furthermore, I'm on Slamd64, so I don't get to use all those fancy prebuilt packages, and just compiling and installing Wine is a major ordeal, taking at least a few days of RTFM, frustration, and heavy cursing of every Wine developer. It just happens to be one of those applications where you can't do a 'make install' and have it work. No, they have this autoconfigurator, which doesn't work on my system, and a huge, out of date document on how to do it manually. Would I like to contribute? Maybe. But I just not interested in committing the amount of time and effort it would take. When I want to play, it is simpler and more reliable to just reboot into XP and have everything work.
Lighten up! Bioshock only took a month to crack. Now we know what's coming, so I bet Spore will get cracked within a week. Admit it, you crack all your games anyway, if only to get rid of the stupid CD check.
> Your stated hate for DRM leads me to believe that you couldn't bring yourself to actually > pay for any product that comes with any type of DRM. Assuming that you both want to play > this game and don't want to deal with the DRM, would you pirate it?
Actually, I do both. I preordered Bioshock and got to play it on the release date, which was fun. I also cracked it as soon as the crack was available, because I don't want the CD in the drive. It will be the same with Spore. I have it on preorder right now, so I'll get it immediately. If they really do let people play without the damn CD, it might take longer before I get a crack. But any DRM will have inconveniences, like the three install rule, so I'm pretty sure I'll end up cracking it eventually. Since I don't really care about other people's crappy creations, it won't be a big loss anyway. (And I'm sure someone will come up with a way to package all that content from the cache and share it by torrent)
> The problem is that there are project-related issues (delivery dates for example) which make > a lost repository a far more significant issue than just the labour cost of retyping the code.
I say this is a management issue, not a technical one. If the code is on a private branch, it is not good enough to be committed, which means it isn't going to be in the release anyway. So no, you won't miss a release just because somebody's disk crashes. But what if he was working on something critical, you'll say? If you are at a point just before a release, there should not be anything critical, or your release will be garbage. At the end of the cycle, all workitems should be very small, or your management needs firing. Remember, you only back up once a day anyway, so if someone's disk crashes intraday, their work will be lost in your svn setup just like it would be lost with git.
> the repository is just mirrored on a daily basis - so recovering the entire repository is > probably not half a day but an hour at most.
Are you including the time needed to get another hard disk? Do you have a spare you could plug in right now? Many people don't. Or maybe reinstall the OS, if that machine just happened to have only one drive in it. Some admins do that, especially if the boss is keen on cutting costs, as I'm sure you know.
> And the chances of losing it on a RAIDed server with all the usual bells and whistles are basically insignficant.
The smaller chance of failure is IMO easily offset by the critical nature of it. Your SVN repository is a single point of failure. If your server dies and the backups are bad, your company is dead meat. No kidding. No code, no product. No product, no money. No money, no company. It's that vital. If you are using git, losing a repository, a server, or any developer's machine barely qualifies as an inconvenience. A worrying type, like us, should find this a source of indescribable happiness. You really get more security with DVCS, not less.
> You may consider them "bits of crap" - but I'd rather have your work, no matter how crap > you consider it, somewhere where I'm relatively certain I can recover it if your laptop or PC craps out.
Why? The chances of hard drive failure are extremely low. In my entire life, I have only had it happen to me twice. If you don't buy used drives on eBay, it will probably never happen to you at all. But let's say it happens once every ten years. A temporary branch of the kind I was talking about is probably only one or two days of work at most (if more, you really should reduce the size of your workitems) $70/hour * 16 hours is $1120. More than that, the second time around I'll know exactly what I'm doing, so I'll be able to retype it in maybe half the time, so say $500. At the above failure rate, that's $50 per year per developer on top of their $140000 salary. And how much does it cost you to run your backups? Does this help put things in perspective?
> I appreciate that this is an advantage or working in a DVCS - but I think a better way of addressing > this issue would to have better branch/merge support in SVN rather than independent local repositories.
You're still missing the point. Backups just aren't as important in a DVCS, and that's a major feature. You are shaking in fear, lest your precious repository dies, and obsess over backing it up. But consider: if your central server goes down, how long would it take you to restore it from backup? In my experience with corporate IT, it takes at least half a day. During which nobody can do any work. No central server, no private branches, no nothing. How much productivity does that lose?
With git, everybody can keep working no matter what. In fact, they can immediately create a new "central" repository on another machine by pushing to a git server there. Time lost? None! No disruption to workflow at all, and you don't need to run backups of any kind.
I don't see what you are talking about. git timestamps every commit too.
> 2. move tracking: trying to move a directory branch from one dir to another means you lose history.
No you don't. If you use "git mv", like you're supposed to, history moves with you.
> 3. large files. Take a 100MB binary file into SVN, change one byte, commit. > Change one byte again. And again. Git will waste the freaking 100MB for every single commit.
No it won't. In fact, it will use less space than SVN for that commit. Yes, git supports diffs on any kind of file, and stores them that way. It didn't always, but the current version certainly does.
> 4. partial checkouts. If there's a 5GB repository, you'll often want to check out just a single dir.
That's what git submodules are for. Furthermore, git repositories are smaller than Subversion repositories by a large factor. At least twice, and I've seen as much as a tenfold reduction. Linux 2.6 repository is only 255M in size, and that's a huge project. Anything you do will likely be much smaller.
> 5. ease of use. I see that ordinary users, web monkeys and so on can learn SVN easily;
Bullshit. The commands are almost exactly the same. I don't know what people are complaining about.
> What worries me is that it encourages behaviour which leaves valuable changes sitting > on a disk which may not be backed up. I see changes being made to a codebase like valuable > little bits of gold which need to be kept somewhere nice and safe
As a developer, I'll tell you that not all changes are "little bits of gold". Sometimes I just want to try something out, and end up with little bits of crap. The way to think about local changes is the same way you think about non-committed changes to your Subversion repository. In Subversion, I will have plenty of changes sitting on my disk, they just won't be committed until I am satisfied with them. In git, I can commit as many times as I like to my local repository and push only the final version to the central branch. This way I can checkpoint my code with intermediate commits. This is extremely valuable, since those checkpoints might not even work at all, and I would never want them to break the main build, but I can still break up my task into little subtasks and redo or revise each one of them in turn. These subtasks are not backed up in your scenario either, and are much harder to manager there.
> maybe you could redirect some of the party planning effort into gathering the courage to tell her how you feel?
That's a lousy idea. He wants her to have a good time on her birthday. Having to dump a good friend of hers is nobody's idea of a good time. Be serious people, nobody wants to date nerds. If he has this little love fantasy going, good for him. Why set himself up for disillusionment? It will really get in the way of living happily ever after and dying a virgin.
There is a big kernel warning that pops up in 2.6.25, saying that SMBFS is obsolete and will be removed by 2.6.27. As someone who has never even heard of CIFS until I saw that, my first reaction was "OMG, those Linux guys broke Samba! I'm so screwed!". I think that there are quite a few other people who will feel the same way when they try to mount a windows share.
Has anyone noticed the forced CIFS migration warning yet? Do you have some links on how to do that? I mean just the obvious two things of being able to mount a remote windows share (preferably without being root), and setting up CUPS for printing to a windows-shared printer. All I see on Google are technical articles about the protocol.
Don't worry. Even raytracing will not help you if you can't draw. All I see in your future is beautifully rendered and geometrically perfect utter garbage.
> if you're having a problem with a section of code, have a man come through the door holding a gun in his hand.
Unfortunately, if you are having problem with spaghetti code, like I am, your man would have to crawl on his belly for several miles in twisty passages all alike before reaching the actual problem.
Slashdot Mirror
> are in jail
Hardly. China has 1.5 million people in jail, only 0.1% of the population. The United States, by comparison, has 2.3 million people in jail, or 0.8% of the population. That's about eight times more, so let's not have the pot calling the kettle black.
Open Source programmers are getting older, and many eyes are getting blurry.
>> Why is everyone so dismissive of x86_64? 64 bit is the future.
> Yeah... that's some real solid, airtight logic, there.
In 2038, you might find out that "64 bit is the future" also has a literal meaning.
> 64-bit provided a modest-to-nonexistent performance improvement over x86.
I was talking about the architectural improvements, not performance. Having wider registers does not really give you any speed boost in most cases, since you seldom need more than 32bits for your numbers. Having more registers really is important, but it shows only in CPU-bound tasks, as demonstrated by the SSL tests in the link you provided. Register arguments help a lot, and the fact that floats can now be passed in SSE registers means that you can dedicate FPU registers solely to MMX, which can be a pretty darn important if you try to use MMX in generic templates. And, naturally, any assembly you hand-code is going to be far easier to write with those extra registers.
> even if you get, say, a 10% performance boost from the extra registers, it's still not even remotely worth the trouble.
Why isn't it worth the trouble? If everybody would get on board and make x64 the primary platform, as it ought to be, it's the 32bit people who'll be having trouble. Any trouble there is, exists because people ignore x64. And yes, 10% performance boost really is significant.
> back to the nineties that was the last time I used slackware.
> Is it really any better for hardware support than Fedora or ubuntu?
Hardware support has nothing to do with the distribution. Hardware support is in the kernel, and the only time the distribution matters is when you're booting from it's installation CD. After that, you ought to custom compile a kernel anyway.
As for Slackware, the point is not hardware support. The point is simplicity. A Slackware install is about as close as you can get to a barebones system without doing the Linux-from-scratch thing. The configuration is very simple, if you are the type who prefers to edit files manually instead of drowning in stupid wizards. And the result is pure speed. I boot in 10 seconds, and it takes under three seconds to start X. Yes, I usually work on the console, and start X only for web browsing.
> I am amazed that all those games don't, in fact, run under Wine, or with the problems
> you reported. Is it at all possible that they don't work for you as you have Slamd64?
I didn't actually try to run them, since I have not been able to get Wine to install. The results you see in the journal are what I found in Wine's AppDB, recorded by other people. I am not going to even bother trying a game until someone with an already working Wine reports it working. Until then, I simply wouldn't be able to tell if Wine doesn't support the game, or if Wine just isn't set up correctly on my machine, this latter being a very real possibility.
> BTW, I like the Fallout series myself, too.
Here's to us!
Who's like us?
Damn few!
And they're aaall deead!
> git clone ./configure
>
> make
Easy for you to say. I get:
gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -w -Os -march=athlon64 -mfpmath=sse -D__i386__ -o interlocked.o interlocked.c
{standard input}: Assembler messages:
{standard input}:30: Error: suffix or operands invalid for `push'
{standard input}:31: Error: suffix or operands invalid for `push'
{standard input}:38: Error: suffix or operands invalid for `pop'
{standard input}:39: Error: suffix or operands invalid for `pop'
make[2]: *** [interlocked.o] Error 1
make[2]: Leaving directory `/home/sysadm/rpm/BUILD/wine/libs/port'
make[1]: *** [port] Error 2
This means that there is unportably written assembly in there, utilizing things like push with 32bit args. Looking at the file I see a section for x86_64, but it looks like the i386 section is compiled instead. The configure message about having to define __i386__ might have something to do with this. Sure, this one is probably not too hard to fix, but if this one is there, there will be more. As I mentioned in the other thread, nobody cares about x86_64 for some reason. It is as if everyone hopes it would just go away. So if I submit this as a bug, they'll probably just hope I'll go away.
Heck, I don't even know how Wine is supposed to run 32bit Windows executables on my 64bit Linux. There might be some weird requirements of building some things as 32bit, some as 64bit and mixing the two in quaint ways. I'd also probably need to get the 32bit X libraries and whatever else Wine thinks it needs. It's just all such an unbelievable hassle, and in the end all I get is having to generate bug reports every fifteen minutes as Wine will crash again and again. Does this sound fun to you? It sounds like hard work to me. And all I really want from it is to run a game -- that is, to relax. Rather defeats the purpose, don't you think?
> more debugging info they can get and confirmation that bugs in the wine bugzilla are still valid
:) And the rest are just obscure things that only I still have. Wine developers have a lot of work to do, and the more popular games work well. If you look at their bugs-to-fix list, you'll see that there are far more pressing problems to correct than getting Empire Earth to run.
I think that the problem is not that they don't know how to get these games to run, but that they are a low priority. Most gamers today gravitate to Halo, HalfLife, and the like. The strategy gamers are a small minority. Almost nobody plays CTP any more, and even the more recent games, like Civ4 (which plays like garbage, coming from CTP). Same for single player RPGs like Fallout, which used to be one of the greatest games ever, but is now mostly forgotten. Sims2 is not something real men play
> wow never heard of that distro,
www.slamd64.com. It's the 64 bit version of Slackware. You know, the one and only distribution that doesn't force you to install gigabytes of crap you'll never use that some package maintainer thought ought to be "required".
> but I think 64 bit will present you with some unique challenges. I guess you've got a reason to
Damn right I have a reason! I have a 64 bit CPU. Isn't that reason enough? I'm so sick and tired of people saying "oh, you are running 64bit? What, you need more than 4G of RAM?" Why is everyone so dismissive of x86_64? 64 bit is the future. The architecture is such an improvement over i386, it is no contest whatsoever, people. Get on the f*cking board already!
> You contribute the debug data from your attempts to assist getting them going or maintained those applications in the appDB?
Why should I? They already have the data from the person who tested them last time. The games I'm interested in do get retested occasionally without any help from me. Furthermore, I'm on Slamd64, so I don't get to use all those fancy prebuilt packages, and just compiling and installing Wine is a major ordeal, taking at least a few days of RTFM, frustration, and heavy cursing of every Wine developer. It just happens to be one of those applications where you can't do a 'make install' and have it work. No, they have this autoconfigurator, which doesn't work on my system, and a huge, out of date document on how to do it manually. Would I like to contribute? Maybe. But I just not interested in committing the amount of time and effort it would take. When I want to play, it is simpler and more reliable to just reboot into XP and have everything work.
Lighten up! Bioshock only took a month to crack. Now we know what's coming, so I bet Spore will get cracked within a week. Admit it, you crack all your games anyway, if only to get rid of the stupid CD check.
> Your stated hate for DRM leads me to believe that you couldn't bring yourself to actually
> pay for any product that comes with any type of DRM. Assuming that you both want to play
> this game and don't want to deal with the DRM, would you pirate it?
Actually, I do both. I preordered Bioshock and got to play it on the release date, which was fun. I also cracked it as soon as the crack was available, because I don't want the CD in the drive. It will be the same with Spore. I have it on preorder right now, so I'll get it immediately. If they really do let people play without the damn CD, it might take longer before I get a crack. But any DRM will have inconveniences, like the three install rule, so I'm pretty sure I'll end up cracking it eventually. Since I don't really care about other people's crappy creations, it won't be a big loss anyway. (And I'm sure someone will come up with a way to package all that content from the cache and share it by torrent)
I hope so. I'll be less skeptical when Wine can run the games I actually play. CivCTP, for example, still doesn't work.
> The problem is that there are project-related issues (delivery dates for example) which make
> a lost repository a far more significant issue than just the labour cost of retyping the code.
I say this is a management issue, not a technical one. If the code is on a private branch, it is not good enough to be committed, which means it isn't going to be in the release anyway. So no, you won't miss a release just because somebody's disk crashes. But what if he was working on something critical, you'll say? If you are at a point just before a release, there should not be anything critical, or your release will be garbage. At the end of the cycle, all workitems should be very small, or your management needs firing. Remember, you only back up once a day anyway, so if someone's disk crashes intraday, their work will be lost in your svn setup just like it would be lost with git.
> the repository is just mirrored on a daily basis - so recovering the entire repository is
> probably not half a day but an hour at most.
Are you including the time needed to get another hard disk? Do you have a spare you could plug in right now? Many people don't. Or maybe reinstall the OS, if that machine just happened to have only one drive in it. Some admins do that, especially if the boss is keen on cutting costs, as I'm sure you know.
> And the chances of losing it on a RAIDed server with all the usual bells and whistles are basically insignficant.
The smaller chance of failure is IMO easily offset by the critical nature of it. Your SVN repository is a single point of failure. If your server dies and the backups are bad, your company is dead meat. No kidding. No code, no product. No product, no money. No money, no company. It's that vital. If you are using git, losing a repository, a server, or any developer's machine barely qualifies as an inconvenience. A worrying type, like us, should find this a source of indescribable happiness. You really get more security with DVCS, not less.
> You may consider them "bits of crap" - but I'd rather have your work, no matter how crap
> you consider it, somewhere where I'm relatively certain I can recover it if your laptop or PC craps out.
Why? The chances of hard drive failure are extremely low. In my entire life, I have only had it happen to me twice. If you don't buy used drives on eBay, it will probably never happen to you at all. But let's say it happens once every ten years. A temporary branch of the kind I was talking about is probably only one or two days of work at most (if more, you really should reduce the size of your workitems) $70/hour * 16 hours is $1120. More than that, the second time around I'll know exactly what I'm doing, so I'll be able to retype it in maybe half the time, so say $500. At the above failure rate, that's $50 per year per developer on top of their $140000 salary. And how much does it cost you to run your backups? Does this help put things in perspective?
> I appreciate that this is an advantage or working in a DVCS - but I think a better way of addressing
> this issue would to have better branch/merge support in SVN rather than independent local repositories.
You're still missing the point. Backups just aren't as important in a DVCS, and that's a major feature. You are shaking in fear, lest your precious repository dies, and obsess over backing it up. But consider: if your central server goes down, how long would it take you to restore it from backup? In my experience with corporate IT, it takes at least half a day. During which nobody can do any work. No central server, no private branches, no nothing. How much productivity does that lose?
With git, everybody can keep working no matter what. In fact, they can immediately create a new "central" repository on another machine by pushing to a git server there. Time lost? None! No disruption to workflow at all, and you don't need to run backups of any kind.
> 1. timestamps.
I don't see what you are talking about. git timestamps every commit too.
> 2. move tracking: trying to move a directory branch from one dir to another means you lose history.
No you don't. If you use "git mv", like you're supposed to, history moves with you.
> 3. large files. Take a 100MB binary file into SVN, change one byte, commit.
> Change one byte again. And again. Git will waste the freaking 100MB for every single commit.
No it won't. In fact, it will use less space than SVN for that commit. Yes, git supports diffs on any kind of file, and stores them that way. It didn't always, but the current version certainly does.
> 4. partial checkouts. If there's a 5GB repository, you'll often want to check out just a single dir.
That's what git submodules are for. Furthermore, git repositories are smaller than Subversion repositories by a large factor. At least twice, and I've seen as much as a tenfold reduction. Linux 2.6 repository is only 255M in size, and that's a huge project. Anything you do will likely be much smaller.
> 5. ease of use. I see that ordinary users, web monkeys and so on can learn SVN easily;
Bullshit. The commands are almost exactly the same. I don't know what people are complaining about.
> What worries me is that it encourages behaviour which leaves valuable changes sitting
> on a disk which may not be backed up. I see changes being made to a codebase like valuable
> little bits of gold which need to be kept somewhere nice and safe
As a developer, I'll tell you that not all changes are "little bits of gold". Sometimes I just want to try something out, and end up with little bits of crap. The way to think about local changes is the same way you think about non-committed changes to your Subversion repository. In Subversion, I will have plenty of changes sitting on my disk, they just won't be committed until I am satisfied with them. In git, I can commit as many times as I like to my local repository and push only the final version to the central branch. This way I can checkpoint my code with intermediate commits. This is extremely valuable, since those checkpoints might not even work at all, and I would never want them to break the main build, but I can still break up my task into little subtasks and redo or revise each one of them in turn. These subtasks are not backed up in your scenario either, and are much harder to manager there.
> var int smoke=I*R;
Voltage does not cause smoke. Power causes smoke, so if that were what you wanted, you'd say smoke=I*I*R.
> Beer. It is one of the greatest agents in the world for reducing people's good judgment
Here's the other one: www.fastseduction.com
> maybe you could redirect some of the party planning effort into gathering the courage to tell her how you feel?
That's a lousy idea. He wants her to have a good time on her birthday. Having to dump a good friend of hers is nobody's idea of a good time. Be serious people, nobody wants to date nerds. If he has this little love fantasy going, good for him. Why set himself up for disillusionment? It will really get in the way of living happily ever after and dying a virgin.
> i'm not 100% sure on what you're asking,
There is a big kernel warning that pops up in 2.6.25, saying that SMBFS is obsolete and will be removed by 2.6.27. As someone who has never even heard of CIFS until I saw that, my first reaction was "OMG, those Linux guys broke Samba! I'm so screwed!". I think that there are quite a few other people who will feel the same way when they try to mount a windows share.
> http://www.gentoo-wiki.com/HOWTO_Setup_Samba
I'll copy the link, in case you don't get modded up. It seems that I'll only need to change the filesystem type in fstab, so it isn't a catastrophe.
Has anyone noticed the forced CIFS migration warning yet? Do you have some links on how to do that? I mean just the obvious two things of being able to mount a remote windows share (preferably without being root), and setting up CUPS for printing to a windows-shared printer. All I see on Google are technical articles about the protocol.
>> In what country?
> Your current country. Walking is best and most easily accomplished in the country where you are.
Unless that country is the United States.
Don't worry. Even raytracing will not help you if you can't draw. All I see in your future is beautifully rendered and geometrically perfect utter garbage.
> because version-control (check-in/check-out) logs will betray you :)
Do I get bonus points if my mod passes code review and gets checked in?
> When you can figure out a way to make public key encryption so easy even my mother can use it I'll be happy to try.
Try enigmail.
> if you're having a problem with a section of code, have a man come through the door holding a gun in his hand.
Unfortunately, if you are having problem with spaghetti code, like I am, your man would have to crawl on his belly for several miles in twisty passages all alike before reaching the actual problem.