I've got a proposal for a new IRC protocol (very much a work in progress) sitting around, if you're interested; among other things, it allows redundant connections between servers. Comments are welcome (but "we-don't-need-another-IRC-protocol" flames are not).
Security holes in code can be boiled down to buffer overflows, incorrect application of user privileges, and access to
internal scratch files by other users. Even flawed pointer use can be vetted out with the aid of a debugger tool. If you
use functions like vsprintf() and careful in your design, your code will be 99.9% invulnerable to a root exploit.
You want snprintf(), not vsprintf(). But more to the point, these are only the holes that allow a root exploit--as you correctly emphasized, but referring to these as "[all] security holes", as you imply, is misleading. There are plenty of other ways for users to gain improper privilege. For example, look at the bug Slashdot had a while back where you could put a <font> inside your E-mail address and change the color of the text on the rest of the page (I may be slightly misremembering, but there was something like that at one point), or the brouhaha concerning session IDs stored in URLs. For a more subtle example (paraphrasing from experience), you could have a flag allowing special privileges for a chat nickname, which is cleared every time a new user uses the nickname and only set when a password is given--except that the flag isn't cleared if a user with an
unknown nickname changes to the nickname in question, allowing improper privileges. There are, of course, many other potential pitfalls, many of which rely on what the program in question does; things like buffer overflows that apply to all programs are the easiest ones to find and fix, but only the tip of the iceberg.
What security holes in code really boil down to is insufficient checking, i.e. improper trusting, of input (this includes not only ordinary stdin/form/file input, but environment variables, signals, etc. as well). By ensuring that all input has a known format, the security and robustness of a well-written program can be proven.
Sure, there are a lot of things that were invented first in the US or elsewhere outside Japan; as a number of other comments have pointed out, Japanese society doesn't breed nearly as much creativity as (for example) American society, and I'm not disputing that. What I'm saying is that the Japanese are damn good at making (and improving) things once they have something to work on.
As an aside, I still haven't been able figure out what so many people find wrong with Japan being better at manufacturing/improving than at inventing, but maybe that's just me...
I'd have thought any of the Sony Vaio range would amply demonstrate that the Japanese excel at making PC's too...
Perhaps, but since the HD on my Vaio laptop at work just died yesterday, I'm not overly fond of Vaios at the moment...
(BTW, I wasn't saying the Japanese aren't good at making PC's, I was just commenting on the fact that Net-enabled cell phones have supplanted PCs for some uses in Japan, hence there aren't as many PCs in use here as there on the consumer end.)
Looks like what happened is his dashes got deleted. I bet he was using Word's "smart dashes" or whatever they're called and an HTML sanitizer bit him. (If you look at the source, you'll notice that the places which are presumably missing punctuation have two spaces between the words: "7.5 percent of the salesabout three times..." and so on.)
Maybe it's just that Japanese companies are better at coming up with clever games, or Japanese arcade operators know that not everybody likes fighting games, but arcades in Japan are, if not exactly flourishing, certainly not dead. Most arcades here have a pretty wide selection of games, from fighting to shooters to sports to puzzle games; where you'd be lucky to even find a Ms. Pac-Man in the US these days (heaven knows how many quarters I dropped into that game), pretty much any arcade here will have a decent number of puzzlers, probably 20% or so on average. One place in Akihabara I tend to stop in whenever I'm in the area has Columns and a couple other puzzle games despite having little floor space. Some arcades even have machines with several games available, which presumably saves a lot on hardware/maintenance.
The fact that games here are, and AFAIK have always been, all 100 yen (~= US$0.83) could also be a factor in the health of arcades...
He also mentioned that 57% of that was in the drivers subdirectory. While I suppose a little more code sharing could happen if you tried, the real problem is hardware companies that insist on having their own special little addition to the protocol that requires a new driver.
Just to clarify (however belatedly), since I've been developing for DoCoMo's Java phones for the last few months...
You can do nothing to the phone itself from Java. You can't dial, you can't send E-mail (well, you can connect back to your server and have it send E-mail, but if you're going to spam from a server you don't need a phone), you can't connect to any remote site other than the one the program was downloaded from, you can't access the phone's memory / dial history / etc., you can't even run another Java app from inside yours (which is a major PITA since the maximum size of a JAR file is 10k). Moreover, the Docomo spec calls for the chip that implements the JVM to be physically separate from the chip(s) controlling the rest of the phone--obviously they're connected and all, but it certainly reduces the chance of a rogue Java program "accidentally" messing with main memory or such.
First of all, the interface to all functions and classes in a shared library MUST be backwards compatible with
previous versions.
<rant>
And while you're at it, get rid of that stupid symbol versioning system whoever it was invented and stuck into glibc. It makes it impossible to use newer binaries with older (but the same major version) libraries, or even with the same version if it's compiled without symbol versioning. Even simple things like cat don't work. I'm almost tempted to say the GNU people are trying to sneakily force new versions of their libraries on everyone.
</rant>
We now return you to your regularly scheduled Slashdot programming.
Image the bloat hell we would be in if everyone linked their projects statically to libraries.
Oh, like I'm really going to notice that 1500 or so binaries have an extra meg or two tacked onto them, if even that. I don't know if you've looked around recently, but even 40-gig drives are going for just $100 or so these days. There's a point up to which optimization is good, and beyond which it's not worth it--think diminishing returns. Guess where this lies? (Yes, I'm well aware there are things like embedded systems where a few kilobytes mean a lot--in fact, I just spent a year working on one. But such systems have plenty of other special requirements as well, so I'm not considering them here.)
On the other hand, a good reason for keeping shared libraries is that if a bug is found and fixed in a library, you only have to upgrade the library (one item) instead of every program that uses it (in the case of libc, basically everything). Even that's starting to become moot with broadband connections, but there's always the security aspect: "oops, I thought I upgraded everything but I forgot about that one contrib daemon and someone cracked me through it..."
Even so, I'm not convinced that a 3500x2600 display exceeds the limit of human eye resolution--though that may just be because I'm used to sitting a foot from my monitor...
a typical person has a maximum resolution of about 17000 point sources per inch.
So, assuming for the sake of argument the monitor has a roughly 16"x12" viewable area, that gives (16*17000) * (12*17000) = 55,488,000,000 points, or 55.5 gigapoints, as the limit of human eye resolution for a screen of that size. That's several orders of magnitude over the announced 9.2 megapixel display, assuming that pixels are roughly equivalent to points.
Incidentally, putting that 9.2 megapixel value into more easily understandable terms gives a display size of roughly 3500x2600 (assuming a 4:3 display ratio). Good? Yes. Perfect? No.
>>Japan and Korea get no benefit from Unicode. In fact, their ISO 2022 encodings are at least in "alphabetical
order" for the relevant alphabets. Unicode is just a jumble.
I can't speak for Korean, but there is no such thing as an alphabetic order for Kanji. In Japanese, Kanji almost
always have at least two pronunciations, and often more.
While it is true that most all kanji have multiple pronunciations, the kanji in ISO-2022-JP are most definitely in order. Level 1 characters (0x3021-0x4F7E) are ordered by their primary reading, and Level 2 characters (0x5021-0x7426?) are ordered first by radical and then by number of strokes. In both cases it's easy to locate a character if for some reason you can't type it normally (e.g. it's not in your IME dictionary)--I've had to do this on occasion, in fact.
Unicode is, for all intents and purposes, completely random. Even without the problems of characters being inappropriately merged, there is no way you could try and find a character in Unicode; if your dictionary doesn't have it, tough luck. To me, that's an even scarier concept: for all practical purposes it could eliminate characters from the language. After all, if nobody can type it who's going to use it?
Have you ever tried to program in shift-JIS? It is horrific.
I will agree with this. Leaving aside the original poster's confusion of ISO-2022-JP and shi[f]t-JIS (the former is the official standard, aka JIS, while the latter is a poorly-thought-out Microsoft hack), dealing with strings that contain both half-width (1-byte) and full-width (2-byte) characters is a major PITA. About the only thing that can be said for it is the number of bytes is equal to the number of half-width character positions needed; and even that only applies to EUC and SJIS, since JIS has escape sequences to squeeze everything into 7-bit characters.
On the other hand, there's the character order consideration, which along with the problem of merged characters seems to be what draws so much dislike for Unicode from Japanese.
For
young hi-tech Japanese these days, job loyalty doesn't mean much more than it does to their American
counterparts.
Perhaps not loyalty in the sense of sacrificing one's free time / etc. to the company, but there's not nearly as much job hopping as you seem to think--mainly because the people who do take full-time jobs take them because they want job security, which is something Japanese companies are (even now) much more willing to offer than American companies. Even Japan's labor laws prohibit "arbitrary" firing of full-time employees, though you can of course find a reason for anything if you look hard enough. There was also a survey done recently by a government office which showed a slight increase compared to 2-3 years ago in willingness to stay at a single job indefinitely (as with all surveys, take with as many grains of salt as you need).
The fact that management is concerned about losing employees should indicate that it is, if not a major
problem, at least a possibility.
Yup. Going from 0.1% to 1% is a tenfold increase--anyone would be worried at a tenfold increase!
No, I don't have any actual data on frequency of job changing on hand at the moment, but I can tell you my friends (same age group, early-mid 20's) are all pretty shocked when they hear how often Americans change jobs. (Incidentally, the number I heard a few years back was once every 2-3 years... has that changed significantly?)
Even in high-tech, the offices are cramped, the hours are long, and the bureacracy is thick.
And don't forget the infamous Tokyo commute.
As opposed to American companies, where you have to run across the building to talk to a coworker, the hours are long, and the bureaucracy is thick. And don't forget the infamous Beltway parking-lot traffic jams.
First, a correction: the GPL does not require that you distribute source to a GPL program that you modify--only that if you distribute it in binary form then you must also distribute it in source form. This seems to be a pretty common misunderstanding, but if you come from out of nowhere and ask Sony (or anyone else) to fork over the source for some GPL'd software XYZ, and they say "screw you," well, tough luck--they're completely within their rights.
Second, Sony is including the source to all GPL components of their distribution. They even say as much (in Japanese) on their license terms page.
Slightly Offtopic, but are there any more news on the rumoured Linux which they got to run on a PS2?
It's not rumored anymore--they had it on display, running, at LinuxWorld today (apparently Sony lent out one of their kits ahead of time), and it looked sweet. Now I'm looking forward even more to when I get mine on the 20th of June. (:
It is too that programmers are getting sloppy. Take Playstation save files, for instance: The original Playstation had a 128kB memory card divided into 8kB blocks, and the majority of games used just 1 block (some used 2), for a save file size of 8-16kB. Now we come to the Playstation 2, with an 8MB memory card, and all of a sudden save file sizes have jumped to 100kB or more. You'll never convince me that's not sloppy programming (or over-design, which is the same thing), at least in the cases I've seen.
Though I won't dispute the argument that game engines don't grow to 60GB... (:
[..] judging from the lack of Japanese posts to slashdot, I don't see a lot
of traffic from our.jp friends.
Well, one reason could be that the lameness filter blocks Japanese characters... of course, posting in Japanese would be kinda pointless anyway because almost nobody else could read it.
-- BACKNEXTFINISHCANCEL
On display at NHK Studio Park (Tokyo)
on
3D w/o Goggles
·
· Score: 2
So excuse my scepticism if I say that I'll believe it when I see it.
Then come to NHK Studio Park in Shibuya, Tokyo; they've got a 3D-without-goggles system on permanent display, and though it only works well when you stand at a certain distance directly in front of the screen, it works excellently within those limitations.
And that's not even state-of-the-art anymore. At a digital-TV fair they had earlier this month, they had what was essentially a hologram on display. Yes, really. Not quite the same because you can't look at it from the side, but within the viewing angle (about 60 degrees IIRC) it's a 3D image standing in midair. You could even stick your hand (or your face) in it like they used to do in all those sci-fi shows. Frankly, it knocked my socks off.
You're forgetting temporary files: what about all those ccxxxxxx.[iso] files that gcc creates--and then deletes--for each source file you compile, or the test programs autoconf's configure script generates for every test it does?
I will agree that allocation has greater importance overall than deletion, though.
Slashdot Mirror
I've got a proposal for a new IRC protocol (very much a work in progress) sitting around, if you're interested; among other things, it allows redundant connections between servers. Comments are welcome (but "we-don't-need-another-IRC-protocol" flames are not).
--
BACKNEXTFINISHCANCEL
Security holes in code can be boiled down to buffer overflows, incorrect application of user privileges, and access to internal scratch files by other users. Even flawed pointer use can be vetted out with the aid of a debugger tool. If you use functions like vsprintf() and careful in your design, your code will be 99.9% invulnerable to a root exploit.
You want snprintf(), not vsprintf(). But more to the point, these are only the holes that allow a root exploit--as you correctly emphasized, but referring to these as "[all] security holes", as you imply, is misleading. There are plenty of other ways for users to gain improper privilege. For example, look at the bug Slashdot had a while back where you could put a <font> inside your E-mail address and change the color of the text on the rest of the page (I may be slightly misremembering, but there was something like that at one point), or the brouhaha concerning session IDs stored in URLs. For a more subtle example (paraphrasing from experience), you could have a flag allowing special privileges for a chat nickname, which is cleared every time a new user uses the nickname and only set when a password is given--except that the flag isn't cleared if a user with an unknown nickname changes to the nickname in question, allowing improper privileges. There are, of course, many other potential pitfalls, many of which rely on what the program in question does; things like buffer overflows that apply to all programs are the easiest ones to find and fix, but only the tip of the iceberg.
What security holes in code really boil down to is insufficient checking, i.e. improper trusting, of input (this includes not only ordinary stdin/form/file input, but environment variables, signals, etc. as well). By ensuring that all input has a known format, the security and robustness of a well-written program can be proven.
--
BACKNEXTFINISHCANCEL
--
BACKNEXTFINISHCANCEL
As an aside, I still haven't been able figure out what so many people find wrong with Japan being better at manufacturing/improving than at inventing, but maybe that's just me...
--
BACKNEXTFINISHCANCEL
I'd have thought any of the Sony Vaio range would amply demonstrate that the Japanese excel at making PC's too...
Perhaps, but since the HD on my Vaio laptop at work just died yesterday, I'm not overly fond of Vaios at the moment...
(BTW, I wasn't saying the Japanese aren't good at making PC's, I was just commenting on the fact that Net-enabled cell phones have supplanted PCs for some uses in Japan, hence there aren't as many PCs in use here as there on the consumer end.)
--
BACKNEXTFINISHCANCEL
Which one produces a superior product? That's the superior business culture.
Hm, let's see...
- Household electronics: Sony, Sharp, Sanyo, Panasonic...
- Walkman: That's the Sony Walkman.
- Cell phones: Can you say i-mode?
- PC's: Bah, who needs 'em when you have cell phones? (Okay, that's an overstatement, but not as much as you might think.)
Now what was that you were saying again?--
BACKNEXTFINISHCANCEL
--
BACKNEXTFINISHCANCEL
--
BACKNEXTFINISHCANCEL
The fact that games here are, and AFAIK have always been, all 100 yen (~= US$0.83) could also be a factor in the health of arcades...
--
BACKNEXTFINISHCANCEL
--
BACKNEXTFINISHCANCEL
Minor correction... B8 00 4C = MOV AX,4C00h (load 4C00 hex into register AX--remember that the x86 is little-endian).
And the scary thing is, I knew what those bytes meant without having to read the answer...
--
BACKNEXTFINISHCANCEL
Just to clarify (however belatedly), since I've been developing for DoCoMo's Java phones for the last few months...
You can do nothing to the phone itself from Java. You can't dial, you can't send E-mail (well, you can connect back to your server and have it send E-mail, but if you're going to spam from a server you don't need a phone), you can't connect to any remote site other than the one the program was downloaded from, you can't access the phone's memory / dial history / etc., you can't even run another Java app from inside yours (which is a major PITA since the maximum size of a JAR file is 10k). Moreover, the Docomo spec calls for the chip that implements the JVM to be physically separate from the chip(s) controlling the rest of the phone--obviously they're connected and all, but it certainly reduces the chance of a rogue Java program "accidentally" messing with main memory or such.
--
BACKNEXTFINISHCANCEL
Please pardon a minor rant...
First of all, the interface to all functions and classes in a shared library MUST be backwards compatible with previous versions.
<rant>
And while you're at it, get rid of that stupid symbol versioning system whoever it was invented and stuck into glibc. It makes it impossible to use newer binaries with older (but the same major version) libraries, or even with the same version if it's compiled without symbol versioning. Even simple things like cat don't work. I'm almost tempted to say the GNU people are trying to sneakily force new versions of their libraries on everyone.
</rant>
We now return you to your regularly scheduled Slashdot programming.
--
BACKNEXTFINISHCANCEL
Image the bloat hell we would be in if everyone linked their projects statically to libraries.
Oh, like I'm really going to notice that 1500 or so binaries have an extra meg or two tacked onto them, if even that. I don't know if you've looked around recently, but even 40-gig drives are going for just $100 or so these days. There's a point up to which optimization is good, and beyond which it's not worth it--think diminishing returns. Guess where this lies? (Yes, I'm well aware there are things like embedded systems where a few kilobytes mean a lot--in fact, I just spent a year working on one. But such systems have plenty of other special requirements as well, so I'm not considering them here.)
On the other hand, a good reason for keeping shared libraries is that if a bug is found and fixed in a library, you only have to upgrade the library (one item) instead of every program that uses it (in the case of libc, basically everything). Even that's starting to become moot with broadband connections, but there's always the security aspect: "oops, I thought I upgraded everything but I forgot about that one contrib daemon and someone cracked me through it..."
--
BACKNEXTFINISHCANCEL
Correct you are; my apologies.
Even so, I'm not convinced that a 3500x2600 display exceeds the limit of human eye resolution--though that may just be because I'm used to sitting a foot from my monitor...
--
BACKNEXTFINISHCANCEL
a typical person has a maximum resolution of about 17000 point sources per inch.
So, assuming for the sake of argument the monitor has a roughly 16"x12" viewable area, that gives (16*17000) * (12*17000) = 55,488,000,000 points, or 55.5 gigapoints, as the limit of human eye resolution for a screen of that size. That's several orders of magnitude over the announced 9.2 megapixel display, assuming that pixels are roughly equivalent to points.
Incidentally, putting that 9.2 megapixel value into more easily understandable terms gives a display size of roughly 3500x2600 (assuming a 4:3 display ratio). Good? Yes. Perfect? No.
--
BACKNEXTFINISHCANCEL
>>Japan and Korea get no benefit from Unicode. In fact, their ISO 2022 encodings are at least in "alphabetical order" for the relevant alphabets. Unicode is just a jumble.
I can't speak for Korean, but there is no such thing as an alphabetic order for Kanji. In Japanese, Kanji almost always have at least two pronunciations, and often more.
While it is true that most all kanji have multiple pronunciations, the kanji in ISO-2022-JP are most definitely in order. Level 1 characters (0x3021-0x4F7E) are ordered by their primary reading, and Level 2 characters (0x5021-0x7426?) are ordered first by radical and then by number of strokes. In both cases it's easy to locate a character if for some reason you can't type it normally (e.g. it's not in your IME dictionary)--I've had to do this on occasion, in fact.
Unicode is, for all intents and purposes, completely random. Even without the problems of characters being inappropriately merged, there is no way you could try and find a character in Unicode; if your dictionary doesn't have it, tough luck. To me, that's an even scarier concept: for all practical purposes it could eliminate characters from the language. After all, if nobody can type it who's going to use it?
Have you ever tried to program in shift-JIS? It is horrific.
I will agree with this. Leaving aside the original poster's confusion of ISO-2022-JP and shi[f]t-JIS (the former is the official standard, aka JIS, while the latter is a poorly-thought-out Microsoft hack), dealing with strings that contain both half-width (1-byte) and full-width (2-byte) characters is a major PITA. About the only thing that can be said for it is the number of bytes is equal to the number of half-width character positions needed; and even that only applies to EUC and SJIS, since JIS has escape sequences to squeeze everything into 7-bit characters.
On the other hand, there's the character order consideration, which along with the problem of merged characters seems to be what draws so much dislike for Unicode from Japanese.
--
BACKNEXTFINISHCANCEL
For young hi-tech Japanese these days, job loyalty doesn't mean much more than it does to their American counterparts.
Perhaps not loyalty in the sense of sacrificing one's free time / etc. to the company, but there's not nearly as much job hopping as you seem to think--mainly because the people who do take full-time jobs take them because they want job security, which is something Japanese companies are (even now) much more willing to offer than American companies. Even Japan's labor laws prohibit "arbitrary" firing of full-time employees, though you can of course find a reason for anything if you look hard enough. There was also a survey done recently by a government office which showed a slight increase compared to 2-3 years ago in willingness to stay at a single job indefinitely (as with all surveys, take with as many grains of salt as you need).
The fact that management is concerned about losing employees should indicate that it is, if not a major problem, at least a possibility.
Yup. Going from 0.1% to 1% is a tenfold increase--anyone would be worried at a tenfold increase!
No, I don't have any actual data on frequency of job changing on hand at the moment, but I can tell you my friends (same age group, early-mid 20's) are all pretty shocked when they hear how often Americans change jobs. (Incidentally, the number I heard a few years back was once every 2-3 years... has that changed significantly?)
Even in high-tech, the offices are cramped, the hours are long, and the bureacracy is thick. And don't forget the infamous Tokyo commute.
As opposed to American companies, where you have to run across the building to talk to a coworker, the hours are long, and the bureaucracy is thick. And don't forget the infamous Beltway parking-lot traffic jams.
It all depends on your definition of "better".
--
BACKNEXTFINISHCANCEL
First, a correction: the GPL does not require that you distribute source to a GPL program that you modify--only that if you distribute it in binary form then you must also distribute it in source form. This seems to be a pretty common misunderstanding, but if you come from out of nowhere and ask Sony (or anyone else) to fork over the source for some GPL'd software XYZ, and they say "screw you," well, tough luck--they're completely within their rights.
Second, Sony is including the source to all GPL components of their distribution. They even say as much (in Japanese) on their license terms page.
--
BACKNEXTFINISHCANCEL
Slightly Offtopic, but are there any more news on the rumoured Linux which they got to run on a PS2?
It's not rumored anymore--they had it on display, running, at LinuxWorld today (apparently Sony lent out one of their kits ahead of time), and it looked sweet. Now I'm looking forward even more to when I get mine on the 20th of June. (:
--
BACKNEXTFINISHCANCEL
It is too that programmers are getting sloppy. Take Playstation save files, for instance: The original Playstation had a 128kB memory card divided into 8kB blocks, and the majority of games used just 1 block (some used 2), for a save file size of 8-16kB. Now we come to the Playstation 2, with an 8MB memory card, and all of a sudden save file sizes have jumped to 100kB or more. You'll never convince me that's not sloppy programming (or over-design, which is the same thing), at least in the cases I've seen.
Though I won't dispute the argument that game engines don't grow to 60GB... (:
--
BACKNEXTFINISHCANCEL
[..] judging from the lack of Japanese posts to slashdot, I don't see a lot of traffic from our .jp friends.
Well, one reason could be that the lameness filter blocks Japanese characters... of course, posting in Japanese would be kinda pointless anyway because almost nobody else could read it.
--
BACKNEXTFINISHCANCEL
So excuse my scepticism if I say that I'll believe it when I see it.
Then come to NHK Studio Park in Shibuya, Tokyo; they've got a 3D-without-goggles system on permanent display, and though it only works well when you stand at a certain distance directly in front of the screen, it works excellently within those limitations.
And that's not even state-of-the-art anymore. At a digital-TV fair they had earlier this month, they had what was essentially a hologram on display. Yes, really. Not quite the same because you can't look at it from the side, but within the viewing angle (about 60 degrees IIRC) it's a 3D image standing in midair. You could even stick your hand (or your face) in it like they used to do in all those sci-fi shows. Frankly, it knocked my socks off.
--
BACKNEXTFINISHCANCEL
You're forgetting temporary files: what about all those ccxxxxxx.[iso] files that gcc creates--and then deletes--for each source file you compile, or the test programs autoconf's configure script generates for every test it does?
I will agree that allocation has greater importance overall than deletion, though.
--
BACKNEXTFINISHCANCEL
If this is the case, I think it is quite a good tradeoff, given that space is allocated much more often.
Only if you've got an infinite drive...
--
BACKNEXTFINISHCANCEL