You're still releasing the carbon dioxide bound in those untapped oil fields and all that oil sand out of the ground and into the air.
It's far from certain, but there's pretty good reason to fear that such action would seriously warm the earth. If there's any non-linearity in the system -- and there's no reason to assume linearity -- then we could have a runaway greenhouse effect that we might be unable to stop.
I'm sure life would thrive on such a planet, but perhaps not human life.
If you want to know what influence other languages would have on software systems, look no farther than the big multinational corporations and the new systems they create. These companies, because of their size, pay much closer attention to non-Westerners than most open-source hackers ever will.
Virtually all new systems created by IBM, MS, Sun, Oracle, etc. are Unicode based, and have been for several years. Languages like Java and C# use 16-bit Unicode chars. All of Java's text widgets are designed to accept a Unicode string containing an arbitrary mix of any set of languages and to display them correctly (each version gets a little closer, but the proper foundation was laid from the start). IBM was the main driver behind that, but Sun readily agreed. Oracle would be happy if every database from now on were Unicode.
Contrast that to the brand new systems produced by the "enlightened" open source community of primarily Western hackers. Released several years after Java and other Unicode systems, GNOME 1.0 was once again based on the obsolete notion that char == byte. Unbelievable. KDE did the same thing. While KDE could mostly paper over it by using the features of C++ (they just upgraded the string class implementation to Unicode and relied on automatic type conversion), the C-based GNOME will have programmers falling into single-byte traps for years to come. This is the same problem that haunts Win9x developers that pure NT or pure Java developers don't have to worry about.
I can't help but think that if more developers of programming languages were Asian, for example, the concept of a real string class (multiple bytes per char) and truly multilingual text widgets would be given, not awkwardly grafted on in version 4 of everything.
I think the actions of multinationals (as compared to open source hackers who never venture far from home) demonstrate my point.
That pretty much makes the whole exercise a waste of time. If you're only allowed to post opinions that the agencies want posted, then they may as well just run banner ads.
Under UK law, if you have a bad experience with an agency but aren't *certain* that you can prove it, you'd better keep your mouth shut or move to the US. I guess that's one way to keep a lid on society.;-)
I wouldn't bet on its being a minor language. This could meet the needs of a lot of Windows developers rather nicely, and it appears designed to work nicely in modern dev environments (i.e. something more than a generic text editor.)
It's amazing to me that once again, a new language has been introduced without Eiffel's innovative Design by Contract. This is the one feature James Gosling says he most regrets leaving out of Java. He left it out, he says, because at the last minute, when Java was suddenly being thrust into the limelight, he wasn't sure how to do it right, so he left it for later, and now it may be too late to really build it in (as opposed to bolting it on as an afterthought.) It looks as though, after years of hearing Gosling expressing such regrets, MS is going to go right ahead and repeat his mistake.
Not an Internet language because it doesn't compile into bytecodes? What kind of definition is that? How about changing that definition to "useful for Internet developers"?
Sun has relentlessly pursued a policy that "the whole idea of Java" is to produce bytecode, as if that's really at the top of most Java users' agendas. Funny, but in every enterprise I've been involved with, the whole idea (on our -- the developers' -- side) was to have a quicker, easier, more reliable way to create good server-side apps. True, there is occasional use of Java on the client, but the majority of serious Java users use it as a server-side development language, where they couldn't care less about portable binaries, but the conveniences of the language itself are the attraction.
What we want is a language that lets us quickly whip together a powerful, fast, and reliable server-side app, then compile it into a blindingly fast executable, optimized for whatever server we happen to use. Once every few years, when we change server platforms, we'd be willing to recompile.;-)
I would so much rather have a language that combined some of Java's (language) features, with an Eiffel/eXtremeProgramming-ish ability to *automatically* generate testing/assertion/designByContract debug scaffolding, based on explicit interface contracts expressed in the language, that could be turned on or off in a fine-grained way for a customized balance of speed and safety when compiling the production executable for deployment on the server. In other words, basically Eiffel, with some of the Internet-oriented features (and the marketshare!) of Java The Language.
If some sort of bytecode system were designed for the express purpose of allowing additional runtime performance optimizations, then that would be fine. Such a system, unlike Java's, wouldn't carry any baggage necessary solely to make the binary portable, nor any security checking baggage of the the sort that is only relevant when running as untrusted code, nor anything else that would interfere with the mission of creating rock-solid, blindingly fast, easy-to-create, multithreaded, inherently distributed server-side internet applications. Such bytecode would be purely a performance technology.
Now, it doesn't sound to me as though C# is anywhere near so innovative. I wouldn't expect it to be, given the source. I'm certainly not looking for another Windows-only language, but neither do I want another language that, like Java, is essentially designed to prevent me from using it to write great Windows apps.
An inability to produce bytecode would hardly make a language less interesting to most real Internet application developers that I know.
Karmageddon gets the award for being the only person in this thread who actually knew the answer, moderation notwithstanding.
Twenty years ago, we used the "learning curve" for strategic purposes. The Boston Consulting Group (our competitor) had pioneered its use for business and competitive analysis. It was the observation that unit manufacturing cost tends to decrease with the log of the cumulative number of units manufactured. That's a downhill curve, and a steep descent meant rapid learning, and was a sign of good organizational practices. A steep and consistent learning curve was characteristic of Japanese kaizen practices, which were of great interest in those days.
The fact that others haven't a clue what "learning curve" means is demonstrated by their inability to define it in any consistent and sensible way. It's just a way of co-opting specialist jargon as a way to make oneself sound like a specialist.
Now, ChrisWong insists "don't bore me with the truth, which is no longer relevant to anybody except those few who know what they're talking about, tell me instead how to blend in with the misinformed but trendy masses."
Ask and you shall receive.
Use the following guide: say "steep learning curve" when you mean difficult. Talk about the "parameters" of a problem. Say "bandwidth" when you mean time. That should get you started.
"I will readily retract and apologize for these statements if NSI does start pulling systematic monkey business with domains, but I'm not afraid b/c it isn't going to happen. Spend some time outside of Slashdot, get some fresh air, and stop making mountains out of nothing."
I think this is naive. Contrary to your belief, I and many other Slashdot readers are rather careful readers of other contracts. Yes, they are often surprising in the breadth of their claims, and yet we sign them anyway. This is because of legal precedent. Regardless of the specific wording of the contracts, there is a great deal of legal precedent demonstrating that the courts will protect consumers to a certain extent, and everything you mentioned was a consumer service.
What NSI is doing is setting precedent in an area of law that is still virgin territory. I consider their hosting of my domain to be the equivalent of their keeping my jewels in their safe deposit box in return for consideration: my monthly fee.
NSI is asserting that my domain, which pre-existed their company, is the creation and sole property of their company, to do with as they choose at their sole discretion. I don't actually suspect that they intend to simply take it and auction it off to the highest bidder. Nevertheless, they have now asserted their "right" to do exactly that if they so choose, and that if they do so, I have no recourse because it was theirs, not mine.
I want this assertion to be soundly trounced, both legally and commercially, before it sets a legal precedent with some scary ramifications. People who make statements such as yours are the ones who should really get out more. "I don't care what the contract says, bad things only happen to the other guy...." Lot of bad things happen to people in contractual relationships, and when they do, the wording of the contract and previous legal precedent matter enormously.
Imagine a scenario where NSI has created this precedent, but they don't meddle with any of our domains. "There," you say, "I told you." Then along comes another registrar. It offers to pay you to let them host your domain. "Wow," you say, "this is great! Real competition." You transfer your domain to them, Acme Domains, Inc., and once they've gathered enough of them, they turn around and repossess them and begin auctioning them off to other bidders. "Hey!" you scream. "What's the deal?"
They then inform you that they were only providing you with the equivalent of a phone number, that they didn't just take it (even though it's theirs) that they actually bought it from you originally, and now they are changing to a different line of business: domain auctions. Thank you very much. They point to the legal precedent set by NSI and the courts rule in their favor.
Good domain names are so difficult to obtain that they sell for millions. There are a lot of large institutions with big legal departments out there that would be horrified to learn of NSI's legal claim, but I'm willing to bet that few of them know about this yet. Once they find out, we'll have some powerful allies.
Imagine if your bank were to declare that your deposits with them were not physical, but electronic, and as such were merely forms of information that were the product of your contract with the bank. Therefore, they actually owned your money, allowing you to use it at their "sole discretion", and if you tried to move it to another bank, they had no legal responsibility if the "information" somehow ended up in the hands of a third party.
I would guess that if this move got out, there would be a run on the bank. That's exactly what should happen to NSI as well as any other institution that claims ownership of something I deposit with them for a fee.
I suggest that we generate a Slashdot effect on NSI by getting the word out anyway we can, to everyone who will listen, hopefully causing a run on this "bank".
NSI would then either have to publicly change its policy, or publicly explain its unchanged policy. The latter would probably put them out of business as all the folks in the world who give computer advice decided en masse to advise against NSI. Either way, it would make news.
All eyes would be on them, with the press sniffing around for stories of NSI "losing" domains that were transferred away from them, probably making them much more careful. At the same time, there would probably be a few large organizations willing to combine their legal resources in a bid to stop NSI. After all, NSI isn't just setting its own policies, it's setting precedents -- precedents that organizations with billions in intellectual property and large legal departments wouldn't want set.
This approach is about the only way I can think of to increase our likelihood, as small fish ourselves, of maintaining possession of our hard-won domain names in the face of this sort of outrageous behavior.
Thanks for a very useful posting. Posting as an AC means you don't get your frequent flyer miles, uh, moderator points, but here's a virtual 5 from me.;-) Very helpful.
This could be solved with a "true status" bar feature. You could choose to display either the True Status bar or the legacy status bar via your browser preferences, but the true status bar would be the default in new browsers.
The true status bar could be a lot more informative than the one we have now in both major browsers. It would work for YOU, not for the website. It would tell you what things really MEANT when you passed the mouse over them before you ever clicked anything. It could blink or in some other way attract your attention if something seemed fishy on the page. For example, the visible anchor text appeared to contain a domain, but the HREF pointed to a different domain. Or if there were any <tags> in the URL text. Or if it noticed any tiny GIF on the page from a domain other than the domain of the page itself or with a URL that looked as though it contained more than a simple image name. Or light up a little chocolate chip icon if the page was using a cookie (click the cookie to allow or disallow it). Or if form data SUBMIT would submit the data to some domain other than the domain of the page. Or....
That's what a true status bar should offer us, not a place for annoying scrolling text that blocks our view of the URL behind a link.
There are nowhere close to 100,000 Chinese characters, much less 200,000. That's mythology. The largest collections of Chinese characters are in the 50,000 to 80,000 range, and are mostly composed of glyph variants.
Today, Chinese experts make a distinction between character and glyph, and prefer to deal with glyph variants at the font level. This makes it so much simpler for Chinese software, such as search engines. For this reason, they are not anxious to use giant characters sets. Unicode is about the right size, and the Chinese official experts contributing to Unicode aren't anxious to add a lot more characters to Unicode. They still need to add a few, but are doing so very judiciously. Whatever they add, they know they'll have to support, so they frown on variant glyphs of the same character as separate characters. Sorting, searching, printing, font making...everything is tougher when you encode multiple versions of what really should be considered the same character. The experts don't want the permanent liability. It's really only nationalistic amateurs who make a big fuss about Unicode being "far from enough". The experts know better (though there will later be a full 64K character plane devoted to such variants outside the core "Basic Multilingual Plane" to quiet the complainers.)
The only thing that will happen to consumer e-commerce is that it will lose its "e" as it becomes just "commerce".
The catalog business has been growing for years. There are more consumer catalogs than ever being mailed out. E-commerce is just a more effective medium. There's no reason for a "backlash" against consumer e-commerce when there has been no such backlash against catalog sales.
Granted, there will be a lot of b2b e-commerce, but there's already a ton of b2b catalog commerce, too. That hasn't devastated the consumer catalog industry.
What we have now is a lot of consumer e-commerce pioneers building their infrastructure by hand and trying to dominate large industries. No wonder they're profit-impaired. The original Sears catalog business was like that -- except that they went more slowly and allowed themselves some profits for a few decades -- but time brought changes along with an overall growth in catalog sales.
Sears's catalog business didn't survive the changes, but it wasn't any "backlash", and the industry didn't shrink. Quite the contrary.
Most companies in catalog commerce today are small outfits that outsource most aspects of their infrastructure and try to dominate a small market niche. Consumer e-commerce will grow overall, and grow in that direction. Most companies will outsource to a growing number of full-service e-commerce infrastructure providers, whose competition will make them vastly cheaper -- like the printing businesses used by catalogers today.
The industry will only grow as more and more niches are populated and the infrastructural costs plummet.
According to the site your servlets will be running about 10 times slower than perl.
I see the opposite in those same benchmarks. I'm not promoting Java. I'm just looking at the table you refer to. Look at the hits per second *per MHz*, not the simple hits/s column. Java is running on a machine with only half the processor speed, and when you compensate for that, Java servlets outperform mod_perl (again, in *these* benchmarks, for what they're worth.)
The problem isn't Unicode, it's the lack of sufficient Unicode support in Linux (so far). Unfortunately, Gtk (so GNOME) and Qt (so KDE) overlooked the recent lessons of MS (NT), Sun (Java), Oracle (8), Perl (5.6), Apple (OSX), XML, HTML 4, etc. and went ahead and designed "The" Standard Linux GUI based on the obsolete char == byte model instead of Unicode. Doh!
They then released them that way, so the brokenness will have to be maintained for backward (as in "primitive") compatibility as they now work to fix their mistakes and move on to Unicode.
The Trolls have taken full advantage of the fact that Qt is all C++ to replace all the method implementations with Unicode and added a Unicode-based string type that they will recommend in place of const char* for all future development. You'll still be able to use const char*, but it will be converted internally into a modern data type automatically if you don't do it yourself.
One of the highest priorities on RedHat's agenda when they started pumping resources into GNOME was to fix it's obsolete byte == char architecture. Unfortunately, it's a lot harder with C than with C++. In Qt, you'll think you're incrementing a const char* with a ++ operator, but what actually happens (due to operator overloading) is that you'll be advancing one unicode character in a unicode string. Doing the same in GNOME (GTK) is still just going to move a const char* one byte ahead. Because it's C, there will be a lot of extra pitfalls that the GTK people won't be able to paper over that the application developer will have to deal with personally.
This is likely to cause GNOME programmers to curse Unicode, when the real fault lies with the shortsighted architecture, which should have been based on Unicode to begin with.
As for Chinese character repertoire, Unicode is more than up to the task. It is essentially a superset of all official Chinese, Japanese, and Korean national character sets. (The exception is one Taiwanese standard (CCCII) that has never been implemented by any font maker because its absurdly long list of characters are mostly glyph variants, antique typos, and nonstandard forms for which there is little demand in Taiwan and essentially none anywhere else.)
That's not to say that there are no missing characters. There is a multinational group of representatives from China, Taiwan, Hong Kong, Japan, Korea, Vietnam, and the US whose job it is to continually determine what additional Chinese characters need to be added to Unicode/iso10646 for real-life applications, characters that don't even exist yet in their own national character standards.
These countries themselves do not want a kitchen sink approach to character sets, because it will make all other aspects of their national computing infrastructures more difficult (fewer complete fonts, bigger fonts, bigger memory footprints, larger collation tables, large equivalency tables for searches, etc.) The Asian specialists want to be as comprehensive as they can be without loading themselves down with a lot of obsolete baggage.
Support for legacy encodings and other considerations have given Unicode some warts, but it's clear to i18n specialists that a single, consistent, language-neutral text data format (encoding) is going to gradually replace most language-specific encodings. Unicode appears to be the clear choice, and Linux needs to reflect that to the greatest extent possible if it is to function as a general purpose OS in an interconnected world.
If I understand the announcement, this is an IDE written entirely in Java. This has been done before, by Sun among others, with little success.
Java is good for quite a few things, but it is unfortunately less than ideal for performance-intensive, client-side applications such as an IDE. At least so far. All popular Java IDEs at the moment are written in C/C++. IIRC, Visual J++ is the only example of a successful IDE with large chunks written in Java, and that's because those chunks just called standard Windows OS UI controls directly (via J/Direct), rather than being "Pure Java".
I look forward to hearing how this Java-based JBuilder stacks up against the C/C++-based JBuilder 3.
Human beings always want to know what's over the next hill, whether geographically or more abstractly in realms such as science.
It's what we do.
Granted, there are cultures that have fossilized, where further development is taboo. Do you want to belong to one of those societies? There are several to choose from.
Also, there are vast numbers of people who essentially squat on their haunches and ridicule the explorers or dig their heels in and actively oppose them (the former usually call themselves "intellectuals" and the latter usually call themselves "progressives", ironically). When the explorers occasionally find something really good, though, they'll grab a piece of it, without thanks and without any change in attitude.
There are a lot of us, though, who want to know what's over the next hill. Only a few of us ever find anything that turns out to have significant value, but you never know who those few will turn out to be. That's why we need to nurture this drive in society. If you don't pick berries in East Africa for a living, you're a beneficiary of that drive in your ancestors.
Slashdot Mirror
You're still releasing the carbon dioxide bound in those untapped oil fields and all that oil sand out of the ground and into the air.
It's far from certain, but there's pretty good reason to fear that such action would seriously warm the earth. If there's any non-linearity in the system -- and there's no reason to assume linearity -- then we could have a runaway greenhouse effect that we might be unable to stop.
I'm sure life would thrive on such a planet, but perhaps not human life.
If you want to know what influence other languages would have on software systems, look no farther than the big multinational corporations and the new systems they create. These companies, because of their size, pay much closer attention to non-Westerners than most open-source hackers ever will.
Virtually all new systems created by IBM, MS, Sun, Oracle, etc. are Unicode based, and have been for several years. Languages like Java and C# use 16-bit Unicode chars. All of Java's text widgets are designed to accept a Unicode string containing an arbitrary mix of any set of languages and to display them correctly (each version gets a little closer, but the proper foundation was laid from the start). IBM was the main driver behind that, but Sun readily agreed. Oracle would be happy if every database from now on were Unicode.
Contrast that to the brand new systems produced by the "enlightened" open source community of primarily Western hackers. Released several years after Java and other Unicode systems, GNOME 1.0 was once again based on the obsolete notion that char == byte. Unbelievable. KDE did the same thing. While KDE could mostly paper over it by using the features of C++ (they just upgraded the string class implementation to Unicode and relied on automatic type conversion), the C-based GNOME will have programmers falling into single-byte traps for years to come. This is the same problem that haunts Win9x developers that pure NT or pure Java developers don't have to worry about.
I can't help but think that if more developers of programming languages were Asian, for example, the concept of a real string class (multiple bytes per char) and truly multilingual text widgets would be given, not awkwardly grafted on in version 4 of everything.
I think the actions of multinationals (as compared to open source hackers who never venture far from home) demonstrate my point.
Replace "cyber" with "Bat" and you'd have a pretty authentic-sounding Batman episode
Also, notice this:
;-)
http://it.uk.freelancehq.com/nocomment.shtml
That pretty much makes the whole exercise a waste of time. If you're only allowed to post opinions that the agencies want posted, then they may as well just run banner ads.
Under UK law, if you have a bad experience with an agency but aren't *certain* that you can prove it, you'd better keep your mouth shut or move to the US. I guess that's one way to keep a lid on society.
I wouldn't bet on its being a minor language. This could meet the needs of a lot of Windows developers rather nicely, and it appears designed to work nicely in modern dev environments (i.e. something more than a generic text editor.)
It's amazing to me that once again, a new language has been introduced without Eiffel's innovative Design by Contract. This is the one feature James Gosling says he most regrets leaving out of Java. He left it out, he says, because at the last minute, when Java was suddenly being thrust into the limelight, he wasn't sure how to do it right, so he left it for later, and now it may be too late to really build it in (as opposed to bolting it on as an afterthought.) It looks as though, after years of hearing Gosling expressing such regrets, MS is going to go right ahead and repeat his mistake.
Grr.
Not an Internet language because it doesn't compile into bytecodes? What kind of definition is that? How about changing that definition to "useful for Internet developers"?
;-)
Sun has relentlessly pursued a policy that "the whole idea of Java" is to produce bytecode, as if that's really at the top of most Java users' agendas. Funny, but in every enterprise I've been involved with, the whole idea (on our -- the developers' -- side) was to have a quicker, easier, more reliable way to create good server-side apps. True, there is occasional use of Java on the client, but the majority of serious Java users use it as a server-side development language, where they couldn't care less about portable binaries, but the conveniences of the language itself are the attraction.
What we want is a language that lets us quickly whip together a powerful, fast, and reliable server-side app, then compile it into a blindingly fast executable, optimized for whatever server we happen to use. Once every few years, when we change server platforms, we'd be willing to recompile.
I would so much rather have a language that combined some of Java's (language) features, with an Eiffel/eXtremeProgramming-ish ability to *automatically* generate testing/assertion/designByContract debug scaffolding, based on explicit interface contracts expressed in the language, that could be turned on or off in a fine-grained way for a customized balance of speed and safety when compiling the production executable for deployment on the server. In other words, basically Eiffel, with some of the Internet-oriented features (and the marketshare!) of Java The Language.
If some sort of bytecode system were designed for the express purpose of allowing additional runtime performance optimizations, then that would be fine. Such a system, unlike Java's, wouldn't carry any baggage necessary solely to make the binary portable, nor any security checking baggage of the the sort that is only relevant when running as untrusted code, nor anything else that would interfere with the mission of creating rock-solid, blindingly fast, easy-to-create, multithreaded, inherently distributed server-side internet applications. Such bytecode would be purely a performance technology.
Now, it doesn't sound to me as though C# is anywhere near so innovative. I wouldn't expect it to be, given the source. I'm certainly not looking for another Windows-only language, but neither do I want another language that, like Java, is essentially designed to prevent me from using it to write great Windows apps.
An inability to produce bytecode would hardly make a language less interesting to most real Internet application developers that I know.
Karmageddon gets the award for being the only person in this thread who actually knew the answer, moderation notwithstanding.
Twenty years ago, we used the "learning curve" for strategic purposes. The Boston Consulting Group (our competitor) had pioneered its use for business and competitive analysis. It was the observation that unit manufacturing cost tends to decrease with the log of the cumulative number of units manufactured. That's a downhill curve, and a steep descent meant rapid learning, and was a sign of good organizational practices. A steep and consistent learning curve was characteristic of Japanese kaizen practices, which were of great interest in those days.
The fact that others haven't a clue what "learning curve" means is demonstrated by their inability to define it in any consistent and sensible way. It's just a way of co-opting specialist jargon as a way to make oneself sound like a specialist.
Now, ChrisWong insists "don't bore me with the truth, which is no longer relevant to anybody except those few who know what they're talking about, tell me instead how to blend in with the misinformed but trendy masses."
Ask and you shall receive.
Use the following guide: say "steep learning curve" when you mean difficult. Talk about the "parameters" of a problem. Say "bandwidth" when you mean time. That should get you started.
"I will readily retract and apologize for these statements if NSI does start pulling systematic monkey business with domains, but I'm not afraid b/c it isn't going to happen. Spend some time outside of Slashdot, get some fresh air, and stop making mountains out of nothing."
I think this is naive. Contrary to your belief, I and many other Slashdot readers are rather careful readers of other contracts. Yes, they are often surprising in the breadth of their claims, and yet we sign them anyway. This is because of legal precedent. Regardless of the specific wording of the contracts, there is a great deal of legal precedent demonstrating that the courts will protect consumers to a certain extent, and everything you mentioned was a consumer service.
What NSI is doing is setting precedent in an area of law that is still virgin territory. I consider their hosting of my domain to be the equivalent of their keeping my jewels in their safe deposit box in return for consideration: my monthly fee.
NSI is asserting that my domain, which pre-existed their company, is the creation and sole property of their company, to do with as they choose at their sole discretion. I don't actually suspect that they intend to simply take it and auction it off to the highest bidder. Nevertheless, they have now asserted their "right" to do exactly that if they so choose, and that if they do so, I have no recourse because it was theirs, not mine.
I want this assertion to be soundly trounced, both legally and commercially, before it sets a legal precedent with some scary ramifications. People who make statements such as yours are the ones who should really get out more. "I don't care what the contract says, bad things only happen to the other guy...." Lot of bad things happen to people in contractual relationships, and when they do, the wording of the contract and previous legal precedent matter enormously.
Imagine a scenario where NSI has created this precedent, but they don't meddle with any of our domains. "There," you say, "I told you." Then along comes another registrar. It offers to pay you to let them host your domain. "Wow," you say, "this is great! Real competition." You transfer your domain to them, Acme Domains, Inc., and once they've gathered enough of them, they turn around and repossess them and begin auctioning them off to other bidders. "Hey!" you scream. "What's the deal?"
They then inform you that they were only providing you with the equivalent of a phone number, that they didn't just take it (even though it's theirs) that they actually bought it from you originally, and now they are changing to a different line of business: domain auctions. Thank you very much. They point to the legal precedent set by NSI and the courts rule in their favor.
I think this is an issue that matters.
Good domain names are so difficult to obtain that they sell for millions. There are a lot of large institutions with big legal departments out there that would be horrified to learn of NSI's legal claim, but I'm willing to bet that few of them know about this yet. Once they find out, we'll have some powerful allies.
Imagine if your bank were to declare that your deposits with them were not physical, but electronic, and as such were merely forms of information that were the product of your contract with the bank. Therefore, they actually owned your money, allowing you to use it at their "sole discretion", and if you tried to move it to another bank, they had no legal responsibility if the "information" somehow ended up in the hands of a third party.
I would guess that if this move got out, there would be a run on the bank. That's exactly what should happen to NSI as well as any other institution that claims ownership of something I deposit with them for a fee.
I suggest that we generate a Slashdot effect on NSI by getting the word out anyway we can, to everyone who will listen, hopefully causing a run on this "bank".
NSI would then either have to publicly change its policy, or publicly explain its unchanged policy. The latter would probably put them out of business as all the folks in the world who give computer advice decided en masse to advise against NSI. Either way, it would make news.
All eyes would be on them, with the press sniffing around for stories of NSI "losing" domains that were transferred away from them, probably making them much more careful. At the same time, there would probably be a few large organizations willing to combine their legal resources in a bid to stop NSI. After all, NSI isn't just setting its own policies, it's setting precedents -- precedents that organizations with billions in intellectual property and large legal departments wouldn't want set.
This approach is about the only way I can think of to increase our likelihood, as small fish ourselves, of maintaining possession of our hard-won domain names in the face of this sort of outrageous behavior.
Thanks for a very useful posting. Posting as an AC means you don't get your frequent flyer miles, uh, moderator points, but here's a virtual 5 from me. ;-) Very helpful.
This could be solved with a "true status" bar feature. You could choose to display either the True Status bar or the legacy status bar via your browser preferences, but the true status bar would be the default in new browsers.
The true status bar could be a lot more informative than the one we have now in both major browsers. It would work for YOU, not for the website. It would tell you what things really MEANT when you passed the mouse over them before you ever clicked anything. It could blink or in some other way attract your attention if something seemed fishy on the page. For example, the visible anchor text appeared to contain a domain, but the HREF pointed to a different domain. Or if there were any <tags> in the URL text. Or if it noticed any tiny GIF on the page from a domain other than the domain of the page itself or with a URL that looked as though it contained more than a simple image name. Or light up a little chocolate chip icon if the page was using a cookie (click the cookie to allow or disallow it). Or if form data SUBMIT would submit the data to some domain other than the domain of the page. Or....
That's what a true status bar should offer us, not a place for annoying scrolling text that blocks our view of the URL behind a link.
smells like...victory
There are nowhere close to 100,000 Chinese characters, much less 200,000. That's mythology. The largest collections of Chinese characters are in the 50,000 to 80,000 range, and are mostly composed of glyph variants.
Today, Chinese experts make a distinction between character and glyph, and prefer to deal with glyph variants at the font level. This makes it so much simpler for Chinese software, such as search engines. For this reason, they are not anxious to use giant characters sets. Unicode is about the right size, and the Chinese official experts contributing to Unicode aren't anxious to add a lot more characters to Unicode. They still need to add a few, but are doing so very judiciously. Whatever they add, they know they'll have to support, so they frown on variant glyphs of the same character as separate characters. Sorting, searching, printing, font making...everything is tougher when you encode multiple versions of what really should be considered the same character. The experts don't want the permanent liability. It's really only nationalistic amateurs who make a big fuss about Unicode being "far from enough". The experts know better (though there will later be a full 64K character plane devoted to such variants outside the core "Basic Multilingual Plane" to quiet the complainers.)
The only thing that will happen to consumer e-commerce is that it will lose its "e" as it becomes just "commerce".
The catalog business has been growing for years. There are more consumer catalogs than ever being mailed out. E-commerce is just a more effective medium. There's no reason for a "backlash" against consumer e-commerce when there has been no such backlash against catalog sales.
Granted, there will be a lot of b2b e-commerce, but there's already a ton of b2b catalog commerce, too. That hasn't devastated the consumer catalog industry.
What we have now is a lot of consumer e-commerce pioneers building their infrastructure by hand and trying to dominate large industries. No wonder they're profit-impaired. The original Sears catalog business was like that -- except that they went more slowly and allowed themselves some profits for a few decades -- but time brought changes along with an overall growth in catalog sales.
Sears's catalog business didn't survive the changes, but it wasn't any "backlash", and the industry didn't shrink. Quite the contrary.
Most companies in catalog commerce today are small outfits that outsource most aspects of their infrastructure and try to dominate a small market niche. Consumer e-commerce will grow overall, and grow in that direction. Most companies will outsource to a growing number of full-service e-commerce infrastructure providers, whose competition will make them vastly cheaper -- like the printing businesses used by catalogers today.
The industry will only grow as more and more niches are populated and the infrastructural costs plummet.
I see the opposite in those same benchmarks. I'm not promoting Java. I'm just looking at the table you refer to. Look at the hits per second *per MHz*, not the simple hits/s column. Java is running on a machine with only half the processor speed, and when you compensate for that, Java servlets outperform mod_perl (again, in *these* benchmarks, for what they're worth.)
The problem isn't Unicode, it's the lack of sufficient Unicode support in Linux (so far). Unfortunately, Gtk (so GNOME) and Qt (so KDE) overlooked the recent lessons of MS (NT), Sun (Java), Oracle (8), Perl (5.6), Apple (OSX), XML, HTML 4, etc. and went ahead and designed "The" Standard Linux GUI based on the obsolete char == byte model instead of Unicode. Doh!
They then released them that way, so the brokenness will have to be maintained for backward (as in "primitive") compatibility as they now work to fix their mistakes and move on to Unicode.
The Trolls have taken full advantage of the fact that Qt is all C++ to replace all the method implementations with Unicode and added a Unicode-based string type that they will recommend in place of const char* for all future development. You'll still be able to use const char*, but it will be converted internally into a modern data type automatically if you don't do it yourself.
One of the highest priorities on RedHat's agenda when they started pumping resources into GNOME was to fix it's obsolete byte == char architecture. Unfortunately, it's a lot harder with C than with C++. In Qt, you'll think you're incrementing a const char* with a ++ operator, but what actually happens (due to operator overloading) is that you'll be advancing one unicode character in a unicode string. Doing the same in GNOME (GTK) is still just going to move a const char* one byte ahead. Because it's C, there will be a lot of extra pitfalls that the GTK people won't be able to paper over that the application developer will have to deal with personally.
This is likely to cause GNOME programmers to curse Unicode, when the real fault lies with the shortsighted architecture, which should have been based on Unicode to begin with.
As for Chinese character repertoire, Unicode is more than up to the task. It is essentially a superset of all official Chinese, Japanese, and Korean national character sets. (The exception is one Taiwanese standard (CCCII) that has never been implemented by any font maker because its absurdly long list of characters are mostly glyph variants, antique typos, and nonstandard forms for which there is little demand in Taiwan and essentially none anywhere else.)
That's not to say that there are no missing characters. There is a multinational group of representatives from China, Taiwan, Hong Kong, Japan, Korea, Vietnam, and the US whose job it is to continually determine what additional Chinese characters need to be added to Unicode/iso10646 for real-life applications, characters that don't even exist yet in their own national character standards.
These countries themselves do not want a kitchen sink approach to character sets, because it will make all other aspects of their national computing infrastructures more difficult (fewer complete fonts, bigger fonts, bigger memory footprints, larger collation tables, large equivalency tables for searches, etc.) The Asian specialists want to be as comprehensive as they can be without loading themselves down with a lot of obsolete baggage.
Support for legacy encodings and other considerations have given Unicode some warts, but it's clear to i18n specialists that a single, consistent, language-neutral text data format (encoding) is going to gradually replace most language-specific encodings. Unicode appears to be the clear choice, and Linux needs to reflect that to the greatest extent possible if it is to function as a general purpose OS in an interconnected world.
If I understand the announcement, this is an IDE written entirely in Java. This has been done before, by Sun among others, with little success.
Java is good for quite a few things, but it is unfortunately less than ideal for performance-intensive, client-side applications such as an IDE. At least so far. All popular Java IDEs at the moment are written in C/C++. IIRC, Visual J++ is the only example of a successful IDE with large chunks written in Java, and that's because those chunks just called standard Windows OS UI controls directly (via J/Direct), rather than being "Pure Java".
I look forward to hearing how this Java-based JBuilder stacks up against the C/C++-based JBuilder 3.
Human beings always want to know what's over the next hill, whether geographically or more abstractly in realms such as science.
It's what we do.
Granted, there are cultures that have fossilized, where further development is taboo. Do you want to belong to one of those societies? There are several to choose from.
Also, there are vast numbers of people who essentially squat on their haunches and ridicule the explorers or dig their heels in and actively oppose them (the former usually call themselves "intellectuals" and the latter usually call themselves "progressives", ironically). When the explorers occasionally find something really good, though, they'll grab a piece of it, without thanks and without any change in attitude.
There are a lot of us, though, who want to know what's over the next hill. Only a few of us ever find anything that turns out to have significant value, but you never know who those few will turn out to be. That's why we need to nurture this drive in society. If you don't pick berries in East Africa for a living, you're a beneficiary of that drive in your ancestors.
Let's see what's out there....