As someone who is fluent in Japanese (spoken and written) and proficient in Korean, I can say
that you are not entirely correct regarding the simplicity of the language and its isolation.
With regards to the simplicity of the spoken language, it is interesting that you completely
avoid mentioning levels of respect. Conjugations and actual word selection change dramatically
when speaking to someone in a respectful manner -- forms of speach even change when you are
refering to yourself, your audience or even a third person.
Additionally, there are more than two main verb tenses. I count 4 without thinking much: past
perfect (e.g. "shimashita"), past continuous ("shiteimashita"), present ("shiteimasu") and future ("shimasu").
(For exercise, all these verb forms basically mean the same thing: "yaru",
"suru", "shimasu", "itashimasu", "nasaimasu", "shiteitadakimasu", etc. Yeah, that is easy,
right?)
Also, you are just plain wrong if you believe you can place the nouns anywhere in a sentence. Sure, you can do anything you like, and the Japanese will most likely make sense of your mangled sentence, but if you want to speak as the Japanese do, you will have to follow grammatical rules.
Regarding Japanese as an isolated language, Korean and Japanese grammar are almost identical, and
they share a vast amount of vocabulary inherited from Chinese.
you could just spoof the datastream coming from the sensor and feed it into a hacked driver.
Hacking this protocol would mean hacking the PKI security it is wrapped in, at which point you would be breaking the equivalent to SSL and stealing someone's banking information. Good luck.
The data coming off of the sensor is not going to be usable by anyone without the private key of the hosting system; and if you can get this key, the problem is no longer specific to the biometric system being used.
The answer here is called "anti-spoof," or more appropriately "live finger detection."
Quite a lot of research has gone into how the fingerprint scanners themselves can distinguish live
human skin from other materials, or even dead human skin. There has been much success in
this area to date, and you should expect to see this new technology in products before too long.
What this equates to is you having to be physically present at the time of authentication,
as it will be impossible for someone to spoof your finger, even if they were successful
at lifting a latent print from off of something you touched.
So, though this is a legitimate concern, rest assured the fingerprint sensor companies are
not sitting on their thumbs.;-)
What most people do not understand here is that fingerprint biometric companies are working hard at creating methods of inhibiting entry with anything but live human skin: known as anti-spoofing.
Coupling this with subcutaneous sensor technologies that image the live (saline) layer of the skin, spoofing the fingerprint biometric system becomes prohibitively nontrivial. (Read: the techniques needed to to crack the system are only known to the developers of the system, as the anti-spoof technology itself is highly secretive.).
Re:New Removable Media Standard Ignores Media
on
USB Flash Drive Round-up
·
· Score: 2, Informative
Having worked with USB Mass Storage Class (MSC) devices, I will have to call you on your bullshit.
MSC devices utilise a SCSI pass-through protocol, which encapsulates SCSI packets in USB bulk commands. In order to access the flash, the device has to report the storage unit as a LUN, and respond to standard SCSI capacity inquiries.
Now, the firmware on the uController is at complete liberty to report whatever information it deems necessary to the requesting host. The host cannot arbitrarily "dump the memory" contents of the flash chip, as it is limited the number of sectors that the F/W reports. Attempts to access beyond the reported sector boundary will result in errors.
Additionally, in many of the top-end removable media devices, the F/W possesses the capability of representing the separate sections of the flash storage on the device as multiple LUNs, each with their own capacity (read: multiple partitions).
Add this functionality to a secure authentication system (password, fingerprint, etc.), and voila! The user has complete control over what can be accessed on the device by disabling, and effectively hiding, the partition on which they have data that they do not want to expose to the host.
I lived and worked as an embedded engineer in Japan on cellular technology, so there are few NB I can perhaps throw your way.
Expect the worst
All the strings are most likely hard-coded.
What this means for you is: you will not have the luxury of running this code through a perl script, extracting strings to eventually provide one-to-one correlations in the other target langauge (in this case, English).
Given that Japanese and English grammar differ greatly enough to affect the formatting of strings, many of the strings that will require translation will necessitate rethinking how the data is displayed on the GUI. This is only exacerbated by the fact that VB allows you to build strings with semtantics like "Processing test #" & testIdx & "'s results." (in Japanese: testIdx & "banme no tesutokekka wo shorichuu") -- damn slashdot completely removed my Japanese when I tried to input it!!
Encoding issues
I am not sure about VB in this regard, but you may run into issues with the character set encoding they are using. Most likely this will be Shift JIS on older Windows systems.
ASCII is pretty much universal accross code sets, but it would be wise to port everything over to UNICODE, just incase you are going to have to support other langauges in the future.
I am sure there are other things you will run into, but I wouldn't sweat it. As much as possible, use tools for internationalisation of strings, i.e. gettext.
Not to wax pedantic, but as you have stated ! means logical "not," whereas ~ is the true inverse, or unary bitwise complement, operator. -- Deeming 0x00 the inverse of 0xAA, as !0xAA would produce, does not sit well with the logistician within;-).
Be this as it may, I wholeheartedly agree with your criticism.
I would even posit that the entire concept of ! in C is broken: meaning both "not" in the equality operator != and a "not" in a quasi-logical sense. As an example: since pointers represent memory addresses, or offsets, and because it is widely acceptable to express pointers of 0 value as "NULL," it is perfectly conceivable to interpret "if(!ptr)" as "if 'ptr' is not NULL," which logically opposes the original intent of the expression.
Needless to say, I must admit that I, like many others, give into the temptation of the terse semantics C provides, simply as a matter of typing shortcuts. However, according this logic we should all be mad proponents of Perl.
While all the points you mentioned are valid concerns, especially False Acceptance Rate (FAR) & False Rejection Rate (FRR), there is technology that overcomes most of these limitations.
Have a look at AuthenTec's TruePrint Technology. In summary, "TruePrint Technology uses a patented radio frequency (RF) imaging technique that allows the sensor to generate an image of the shape of the live layer of the skin that is buried beneath the surface of the finger." This makes spoofing of fingerprints nearly impossible.
In fact, AuthenTec are quickly dispelling the myth that biometrics are inherently insecure. Have a look at the Fujitsu's hot-off-the-factory-line F900iC [Japanese]. This is the first phone to fully encorporate mobile commerce (m-commerce), and all authentication is performed via that tiny AES2510 AuthenTec swipe sensor.
DoCoMo (think: user base in the millions) would be mad to trust a technology that you suggest is "not really ready."
MonoDevelop, though in its early stages, is already proving really quite useful as a full fledged IDE.
XSP is already capable of running a number of complex sites, web services and all! Just have a look at the monodoc project.
... and if you still believe Mono to be "vaporware," perhaps you can explain why Novell would ever consider sponsering a project so obviously doomed to fail?
Let us not also forget that Mono is still in its infancy, whereas Qt has had the opportunity to mature over many years of constant development and deployment.
Don't get me wrong, I am thoroughly impressed with the TrollTech offering in Qt, it is just that I have a hard time buying into the whole "vaporware" pitch with regards to Mono...
I believe that once Mono gets to 1.0, along with MonoDevelop (a SharpDelevlop port to Mono and GTK#), there will be MUCH interest in the open source community for releasing libraries and entire subsystems.
I'm personally amazed by the pace of development the Mono team have been jugging along at, and there are already a lot of good things coming out of the Mono community; for instance, mod_mono is already capable of running a number of full-blown ASP.NET applications written for the MS.NET CLR.
Gentoo uses MD5 checksums to insure the integrity of the Portage ebuild packages and source files.
While I am not attempting to play down your suggestions, your assertions that "our package managers... are not controlled or vetted by a central authority" are blatantly false.
ARM possesses the ability to run in both little-endian and big-endian byte order modes; byte order can be set by the OS at bootstrap by flipping a bit on a flag.
overpursued or underpersued
ugh... choose a spelling and stick with it, already;-).
And this is just the type of product segregation they don't need.
In fact, Symbian already went this route with their, now defunct, DFRD roadmaps, targeting various form factors for handhelds. They determined that they themselves were not capable of resourcing the R&D necessary to meet the specific needs of their Licensees and soon ran out of funding: they concluded that it is even presumptuous to suppose one could even truly understand what these needs are!
It is a disastrous business model to assume it your responsibility to innovate and steer a market segment that you really have a very limited scope of influence in.
Except that you are ignoring one major factor here: Eclipse is not a Java IDE.
Eclipse is a framework, on top of which a Java language environment (perspective) is developed.
The Eclipse project's goals are so far out of reach of what Sun wants to achieve here that it seems absurd they would demand such acquiescence of the Eclipse project management.
I am sorry, but I must disagree with your premise that utilising Symbian in your handset will give you faster time-to-market. This is reminiscent of the type of Marketing fluff that is so often bandied about by the likes of Redmon-based megacorps...
The main reasons for me being at variance with your stance stem from my personal experience in this very market, as a Symbian OS specialist.
Things that I know to be very true about Symbian and the Symbian OS are as follows:
Symbian support is some of the shoddiist in the industry. This is from first-hand experience both as a Symbian employee and a consultant for one of their most successful licensees. They are generally understaffed (both TC and GT), and overcommitted, and far too often depend on the manufactures themselves to fix their own OS defects for them.
In order to ship a Symbian product successfully, it is necessary for the manufacturer of the handset to develop the UI components themselves (which literally takes years), or resort to licensing UI technology (S60, UIQ, etc.) from a third party, which is nowhere near reasonable, in terms of pricing; not to mention that these additional costs can only serve to compound the overall expense of licensing the Symbian base technology platform, itself.
Far more projects involving the Sybian OS have been canned than have succeeded. This is a fact, and any Symbian employee who has been there for the last 3~4 years can attest to it. Now, as the technology is fairly unfamiliar to most manufacturers, it is to be expected that there will be some initial failures. But remember, there are licensing fees that go beyond the per-unit sales licensing scheme, and these failures can cost a manufacturer literally millions of dollars in lost investment in both hardware and software research and development.
Until really very recently the Symbian kernel was not capable of handling any type of critical real-time damands, such as 2/2.5/3G comms stacks (GSM, CDMA, W-CDMA, etc.); as such, licensees required third-party solutions, often in the form of dual-chip offerings or partner OS schemes (which Nokia employs, BTW), which is not an expense that manufacturers are happy to bear. Even still, there are questions as to the capabilities of Symbian KA2 to handle really time-critical constraints.
Now, please do not misunderstand my intention in posting this information: it is just that I am so tired of people attributing to Symbian qualities that have really very little basis in reality.
Rather, I think that it would behove us to take a sober look at the Symbian product and make claims based on actuality and factual circumstances.
I love Symbian technology and am fascinated by many of their work and innovations in mobile technology (like their pioneering implementation of a BT stack, to name one), but I must admit that at this point dealing with Symbian technology does not ensure the touted "time-to-market" that so many people are quick to pledge working with it will procure.
And that is all fine and dandy until you start considering Java in the context of resource constrained systems (CPU, memory, etc.)... This is where C/C++ shines, and will continue to do so for a long time to come.
In this arena, Java is often not even a viable option; and the solutions that do exist strip Java of most of those "benefits" you are alluding to.
Slashdot Mirror
This was my comment. Didn't realize that I was not logged in. My apologies.
No, that is just inherent to PERL... Badumdum...
As someone who is fluent in Japanese (spoken and written) and proficient in Korean, I can say that you are not entirely correct regarding the simplicity of the language and its isolation.
With regards to the simplicity of the spoken language, it is interesting that you completely avoid mentioning levels of respect. Conjugations and actual word selection change dramatically when speaking to someone in a respectful manner -- forms of speach even change when you are refering to yourself, your audience or even a third person.
Additionally, there are more than two main verb tenses. I count 4 without thinking much: past perfect (e.g. "shimashita"), past continuous ("shiteimashita"), present ("shiteimasu") and future ("shimasu").
(For exercise, all these verb forms basically mean the same thing: "yaru", "suru", "shimasu", "itashimasu", "nasaimasu", "shiteitadakimasu", etc. Yeah, that is easy, right?)
Also, you are just plain wrong if you believe you can place the nouns anywhere in a sentence. Sure, you can do anything you like, and the Japanese will most likely make sense of your mangled sentence, but if you want to speak as the Japanese do, you will have to follow grammatical rules.
Regarding Japanese as an isolated language, Korean and Japanese grammar are almost identical, and they share a vast amount of vocabulary inherited from Chinese.
Hacking this protocol would mean hacking the PKI security it is wrapped in, at which point you would be breaking the equivalent to SSL and stealing someone's banking information. Good luck.
The data coming off of the sensor is not going to be usable by anyone without the private key of the hosting system; and if you can get this key, the problem is no longer specific to the biometric system being used.
The answer here is called "anti-spoof," or more appropriately "live finger detection."
Quite a lot of research has gone into how the fingerprint scanners themselves can distinguish live human skin from other materials, or even dead human skin. There has been much success in this area to date, and you should expect to see this new technology in products before too long.
What this equates to is you having to be physically present at the time of authentication, as it will be impossible for someone to spoof your finger, even if they were successful at lifting a latent print from off of something you touched.
So, though this is a legitimate concern, rest assured the fingerprint sensor companies are not sitting on their thumbs. ;-)
Yes, because you cannot have flash without transisters.
Visual Studio and Microsoft tools force you to adopt programming techniques designed around implementation speed, not understanding or quality.
It is not the responsibility of the tool developer to insure the user has a clue.
What most people do not understand here is that fingerprint biometric companies are working hard at creating methods of inhibiting entry with anything but live human skin: known as anti-spoofing.
Coupling this with subcutaneous sensor technologies that image the live (saline) layer of the skin, spoofing the fingerprint biometric system becomes prohibitively nontrivial. (Read: the techniques needed to to crack the system are only known to the developers of the system, as the anti-spoof technology itself is highly secretive.).
Having worked with USB Mass Storage Class (MSC) devices, I will have to call you on your bullshit.
MSC devices utilise a SCSI pass-through protocol, which encapsulates SCSI packets in USB bulk commands. In order to access the flash, the device has to report the storage unit as a LUN, and respond to standard SCSI capacity inquiries.
Now, the firmware on the uController is at complete liberty to report whatever information it deems necessary to the requesting host. The host cannot arbitrarily "dump the memory" contents of the flash chip, as it is limited the number of sectors that the F/W reports. Attempts to access beyond the reported sector boundary will result in errors.
Additionally, in many of the top-end removable media devices, the F/W possesses the capability of representing the separate sections of the flash storage on the device as multiple LUNs, each with their own capacity (read: multiple partitions).
Add this functionality to a secure authentication system (password, fingerprint, etc.), and voila! The user has complete control over what can be accessed on the device by disabling, and effectively hiding, the partition on which they have data that they do not want to expose to the host.
A CEO that reads slashdot?! :-)
Where do I apply?
I lived and worked as an embedded engineer in Japan on cellular technology, so there are few NB I can perhaps throw your way.
All the strings are most likely hard-coded.
What this means for you is: you will not have the luxury of running this code through a perl script, extracting strings to eventually provide one-to-one correlations in the other target langauge (in this case, English).
Given that Japanese and English grammar differ greatly enough to affect the formatting of strings, many of the strings that will require translation will necessitate rethinking how the data is displayed on the GUI. This is only exacerbated by the fact that VB allows you to build strings with semtantics like "Processing test #" & testIdx & "'s results." (in Japanese: testIdx & "banme no tesutokekka wo shorichuu") -- damn slashdot completely removed my Japanese when I tried to input it!!
I am not sure about VB in this regard, but you may run into issues with the character set encoding they are using. Most likely this will be Shift JIS on older Windows systems.
ASCII is pretty much universal accross code sets, but it would be wise to port everything over to UNICODE, just incase you are going to have to support other langauges in the future.
I am sure there are other things you will run into, but I wouldn't sweat it. As much as possible, use tools for internationalisation of strings, i.e. gettext.
Hope this helps.
Not to wax pedantic, but as you have stated ! means logical "not," whereas ~ is the true inverse, or unary bitwise complement, operator. -- Deeming 0x00 the inverse of 0xAA, as !0xAA would produce, does not sit well with the logistician within ;-).
Be this as it may, I wholeheartedly agree with your criticism.
I would even posit that the entire concept of ! in C is broken: meaning both "not" in the equality operator != and a "not" in a quasi-logical sense. As an example: since pointers represent memory addresses, or offsets, and because it is widely acceptable to express pointers of 0 value as "NULL," it is perfectly conceivable to interpret "if(!ptr)" as "if 'ptr' is not NULL," which logically opposes the original intent of the expression.
Needless to say, I must admit that I, like many others, give into the temptation of the terse semantics C provides, simply as a matter of typing shortcuts. However, according this logic we should all be mad proponents of Perl.
While all the points you mentioned are valid concerns, especially False Acceptance Rate (FAR) & False Rejection Rate (FRR), there is technology that overcomes most of these limitations.
Have a look at AuthenTec's TruePrint Technology. In summary, "TruePrint Technology uses a patented radio frequency (RF) imaging technique that allows the sensor to generate an image of the shape of the live layer of the skin that is buried beneath the surface of the finger." This makes spoofing of fingerprints nearly impossible.
In fact, AuthenTec are quickly dispelling the myth that biometrics are inherently insecure. Have a look at the Fujitsu's hot-off-the-factory-line F900iC [Japanese]. This is the first phone to fully encorporate mobile commerce (m-commerce), and all authentication is performed via that tiny AES2510 AuthenTec swipe sensor.
DoCoMo (think: user base in the millions) would be mad to trust a technology that you suggest is "not really ready."
And yes, I work for AuthenTec ;-).
Here are some substantial pieces of software that can currently run on top of the Mono VM:
... and if you still believe Mono to be "vaporware," perhaps you can explain why Novell would ever consider sponsering a project so obviously doomed to fail?
Let us not also forget that Mono is still in its infancy, whereas Qt has had the opportunity to mature over many years of constant development and deployment.
Don't get me wrong, I am thoroughly impressed with the TrollTech offering in Qt, it is just that I have a hard time buying into the whole "vaporware" pitch with regards to Mono...
Lack of scruples should not here be mistaken for intelligence.
You must have never looked at the Mono project.
I believe that once Mono gets to 1.0, along with MonoDevelop (a SharpDelevlop port to Mono and GTK#), there will be MUCH interest in the open source community for releasing libraries and entire subsystems.
I'm personally amazed by the pace of development the Mono team have been jugging along at, and there are already a lot of good things coming out of the Mono community; for instance, mod_mono is already capable of running a number of full-blown ASP.NET applications written for the MS.NET CLR.
um... perhaps you have never used a system other than Debian?
RedHat uses GPG signing of all the packages they distribute.
Mandrake does as well.
Most RPM-based distros do, for that matter.
Gentoo uses MD5 checksums to insure the integrity of the Portage ebuild packages and source files.
While I am not attempting to play down your suggestions, your assertions that "our package managers ... are not controlled or vetted by a central authority" are blatantly false.
ARM possesses the ability to run in both little-endian and big-endian byte order modes; byte order can be set by the OS at bootstrap by flipping a bit on a flag.
overpursued or underpersued
ugh... choose a spelling and stick with it, already ;-).
And this is just the type of product segregation they don't need.
In fact, Symbian already went this route with their, now defunct, DFRD roadmaps, targeting various form factors for handhelds. They determined that they themselves were not capable of resourcing the R&D necessary to meet the specific needs of their Licensees and soon ran out of funding: they concluded that it is even presumptuous to suppose one could even truly understand what these needs are!
It is a disastrous business model to assume it your responsibility to innovate and steer a market segment that you really have a very limited scope of influence in.
Some things are best left to the experts...
Except that you are ignoring one major factor here: Eclipse is not a Java IDE.
Eclipse is a framework, on top of which a Java language environment (perspective) is developed.
The Eclipse project's goals are so far out of reach of what Sun wants to achieve here that it seems absurd they would demand such acquiescence of the Eclipse project management.
I am sorry, but I must disagree with your premise that utilising Symbian in your handset will give you faster time-to-market. This is reminiscent of the type of Marketing fluff that is so often bandied about by the likes of Redmon-based megacorps...
The main reasons for me being at variance with your stance stem from my personal experience in this very market, as a Symbian OS specialist.
Things that I know to be very true about Symbian and the Symbian OS are as follows:
Now, please do not misunderstand my intention in posting this information: it is just that I am so tired of people attributing to Symbian qualities that have really very little basis in reality.
Rather, I think that it would behove us to take a sober look at the Symbian product and make claims based on actuality and factual circumstances.
I love Symbian technology and am fascinated by many of their work and innovations in mobile technology (like their pioneering implementation of a BT stack, to name one), but I must admit that at this point dealing with Symbian technology does not ensure the touted "time-to-market" that so many people are quick to pledge working with it will procure.
And that is all fine and dandy until you start considering Java in the context of resource constrained systems (CPU, memory, etc.)... This is where C/C++ shines, and will continue to do so for a long time to come.
In this arena, Java is often not even a viable option; and the solutions that do exist strip Java of most of those "benefits" you are alluding to.
This is by far one of the best movies released this year.
Good plot, and great acting from both Cruise and Ken Watanabe!
And, yes, smartass is one word... :-P
And your clause "as in 'loose legal reasoning'" requires a closing comma, smart ass!!