To annotate = to add notes to, so yes, it's a pretty accurate description (at least for Mercurial, where it prepends each line with the last revision in which that line was changed—I've never tried it in Subversion, so I'm not sure how it works there).
About blame:
svn help blame
blame (praise, annotate, ann) [...]
It's just an alias. If you want, you can praise! How is that for positive! Or ann, or annotate, if you're not into the brevity thing.
I'm aware of that, which is why I tacked that part on as a parenthetical comment. It wouldn't have a significant effect on my choice of SCMS, but if I did end up using Subversion, it would probably contribute a bit of extra stress from annoyance every time I happened across text (like "svn help") showing the "blame" command. (FWIW, Mercurial has the "blame" alias as well, but at least hides it from the "hg help" command list.) It's probably just me, but I prefer my tools to be neutral, direct and to the point, without extra cuteness.
I agree with the proposition that the mouse is essentially a substitute for touch-screen control, and given my own usage patterns, I could probably do away with my mouse for pretty much everything except drawing in GIMP. (Those of you talking about how people can't hold their arms out for hours on end: Do you really sit around with one hand on the mouse for hours on end, rather than both hands on the keyboard most of the time? I don't know, maybe you do; just something to think about.) There are certainly interface issues to be dealt with, like the fact that you can't "hover" or click with multiple buttons, but I think the iPhone has shown that it's quite possible to deal with them. As for fingerprints--think of it as an incentive to practice good hygiene; do you really want to know what's living on the surface of your mouse? So to the extent they suggest touch-based controls will become mainstream for PCs, I consider that likely.
On the other hand, for the aforementioned case of drawing and similar cases where fine, continuous control is needed, the mouse definitely wins out: it's flat on the desk, it gives you pinpoint precision, and you can map large mouse movements to finer pointer motion. (You could use a zoomable tablet and stylus, granted, but would you want to be hunched over a horizontal display for hours on end?) So I wouldn't go so far as to say the mouse is headed for extinction. It'll simply be one tool in a growing toolbox.
I don't know whether you were speaking from experience or just making a general comment, but have you tried looking into Mercurial as an alternative? It's a distributed SCMS, meaning everybody commits to their own copy of the repository and then pushes those commits to a central repository (if you go with a CVS/SVN-like centralized setup). The Mercurial interface is designed to work more or less like CVS and Subversion, and it uses patchsets and repository-wide versioning like Subversion, but it has this nifty command called "rollback" that lets you undo your most recent commit, provided you haven't pushed the commit anywhere else yet. I switched a 200k-line project over from CVS recently--avoiding Subversion for exactly the reason you give--and it's worked fine for me so far; I even stopped mirroring my commits back to the old CVS repository because it was so much easier to roll back accidental commits in Mercurial. Being able to commit individual changes when I'm on the road without a net connection, rather than saving them all for when I get home and trying to separate out the changes afterward, is a nice bonus as well. (And I have to admit, I like how Mercurial names its "annotate" command "annotate" rather than Subversion's immature-sounding "blame", though admittedly not all the documentation is up to quite the same standard.)
That said, Mercurial's toolset isn't nearly as full-fledged as Subversion's. In particular, there doesn't seem to be an explicit equivalent to Subversion's dump/load process, so if you want to obliterate a commit other than the last one you're pretty much out of luck (though it might work to hg export everything but the problem patch and then hg import to an empty repository). You also have to deal with the fact that "revision numbers" are no longer constant except within a single copy of the repository, and you have to refer to hexadecimal node names if you want to talk about a specific patchset with anyone else. For my project, I treat the revision numbers of the central repository as canonical, and when building the project, I include the node name as part of the build ID when building from any other repository.
make it triple buffering with 64 bpp (for what, exactly, I don't know. But it's a worst case scenario), and you're still only at 90 megs.
64bpp probably isn't too common, but how about 128bpp: 32-bit float channels for ARGB. Sure, you won't need all those bits for display, but they come in handy if you want to apply effects to the graphic data. (Whether framebuffer manipulation is a performance win compared to pixel shaders for any given operation is a separate question, and admittedly one I haven't investigated.)
In a sufficiently small election (say, a local election in a municipality of a few thousand people), you're right, there's not much difference. From the viewpoint of the required set of skills, it may even be easier to rig a paper-based election: just get one or two people in the right place, whip up a batch of fake ballots, and you're ready to go—no 1337 skillz needed.
On the other hand, when you're talking national or other large-scale elections, things flip around. With a paper ballot, you have to have people to handle things in every election district you want to influence; and naturally, as you add more people, you increase the risk of someone blabbing and spoiling your whole plan. With an electronic system, however, you only have to break the election software once if you do it in the right place. (Paper trails can help defend against this, but they're not necessarily foolproof; you just have to be cleverer.)
The gory details aren't as simple as this, of course, but that's basically why people worry about electronic voting as opposed to paper ballots.
At the average 40Mbps upstream I get, I could theoretically hit that with just 100 minutes of uploading a day. In fact, I routinely transfer gigabyte-range files to and from the office server, so it's not out of the question for me to break the limit every once in a while. (Then again, I have a business-class connection for my personal server, so I'm not worried.)
This is not a pimply faced youth's porn and music collection - this is important data that can save or destroy lives depending how it is handled and accessed.
Then you'd be using a business-class connection anyway, which isn't affected by the limit.
They want you to calculate your foreign purchases yourself and document them for your reimbursement. Hell no. They should pay us $400/hr as they do their lawyers for the time we spend sorting through years worth of credit card statements.
You might not play the same tune if you had over $25k of foreign currency purchases during the relevant period. (And it only took me about 30 minutes to work that out, so filing's a win even under your suggestion.)
I know I "see" something like a flash of light whenever someone turns on a fluorescent light with magnetic ballast in another room - so I don't think the idea of additional senses is completely crazy.
Actually, that'd probably just be noise from the current spike--sort of like the click you can hear from a speaker in the same circumstances.
A hundred thousand fucking dollars for reading out loud?
Voice acting isn't just "reading out loud", the same way movie acting isn't just walking around a stage. Voice actors have to be expressive, able to inject all sorts of emotions into their readings, able to laugh or scream or cry as necessary--and have to be able to do it on short notice, without reading through an entire scene every time, often without being able to hear the other characters they're interacting with--and have to stay in sync with whatever animation they're voicing. It may or may not be worth $100k a game to be able to do that, but it's not something you can just grab J. Random Sixpack off the street for.
I started looking about half a year before I actually quit my first job. At least here in Tokyo, various recruiting companies run job fairs every couple of months or so--look for train posters that talk about a "tenshoku fair" or "tekishoku fair". I stopped by one of those and talked with a few companies, of which one was where I ended up going. We went back and forth a few times before coming to an agreement; the money was the tough part, of course, but we were able to compromise so that I'd have an initially lower salary--closer to what a typical Japanese salaryman would make--which would rapidly jump up once I'd demonstrated my skills. (Yes, I did get it in writing, and they did follow along with it. Sadly, the company president later passed away from a sudden stroke, so I've since moved elsewhere.)
That said, I have to acknowledge that a certain proficiency in Japanese is pretty much required for anything outside teaching English, especially anywhere outside foreigner-full Tokyo. It's not so much that the language barrier is an impediment to getting work done, as it is that people just feel uncomfortable having their ordinary monolingual, monocultural environment disturbed--though given the stress that Japanese companies tend to place on their workers, I suppose I can't really blame them (the workers). So when you go looking, and especially if you go anywhere for an interview, I'd suggest avoiding any focus on your status as a foreigner; if they ask about how you're getting along in Japan, for example, emphasize how well you get along with your (Japanese) friends or current coworkers rather than talking about all the differences you had to adjust to on coming here. The latter is certainly interesting conversation material, but will tend to make people who don't know you subconsciously edge away.
And I should know--I left exactly that kind of job at an NTT subsidiary (despite having that rarest of rarities: an intelligent, competent, understanding boss) for a much smaller software company, and negotiated a salary more than twice what I had been making earlier, even taking into account that I couldn't live in a $70/month apartment anymore. It's totally possible to make a decent living here if you're willing to push for it.
Of course, given the way Japanese society works, I imagine most people here don't even consider the possibility of salary negotioations.
Skype ripped off some GPL code.
After they got caught out, it went to court.
After some months toing and froing, Skype lost a lower court settlement.
Skype took it to a higher court.
Later that day, the appeals judge slaps them down, hard.
The next day, Skype drops the case.
Think of what happens now: The shareholders of Yahoo are going to go ballistic. Yahoo management just left $47.5 billion on the table!
Assuming, of course, that said shareholders think Microsoft was actually going to let Yahoo live. I don't think I'd have been that optimistic (but then again, I don't hold any YHOO anyway).
And something similar goes for width:
"Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
I don't suppose anyone's ever pointed out that this isn't actually a valid answer to the question? I agree that 3 levels of indentation is a good limit, but that doesn't make it any easier for my eyes to track the code across those huge horizontal jumps, whereas 4 spaces per indent is much more relaxing to read. (Actually, I have a feeling 5 would be even easier, but old habits die hard . ..)
FWIW, it worked for me when I disabled Javascript completely. But it's not worth it to me to go and disable Javascript just to see the comic, so it's gone from my bookmarks too.
Jukinet has been up and running for years, but the central government has been unable to force take-up
This isn't quite accurate; almost nobody has the card, true, but the data itself is being stored nonetheless. The card only serves as the token to pull out your specific record from the database.
That said, there are still a few municipalities that are refusing to connect their systems to the juuki-net. The most well-known is Yamatsuri-cho in Fukushima, which has held out from the start due to concerns about data security (and despite the central government declaring their refusal to connect "illegal"). There's also Suginami-ku in Tokyo and Kawasaki City, if I recall correctly.
Slashdot Mirror
How did they solve the technical problem of the torch run? Wouldn't the flame go out without access to oxygen?
Well, I haven't read the story, but given that they've already solved that problem for humans, it can't be too much of an issue.
but it is NaN times more expensive than OpenOffice.org!
Really? If it's free, I guess I might as well look into it, huh?
(Hint: 1/0 == inf; 0/0 == nan)
To annotate = to add notes to, so yes, it's a pretty accurate description (at least for Mercurial, where it prepends each line with the last revision in which that line was changed—I've never tried it in Subversion, so I'm not sure how it works there).
About blame:
svn help blame
blame (praise, annotate, ann) [...]
It's just an alias. If you want, you can praise! How is that for positive! Or ann, or annotate, if you're not into the brevity thing.
I'm aware of that, which is why I tacked that part on as a parenthetical comment. It wouldn't have a significant effect on my choice of SCMS, but if I did end up using Subversion, it would probably contribute a bit of extra stress from annoyance every time I happened across text (like "svn help") showing the "blame" command. (FWIW, Mercurial has the "blame" alias as well, but at least hides it from the "hg help" command list.) It's probably just me, but I prefer my tools to be neutral, direct and to the point, without extra cuteness.
I agree with the proposition that the mouse is essentially a substitute for touch-screen control, and given my own usage patterns, I could probably do away with my mouse for pretty much everything except drawing in GIMP. (Those of you talking about how people can't hold their arms out for hours on end: Do you really sit around with one hand on the mouse for hours on end, rather than both hands on the keyboard most of the time? I don't know, maybe you do; just something to think about.) There are certainly interface issues to be dealt with, like the fact that you can't "hover" or click with multiple buttons, but I think the iPhone has shown that it's quite possible to deal with them. As for fingerprints--think of it as an incentive to practice good hygiene; do you really want to know what's living on the surface of your mouse? So to the extent they suggest touch-based controls will become mainstream for PCs, I consider that likely.
On the other hand, for the aforementioned case of drawing and similar cases where fine, continuous control is needed, the mouse definitely wins out: it's flat on the desk, it gives you pinpoint precision, and you can map large mouse movements to finer pointer motion. (You could use a zoomable tablet and stylus, granted, but would you want to be hunched over a horizontal display for hours on end?) So I wouldn't go so far as to say the mouse is headed for extinction. It'll simply be one tool in a growing toolbox.
I don't know whether you were speaking from experience or just making a general comment, but have you tried looking into Mercurial as an alternative? It's a distributed SCMS, meaning everybody commits to their own copy of the repository and then pushes those commits to a central repository (if you go with a CVS/SVN-like centralized setup). The Mercurial interface is designed to work more or less like CVS and Subversion, and it uses patchsets and repository-wide versioning like Subversion, but it has this nifty command called "rollback" that lets you undo your most recent commit, provided you haven't pushed the commit anywhere else yet. I switched a 200k-line project over from CVS recently--avoiding Subversion for exactly the reason you give--and it's worked fine for me so far; I even stopped mirroring my commits back to the old CVS repository because it was so much easier to roll back accidental commits in Mercurial. Being able to commit individual changes when I'm on the road without a net connection, rather than saving them all for when I get home and trying to separate out the changes afterward, is a nice bonus as well. (And I have to admit, I like how Mercurial names its "annotate" command "annotate" rather than Subversion's immature-sounding "blame", though admittedly not all the documentation is up to quite the same standard.)
That said, Mercurial's toolset isn't nearly as full-fledged as Subversion's. In particular, there doesn't seem to be an explicit equivalent to Subversion's dump/load process, so if you want to obliterate a commit other than the last one you're pretty much out of luck (though it might work to hg export everything but the problem patch and then hg import to an empty repository). You also have to deal with the fact that "revision numbers" are no longer constant except within a single copy of the repository, and you have to refer to hexadecimal node names if you want to talk about a specific patchset with anyone else. For my project, I treat the revision numbers of the central repository as canonical, and when building the project, I include the node name as part of the build ID when building from any other repository.
make it triple buffering with 64 bpp (for what, exactly, I don't know. But it's a worst case scenario), and you're still only at 90 megs.
64bpp probably isn't too common, but how about 128bpp: 32-bit float channels for ARGB. Sure, you won't need all those bits for display, but they come in handy if you want to apply effects to the graphic data. (Whether framebuffer manipulation is a performance win compared to pixel shaders for any given operation is a separate question, and admittedly one I haven't investigated.)
In a sufficiently small election (say, a local election in a municipality of a few thousand people), you're right, there's not much difference. From the viewpoint of the required set of skills, it may even be easier to rig a paper-based election: just get one or two people in the right place, whip up a batch of fake ballots, and you're ready to go—no 1337 skillz needed.
On the other hand, when you're talking national or other large-scale elections, things flip around. With a paper ballot, you have to have people to handle things in every election district you want to influence; and naturally, as you add more people, you increase the risk of someone blabbing and spoiling your whole plan. With an electronic system, however, you only have to break the election software once if you do it in the right place. (Paper trails can help defend against this, but they're not necessarily foolproof; you just have to be cleverer.)
The gory details aren't as simple as this, of course, but that's basically why people worry about electronic voting as opposed to paper ballots.
30GB/day = 240,000,000,000 bits / 86400 seconds ~= 2.8Mbps
At the average 40Mbps upstream I get, I could theoretically hit that with just 100 minutes of uploading a day. In fact, I routinely transfer gigabyte-range files to and from the office server, so it's not out of the question for me to break the limit every once in a while. (Then again, I have a business-class connection for my personal server, so I'm not worried.)
This is not a pimply faced youth's porn and music collection - this is important data that can save or destroy lives depending how it is handled and accessed.
Then you'd be using a business-class connection anyway, which isn't affected by the limit.
as can be seen from the 103-degree fever.
They want you to calculate your foreign purchases yourself and document them for your reimbursement. Hell no. They should pay us $400/hr as they do their lawyers for the time we spend sorting through years worth of credit card statements.
You might not play the same tune if you had over $25k of foreign currency purchases during the relevant period. (And it only took me about 30 minutes to work that out, so filing's a win even under your suggestion.)
Actually, that'd probably just be noise from the current spike--sort of like the click you can hear from a speaker in the same circumstances.
Voice acting isn't just "reading out loud", the same way movie acting isn't just walking around a stage. Voice actors have to be expressive, able to inject all sorts of emotions into their readings, able to laugh or scream or cry as necessary--and have to be able to do it on short notice, without reading through an entire scene every time, often without being able to hear the other characters they're interacting with--and have to stay in sync with whatever animation they're voicing. It may or may not be worth $100k a game to be able to do that, but it's not something you can just grab J. Random Sixpack off the street for.
I started looking about half a year before I actually quit my first job. At least here in Tokyo, various recruiting companies run job fairs every couple of months or so--look for train posters that talk about a "tenshoku fair" or "tekishoku fair". I stopped by one of those and talked with a few companies, of which one was where I ended up going. We went back and forth a few times before coming to an agreement; the money was the tough part, of course, but we were able to compromise so that I'd have an initially lower salary--closer to what a typical Japanese salaryman would make--which would rapidly jump up once I'd demonstrated my skills. (Yes, I did get it in writing, and they did follow along with it. Sadly, the company president later passed away from a sudden stroke, so I've since moved elsewhere.)
That said, I have to acknowledge that a certain proficiency in Japanese is pretty much required for anything outside teaching English, especially anywhere outside foreigner-full Tokyo. It's not so much that the language barrier is an impediment to getting work done, as it is that people just feel uncomfortable having their ordinary monolingual, monocultural environment disturbed--though given the stress that Japanese companies tend to place on their workers, I suppose I can't really blame them (the workers). So when you go looking, and especially if you go anywhere for an interview, I'd suggest avoiding any focus on your status as a foreigner; if they ask about how you're getting along in Japan, for example, emphasize how well you get along with your (Japanese) friends or current coworkers rather than talking about all the differences you had to adjust to on coming here. The latter is certainly interesting conversation material, but will tend to make people who don't know you subconsciously edge away.
I guess I should have used the 'Preview' button (more often)!
And I should know--I left exactly that kind of job at an NTT subsidiary (despite having that rarest of rarities: an intelligent, competent, understanding boss) for a much smaller software company, and negotiated a salary more than twice what I had been making earlier, even taking into account that I couldn't live in a $70/month apartment anymore. It's totally possible to make a decent living here if you're willing to push for it.
Of course, given the way Japanese society works, I imagine most people here don't even consider the possibility of salary negotioations.
I'd tell you about the clever little rootkit they snuck onto those LiveCDs, but they'd kill me for
NO CARRIER
After they got caught out, it went to court.
After some months toing and froing, Skype lost a lower court settlement.
Skype took it to a higher court.
Later that day, the appeals judge slaps them down, hard.
The next day, Skype drops the case.
Fixed that for you.
Assuming, of course, that said shareholders think Microsoft was actually going to let Yahoo live. I don't think I'd have been that optimistic (but then again, I don't hold any YHOO anyway).
I don't suppose anyone's ever pointed out that this isn't actually a valid answer to the question? I agree that 3 levels of indentation is a good limit, but that doesn't make it any easier for my eyes to track the code across those huge horizontal jumps, whereas 4 spaces per indent is much more relaxing to read. (Actually, I have a feeling 5 would be even easier, but old habits die hard . . .)
FWIW, it worked for me when I disabled Javascript completely. But it's not worth it to me to go and disable Javascript just to see the comic, so it's gone from my bookmarks too.
Of course, somebody's gone and overloaded the -> and ++ operators to do things you really don't want to know about. Isn't C++ wonderful?
burning ur karma
This isn't quite accurate; almost nobody has the card, true, but the data itself is being stored nonetheless. The card only serves as the token to pull out your specific record from the database.
That said, there are still a few municipalities that are refusing to connect their systems to the juuki-net. The most well-known is Yamatsuri-cho in Fukushima, which has held out from the start due to concerns about data security (and despite the central government declaring their refusal to connect "illegal"). There's also Suginami-ku in Tokyo and Kawasaki City, if I recall correctly.