People like to get all worked up about human cloning. I don't see the problem. We allow just about anybody to create human life in whatever random and nonsensical combinations they like, we let just about anybody twist the minds of young kids in whatever way they feel like it (Helms had children, didn't he?), and people have kids for all sorts of reasons already, from status symbol to cheap labor to spare parts. Distasteful as many of the possibilities may seem, it's probably good that we do: the alternatives have been tried and they have always turned out to be worse. In real life, most kids usually turn out OK anyway, and we have laws and mechanisms for dealing with the more egregious abuses.
Of course, we might be particularly suspicious about the motivations for people wanting to have a "clone" and what kind of psychological implications it has. But there is nothing particularly new about it. Most of the genetic manipulations people are worried about with cloning don't require cloning. You can already create and select children specifically for tissue compatibility. And parents already project all sorts of ideas on their children, including "the kid looks just like me", even when the idea seems completely ridiculous to an innocent bystander.
Just about the only thing that to me looks like a possible concern is a loss of genetic diversity in the human population, similar to what we have seen in our crops and livestock. But that is merely theoretical as far as I'm concerned. Any program of cloning that would put us at risk would be enormous, and other attempts at manipulation have failed miserably (China can't even get people to have only one child). Furthermore, cloning is so expensive, time consuming, and unpleasant (compared to the traditional way) that it wouldn't become a threat to diversity until a large part of the world population could afford it; we can worry about that when we have conquered world hunger and poverty.
I do agree fully that web sites should not use IE or NS-specific features. But to conclude from that that people should therefore be forced to upgrade is wrong.
People have lots of legitimate reasons for not upgrading. Their hardware may not support it. They may not be able to pay for it. They may be on a slow connection or wireless device. And they may need special accessibility features.
Any web site that relies on the presence of the complex web features is broken. Sites should be able to render fine with no JavaScript, no DOM, no pixel-accurate positioning, and no graphics even. If they want to offer a graphically overburdened site in addition to a plain one, that's fine, but that should be an option.
Most old browsers are perfectly serviceable for rendering plain HTML and graphics. If someone with an old browser comes to a web site, the site should fall back to its plain version. It shouldn't complain or hassle the user.
People say that with the limited range, this isn't going to be a problem. But the range is going to get bigger; there is no technical reason why it shouldn't. The main reason why the range is limited right now is because the scanners need to be fairly cheap for its current market. If you can spend $100000 per scanner as opposed to $1000 for a scanner, you can do a lot more. And lots of people will have an incentive to spend just that kind of money to track people.
If you carry a set of tags that respond to RF, you can bet that they will be used within a few years for tracking your every move through a store. You'll probably get incentives to carry special ones that are linked to your identity. If you don't, some services may not be available to you, and people will track you based on the random tags that came with your clothes anyway.
Of course, you will have the "right" not to use them, just like you can, in principle, make all your transactions in cash, not drive a car, and not have a telephone number. Well, actually, in the US, there are people who live that way: the homeless.
See, that's the problem with this kind of infrastructure: once society accepts it widely, you don't have a choice but to use it yourself.
I think the ISP could have acted on the request. No, it shouldn't have shut down individual newsgroups; doing that would be pointless. Newsgroups are merely a convenient advisory classification by the senders, and content like this just moves to a different newsgroup.
Instead, the ISP should have asked the attorney general for identifying information other than the newsgroup present on offending messages that they could have used to remove those postings. If that information was forged at their site, they should have referred the attorney general to the upstream site and stopped the problem there. This is no different from spam or other USENET abuse, and there have been mechanisms for dealing with it since the beginning.
Now, there are two possibilities. Either the ISP was incompetent and didn't know what it should really do to stop this. Or the ISP was receiving forged headers from their upstream site and the attorney general interpreted the ISP's referral to the upstream site as inaction. It's hard to tell from the press release. I would, however, blame the ISP for not standing by its convictions: once it decided that it wasn't going to act on the request as made by the attorney general, it should not have settled later without going to court.
Of course, a more general question is whether we should shut down established communications channels because they can be used in this way. For example, should we consider shutting down the US post office because it can be used to mail offending material? Should we shut it down because header information can be forged with just a pen? Should we shut it down because it provides untraceable anonymous distribution of gigabytes of data for a few cents per giant packet? Should we require the post office to open every letter and inspect it for offensive content? I think there are still a few countries that do that sort of thing...
Copyright law is a two-way deal: society grants legal protection for a limited time, and in return, the material becomes public after that time. But music and movie industries are busy on locking up content in proprietary formats protected by all sorts of cryptographic gadgets. Thus, the music and movie industries are currently engaging in blatant violations of the constitutional basis of copyright law..
Yes, I agree technology requires new laws. But I wouldn't be worried about Disney or Sony losing money. If those companies went out of business tomorrow, very little of actual cultural value would be lost. Almost all our cultural heritage has been created without the benefit of copyrights, and the argument that we need extensive copyright protections now is flimsy at best.
I'd be concerned foremost about having mechanisms installed everywhere that give a few companies complete control over how and what we communicate. The risk of that isn't merely that Disney won't be able to make hundreds of millions with the latest rip-off of a 19th century fairy tale, the risk of that goes to the core of our democracy and freedoms.
My zipcode has perhaps 5000 people in it. My day of birth is shared by roughly 1/300th of the population, and my age probably by no more than 1/30th of the population.
So, if I give you my zip code, day of birth, and age, there is a good chance that you can identify me uniquely based on publically accessible records. Any additional information, like income level, first name, hobbies, years of residence in this zip code, marital status, gender, etc. makes such identifications very reliable.
There isn't a lot of anonymity, either off-line or on-line.
What are the downsides of allowing the compiler to accept foo(b) as valid code?
I think it's a particular tradition of OOP, in which the inheritance hierarchy is viewed as a classification of real-world objects. An OOP theorist would say that just because you can "smoke a cigarette" and "smoke a ham", you wouldn't want to substitute one for the other. That's valid, but it doesn't explain why you can't give the programmer both choices (besides, there are much better ways of dealing with that problem).
The other reason is probably concerns about efficiencies. But years of experience with Objective-C compilation show that even a fully dynamic runtime can get very close to method dispatch overhead of plain C++. And the "signature" approach turns out not to require any more overhead than plain C++ vtbls (btw, don't bother looking for signatures in GNU C++ anymore--they got sacrificed on the altar of strict ANSI C++ compliance, like so many other good GNU C++ features).
Could you expand a little more why is it so bad of having classes A & B inherit from a common "interface" class (with potential virtual functions)? Does it lead to class-inheritance bloat?
Yes: since a client can't add interfaces, the library writer need to enumerate, ahead of time, all the different combinations of methods that might conceivably be useful and create a separate interface for them. 10 methods--about 1000 possible interfaces, 20 methods--about 1 million possible interfaces. Naturally, programmers don't do that. They pick a bunch of interfaces that are meaninful, and then they muddle through with writing adapters, partial implementations, and methods that do nothing but throw an "UnimplementedException". And in Visual C++, the IDE kicks in an tries to generate "adapters" for you through wizards--less typing but lots of code bloat.
In Java, this has led to a proliferation of classes: you get a hierarchy of interfaces, and then you get a hierarchy of "adapters" that implement those interfaces and provide default implementations for the cases where you didn't need to do anything in the first place. And because, unlike C++, Java does try to provide a large OO library as part of the standard, the language limitations start to show up. I think that's in part why people find Java so painful, even though technically, Java is a lot more forgiving and flexible than C++.
Thx for the discussion. This topic makes/. worthwhile.
class A {
public void method1(int);
public void method2(char*);
public void method3(double);
}
void foo(A *obj) {
obj->method1(3);
obj->method2("s");
}
Now, the only kind of object you can pass is of class "A" or a subclass. For static type safety, however, all that really matters is that the argument to "foo" is an object that has a "method1(int)" and a "method2(char*)". The additional requirement that the argument is of class "A" or a subclass is an additional restriction that may or may not model some aspect of the problem you are trying to solve and you may want to express it sometimes. It may even protect you from mistakes sometimes. But it isn't necessary for "type safety", in the same sense that declaring variables as "int" or "float" is necessary.
Dynamically typed OOLs like Smalltalk avoid this restriction entirely. In statically typed languages, it's pretty rare to support this feature. GNU C++ had support for it in the form of the "signature" extension (templates may seem to give you similar functionality, but they don't really).
Well, there are several related issues, and I probably didn't explain the differences well enough in such a short space. Dynamic languages avoid this problem, but I didn't mean to imply that statically typed languages can't also avoid it.
Java, for example, couples libraries and user code much less tightly, yet uses statically type checked interfaces. Java's type checking is actually unnecessarily strict: classes are considered incompatible on dynamic linking even though only some aspects of their implementation changed. ML implementations could easily do the same thing.
Also, the fact that languages like C++ and Java tie inheritance hierarchies to static type checking is an unnecessary and idiosyncratic restriction. You can have perfectly statically type-safe systems that do not have these kinds of inheritance constraints: as long as the compiler and/or linker determines that the aspects of the interfaces you are relying on are type-compatible, it can make the two ends fit together safely, no matter what other changes or additions have happened to the classes. The "signature" extension for GNU C++ did this at compile time, and something similar could be done by the dynamic linker when libraries are loaded.
The efficiency issue is not significant. Even for a completely dynamic object system like Objective-C, a good runtime will have hardly more overhead for a dynamic method call than a regular function call. Any of the systems based on static type checking I mentioned above would do even better. And Java, of course, can actually do better than C/C++ when it comes to libraries because the Java runtime can (and does) inline library code as native code at load/execution time.
Of course, sometimes, things just have to change incompatibly. But as far as I can tell, almost none of the changes in glibc (or most other C/C++ libraries I use regularly) should affect any user code. Almost any kind of library interface would be less problematic than what exists right now.
So, I agree: statically typed languages will not go away. But "DLL hell" is avoidable whether you use statically or dynamically typed languages. In fact, as I mentioned, you could even make it go away in C/C++ by introducing a special library calling convention that has a bit more information available at load time. However, why beat a dead horse?
When you pass arguments or structures across the C ABI, each side has a lot of detailed, intricate knowledge of the layouts and sizes of data structures and other details. That means that even fairly minor changes, like adding another field to a structure, may mean that everything needs to be recompiled. Having that kind of detailed knowledge has efficiency advantages, but you pay a serious price in terms of software configuration problems. In the days of the PDP-11, it may have been worth making that tradeoff for most function calls, in the days of 1GHz P4's, it probably isn't except in rare cases.
Are there alternatives? Plenty, actually:
COM was an attempt to address some of these issues in a C++ framework. Unfortunately, the road to hell is paved with good intentions. Trying to retrofit this infrastructure on top of C++ leaves you with a bad kludge on top of an already cumbersome object system.
Dynamic languages like Python, CommonLisp, Smalltalk, etc. generally don't suffer from this problem: as long as the objects you are passing around to roughly the right thing, it usually doesn't matter what you change behind the scenes: the code will still "link" and run.
This problem could have been addressed easily without straying much from traditional C if people had adopted Objective-C. Objective-C is a minimalistic extension of C that adds just these kinds of "flexible" and "loosely coupled" interfaces to the C language.
Java is halfway there: there are a lot more kinds of changes and upgrades you can do to libraries than in C, but it isn't quite as flexible as more dynamic languages.
You could probably invent a new calling convention for C together with some changes to the dynamic linker that would address this problem for C libraries. While you are at it, you should probably also define a new ABI for C++, something that avoids "vtbl hell" using an approach to method invocation similar to Objective-C. These new calling conventions would be optional, so that you can pick one or the other, depending on whether you are calling within the same module or between different modules. Perhaps that's worth it given how much C/C++ code is out there, but it sure would be a lot of work to try and retrofit those languages. Why not use one of the dozens of languages that fix not just this problem but others as well?
A related approach is to still write a lot of stuff in C/C++ but wrap it up in a dynamic language and handle most of the library interactions through that. That was the dream of Tcl/Tk (too bad that the language itself had some limitations).
Altogether, I think the time to fix this in C/C++ has passed, and COM-like approaches didn't work out. My recommendation would be: write your code in a language that suffers less from these problems, Python and Java are my preference, and add C/C++ code to those when needed for efficiency or system calls.
The Lisp Machine GUI had windows that were much like a command line interface: you'd type commands and output would appear. However, the output wasn't just passive, it was an actual GUI. For example, in a directory listing, you could click on files and manipulate them. If you displayed an image, it would appear just like text output in the transcript and you could click on it and interact with it. You could also have input fields and other stuff appear in the output. In effect, each part of the output would stay "connected" to the code that generated that.
Translating that into a UNIX environment is a bit harder, but it might be worth having another go at at it, perhaps based on XML and web infrastructure.
You can compensate for many problems with microphones and acoustics using signal processing. It's kind of like modems can compensate for many problems with telephone lines and still give you very high data rates. Cheap sensors with smart processing is the future of audio and video.
They want to know about consumer complaints, and this seems like a breach of contract to me. If this happens a lot (and it probably does), the company can and should get into legal trouble for it.
Also, many stores now have the annoying habit of listing their prices with rebates included. If I get to the checkout and the rebate doesn't apply or looks like too much hassle, I don't buy the item and just leave it with the cashier.
So,if Germany decides to implement blocking at the ISP level, how is that different from the US? In the US, if the police believe that you have or publish "bad" content (pirated, objectionable, etc.) they can confiscate your computers and media, without any trial or due process.
I think many people in the US live in a state of denial in this area. There are lots of rights guaranteed on paper or assumed to exist, but in reality, when it comes to privacy, freedoms, and protection from unreasonable government actions, the situation is considerably worse than in many other countries. Many policy decisions in the US seem to be hidden behind code words, and informed public debate seems to rarely takes place.
I think it would be unfortunate if Germany adopted this proposed policy (and that's all it is for now). But at least there is an open debate about it and the cards are on the table. I think if it were to be implemented, it would likely come along with other legal provisions that protect consumers. For example, one thing to put on the table for the purpose of negotiations might be a requirement for publishers to publish their content in formats that allow copying. That could be a reasonable tradeoff, giving publishers a bit more confidence that they can effectively shut down pirate sites, in return for publishing stuff in a way that doesn't lock it up in perpetuity.
The present exploit has to do with unsafe languages in two ways. First, it allows an arithmetic operation to overflow without catching the error. Second, it allows an out-of-bounds memory reference based on that erroneous result. Any decent systems programming language with safety features should have caught both errors.
C is a "good language for doing systems work" if safety, security, and correctness are not very high priorities and if your programs are reasonably small. That was true of the original UNIX system. It isn't true of something like SSH or other network services (security is of paramount importance) and it isn't true either of huge GUI applications (too many potential sources of errors to ever get something really reliable).
(In theory, C++ could be a little better, but in practice, the way C++ is actually used, the same comments apply to C++.)
so what is this like 4th r00t expliot from ssh? You would really think that people making an
app to improve security would be more careful about this
In C, it's very hard to get this right: just about every statement can lead to these kinds of problems: unchecked overflows, unchecked pointer dereferences, etc. People simply cannot handle that complexity and also get the code to work right. There are doubtlessly lots and lots of other problems like this in ssh, as well as most other Linux, UNIX, and Windows programs. (C++ lets you do a little better in principle, but the way most people use it, it's just as bad.)
If you want to write code that doesn't suffer from these problems without spending many times as much time on trying to find such silly bugs compared to expressing the actual algorithm, use a language that has some built-in error checking. Java, Modula-2, Modula-3, Ada, Oberon, whatever.
Clunky? Inconvenient? Not as many libraries available in those languages? All true. But that's because they aren't used enough, not because there is anything inherently wrong with them.
It's an incredible waste of money to put all your data in RAM. You are much better off having a large solid state cache in front of a traditional disk drive.
If you have battery backup for the solid state cache and if it's reasonably large, then you get pretty much the same effect as if you had a disk consisting of all RAM. Sun used to sell something like that for speeding up NFS called "PrestoServe".
Of course, Linux already has non-battery-backed-up RAM caches built in. The interesting thing is that even if the kernel crashes, you can usually recover the unwritten data from RAM and (after verifying something like a checksum) write it out to disk (this fails, of course, on platforms where the BIOS messes around with memory before the OS boots).
So, the best thing to do is probably to have battery backup for your RAM and processor and use an operating system that recovers information from RAM after a crash. That way, you can use normal RAM for caching, and if your machine crashes, you can recover quickly and with no or minimal loss of data.
Ricochet service costs, what, $80/month for a connection that's around a 56k modem, close to ISDN speed if you are lucky. $960/year is a lot of money for that kind of connectivity. I suspect at those prices it will mostly appeal to people who really, really need it, or to people who have a lot of money to spare.
I'd be willing to pay, say, $30/month for such a service. That would be a little more expensive than dial-up, but it would be a convenience around the house and to take to a cafe or park.
Raskin may have been one of the first people to argue that computers don't need character generators. So what? That's not what's at issue here.
At issue is the clunky way in which most current GUIs, including the Macintosh and Window burden the user with concepts like "files" and "applications".
As a criticism of OS X, Raskin is right, and what he says applies equally to Windows, Gnome, and KDE. But Apple didn't have a choice: they were trapped in their own legacy. That was a problem Raskin himself could have helped avoid in the 1980s.
Meanwhile, devices and services like Apple's own Newton, Palm Pilots, broadband phones, web-based applications, and game consoles are already redefining what "operating system" and "application" mean.
Several systems prior to the Macintosh, among them Smalltalk, had a much more integrated approach to applications, documents, and data. You didn't have to "start up" applications, exchange data via files, or all the other clunkiness found in "modern" desktop systems. And while none of those systems realized it fully, the writing for an easy-to-use, persistent object-based desktop system without mainframe holdovers like "files" and "applications" was on the wall.
Then came along Apple with their underpowered Macintosh programmed in assembly language and Pascal. They produced something that looked nice, but its model of applications and data was not much different from your average DOS machine. And that metaphor has held the desktop in a tight grip ever since and been copied over and over again, by Windows and now Gnome and KDE.
I think what Raskin is complaining about is ultimately due to Apple and their initial success with what was already then a broken paradigm. It seems like adding insult to injury for an Apple employee to come back now, 15 years later, and say that everybody is doing things wrong. Well, of course we are doing things wrong. That's because the market and users expect things to be done "wrong". Undoing the damage now will be much harder because everybody now expects things to be done that way.
uwm didn't add any window decorations. It merely left windows with their standard borders. You moved windows around with meta keys. It was a very lightweight and pretty innocuous. The main problem with it was that new users walking up to a UNIX machine had no idea how to move windows around.
You can get a similar look with the Sawfish "nanoGUI" theme.
It's hard to see how uwm could be considered "ugly" since it largely just left your windows alone. In fact, I think "twm" looked worse, but it ended up being more usable for new X11 users because they could just grab title bars, without using any keys.
Wiegand compared Linux to a "fallen angel," and claimed
that actually it had "fallen more than it had climbed."
Under the new economy, he said, "expectations were
greater than the deliverables" and that "expectations are
now below zero," suggesting that that's where SUSE
business prospects are too.
There is nothing wrong with Linux. There is plenty wrong with companies that think they can build huge business empires on repackaged free software. Packaging distributions will at best be a small margin business. Actually, it will probably turn into a loss leader for other services. With better package systems and Internet upgrade support, "distributions" themselves may become an anachronism.
SuSE, of course, seems to be trying particularly hard to turn Linux into something commercial. The demo disks I have gotten from them have not been all that useful, and unlike many other vendors, they do not seem to provide ISO images of their distribution on-line.
Let's hope that all this greed from VCs and business people won't end up giving Linux and free software a bad name. Those people placed poor bets, and they only have themselves to blame.
Free software isn't about SuSE or RedHat. Those companies are largely opportunists with no obvious long-term business model. Free software was around before SuSE and RedHat, and it will be around long afterwards. Why? Because it makes a lot more economic sense for customers to help create free software than it makes for them to buy software.
If you buy commercial software, you pay a lot more for each release than the incremental enhancements that actually occurred. You do this because it would be too costly to switch. To add insult to injury, many of the enhancements in commercial software come from the customers in the first place.
There are different kinds of experience. There is the experience of building a big, complex software system. And there is the experience of seeing it evolve over years, finding new uses, having bugs fixed in it, having the vendor drop support for tools used for building it, having different development organizations take it over, etc.
You can get the first kind of experience by working really hard. But to have first hand experience of how a software system you built evolves over ten years in the real world, you have to be there for ten years.
There are other kinds of experience that are difficult to accomplish simply through effort alone. The long-term coming and going of corporate strategies, new languages, platforms, etc. is hard to understand even if you were to become a computer historian.
Sometimes that kind of long-term experience doesn't help, sometimes it even gets in the way, and sometimes, it's vitally important. I suspect that when people don't listen to you, it's in areas where they consider that kind of experience important.
CNN reports that USA Today reports that CIA Director Tenet wrote a letter last March (!) to the Senate Foreign Relations Committee that terrorists are using encryption? And that's news? The CIA has been claiming this for years. And, you know, it's probably true. So what? Terrorists use air and water as well, yet most people would agree that we shouldn't ban air and water.
Which leaves me wondering: why is this being dredged up now? Is the administration preparing for another assault on cryptography?
Slashdot Mirror
Of course, we might be particularly suspicious about the motivations for people wanting to have a "clone" and what kind of psychological implications it has. But there is nothing particularly new about it. Most of the genetic manipulations people are worried about with cloning don't require cloning. You can already create and select children specifically for tissue compatibility. And parents already project all sorts of ideas on their children, including "the kid looks just like me", even when the idea seems completely ridiculous to an innocent bystander.
Just about the only thing that to me looks like a possible concern is a loss of genetic diversity in the human population, similar to what we have seen in our crops and livestock. But that is merely theoretical as far as I'm concerned. Any program of cloning that would put us at risk would be enormous, and other attempts at manipulation have failed miserably (China can't even get people to have only one child). Furthermore, cloning is so expensive, time consuming, and unpleasant (compared to the traditional way) that it wouldn't become a threat to diversity until a large part of the world population could afford it; we can worry about that when we have conquered world hunger and poverty.
People have lots of legitimate reasons for not upgrading. Their hardware may not support it. They may not be able to pay for it. They may be on a slow connection or wireless device. And they may need special accessibility features.
Any web site that relies on the presence of the complex web features is broken. Sites should be able to render fine with no JavaScript, no DOM, no pixel-accurate positioning, and no graphics even. If they want to offer a graphically overburdened site in addition to a plain one, that's fine, but that should be an option.
Most old browsers are perfectly serviceable for rendering plain HTML and graphics. If someone with an old browser comes to a web site, the site should fall back to its plain version. It shouldn't complain or hassle the user.
If you carry a set of tags that respond to RF, you can bet that they will be used within a few years for tracking your every move through a store. You'll probably get incentives to carry special ones that are linked to your identity. If you don't, some services may not be available to you, and people will track you based on the random tags that came with your clothes anyway.
Of course, you will have the "right" not to use them, just like you can, in principle, make all your transactions in cash, not drive a car, and not have a telephone number. Well, actually, in the US, there are people who live that way: the homeless.
See, that's the problem with this kind of infrastructure: once society accepts it widely, you don't have a choice but to use it yourself.
Instead, the ISP should have asked the attorney general for identifying information other than the newsgroup present on offending messages that they could have used to remove those postings. If that information was forged at their site, they should have referred the attorney general to the upstream site and stopped the problem there. This is no different from spam or other USENET abuse, and there have been mechanisms for dealing with it since the beginning.
Now, there are two possibilities. Either the ISP was incompetent and didn't know what it should really do to stop this. Or the ISP was receiving forged headers from their upstream site and the attorney general interpreted the ISP's referral to the upstream site as inaction. It's hard to tell from the press release. I would, however, blame the ISP for not standing by its convictions: once it decided that it wasn't going to act on the request as made by the attorney general, it should not have settled later without going to court.
Of course, a more general question is whether we should shut down established communications channels because they can be used in this way. For example, should we consider shutting down the US post office because it can be used to mail offending material? Should we shut it down because header information can be forged with just a pen? Should we shut it down because it provides untraceable anonymous distribution of gigabytes of data for a few cents per giant packet? Should we require the post office to open every letter and inspect it for offensive content? I think there are still a few countries that do that sort of thing...
Yes, I agree technology requires new laws. But I wouldn't be worried about Disney or Sony losing money. If those companies went out of business tomorrow, very little of actual cultural value would be lost. Almost all our cultural heritage has been created without the benefit of copyrights, and the argument that we need extensive copyright protections now is flimsy at best.
I'd be concerned foremost about having mechanisms installed everywhere that give a few companies complete control over how and what we communicate. The risk of that isn't merely that Disney won't be able to make hundreds of millions with the latest rip-off of a 19th century fairy tale, the risk of that goes to the core of our democracy and freedoms.
So, if I give you my zip code, day of birth, and age, there is a good chance that you can identify me uniquely based on publically accessible records. Any additional information, like income level, first name, hobbies, years of residence in this zip code, marital status, gender, etc. makes such identifications very reliable.
There isn't a lot of anonymity, either off-line or on-line.
I think it's a particular tradition of OOP, in which the inheritance hierarchy is viewed as a classification of real-world objects. An OOP theorist would say that just because you can "smoke a cigarette" and "smoke a ham", you wouldn't want to substitute one for the other. That's valid, but it doesn't explain why you can't give the programmer both choices (besides, there are much better ways of dealing with that problem).
The other reason is probably concerns about efficiencies. But years of experience with Objective-C compilation show that even a fully dynamic runtime can get very close to method dispatch overhead of plain C++. And the "signature" approach turns out not to require any more overhead than plain C++ vtbls (btw, don't bother looking for signatures in GNU C++ anymore--they got sacrificed on the altar of strict ANSI C++ compliance, like so many other good GNU C++ features).
Yes: since a client can't add interfaces, the library writer need to enumerate, ahead of time, all the different combinations of methods that might conceivably be useful and create a separate interface for them. 10 methods--about 1000 possible interfaces, 20 methods--about 1 million possible interfaces. Naturally, programmers don't do that. They pick a bunch of interfaces that are meaninful, and then they muddle through with writing adapters, partial implementations, and methods that do nothing but throw an "UnimplementedException". And in Visual C++, the IDE kicks in an tries to generate "adapters" for you through wizards--less typing but lots of code bloat.
In Java, this has led to a proliferation of classes: you get a hierarchy of interfaces, and then you get a hierarchy of "adapters" that implement those interfaces and provide default implementations for the cases where you didn't need to do anything in the first place. And because, unlike C++, Java does try to provide a large OO library as part of the standard, the language limitations start to show up. I think that's in part why people find Java so painful, even though technically, Java is a lot more forgiving and flexible than C++.
Thanks.class A {
public void method1(int);
public void method2(char*);
public void method3(double);
}
void foo(A *obj) {
obj->method1(3);
obj->method2("s");
}
Now, the only kind of object you can pass is of class "A" or a subclass. For static type safety, however, all that really matters is that the argument to "foo" is an object that has a "method1(int)" and a "method2(char*)". The additional requirement that the argument is of class "A" or a subclass is an additional restriction that may or may not model some aspect of the problem you are trying to solve and you may want to express it sometimes. It may even protect you from mistakes sometimes. But it isn't necessary for "type safety", in the same sense that declaring variables as "int" or "float" is necessary.
Dynamically typed OOLs like Smalltalk avoid this restriction entirely. In statically typed languages, it's pretty rare to support this feature. GNU C++ had support for it in the form of the "signature" extension (templates may seem to give you similar functionality, but they don't really).
Java, for example, couples libraries and user code much less tightly, yet uses statically type checked interfaces. Java's type checking is actually unnecessarily strict: classes are considered incompatible on dynamic linking even though only some aspects of their implementation changed. ML implementations could easily do the same thing.
Also, the fact that languages like C++ and Java tie inheritance hierarchies to static type checking is an unnecessary and idiosyncratic restriction. You can have perfectly statically type-safe systems that do not have these kinds of inheritance constraints: as long as the compiler and/or linker determines that the aspects of the interfaces you are relying on are type-compatible, it can make the two ends fit together safely, no matter what other changes or additions have happened to the classes. The "signature" extension for GNU C++ did this at compile time, and something similar could be done by the dynamic linker when libraries are loaded.
The efficiency issue is not significant. Even for a completely dynamic object system like Objective-C, a good runtime will have hardly more overhead for a dynamic method call than a regular function call. Any of the systems based on static type checking I mentioned above would do even better. And Java, of course, can actually do better than C/C++ when it comes to libraries because the Java runtime can (and does) inline library code as native code at load/execution time.
Of course, sometimes, things just have to change incompatibly. But as far as I can tell, almost none of the changes in glibc (or most other C/C++ libraries I use regularly) should affect any user code. Almost any kind of library interface would be less problematic than what exists right now.
So, I agree: statically typed languages will not go away. But "DLL hell" is avoidable whether you use statically or dynamically typed languages. In fact, as I mentioned, you could even make it go away in C/C++ by introducing a special library calling convention that has a bit more information available at load time. However, why beat a dead horse?
Are there alternatives? Plenty, actually:
You could probably invent a new calling convention for C together with some changes to the dynamic linker that would address this problem for C libraries. While you are at it, you should probably also define a new ABI for C++, something that avoids "vtbl hell" using an approach to method invocation similar to Objective-C. These new calling conventions would be optional, so that you can pick one or the other, depending on whether you are calling within the same module or between different modules. Perhaps that's worth it given how much C/C++ code is out there, but it sure would be a lot of work to try and retrofit those languages. Why not use one of the dozens of languages that fix not just this problem but others as well?
A related approach is to still write a lot of stuff in C/C++ but wrap it up in a dynamic language and handle most of the library interactions through that. That was the dream of Tcl/Tk (too bad that the language itself had some limitations).
Altogether, I think the time to fix this in C/C++ has passed, and COM-like approaches didn't work out. My recommendation would be: write your code in a language that suffers less from these problems, Python and Java are my preference, and add C/C++ code to those when needed for efficiency or system calls.
Translating that into a UNIX environment is a bit harder, but it might be worth having another go at at it, perhaps based on XML and web infrastructure.
You can compensate for many problems with microphones and acoustics using signal processing. It's kind of like modems can compensate for many problems with telephone lines and still give you very high data rates. Cheap sensors with smart processing is the future of audio and video.
Also, many stores now have the annoying habit of listing their prices with rebates included. If I get to the checkout and the rebate doesn't apply or looks like too much hassle, I don't buy the item and just leave it with the cashier.
I think many people in the US live in a state of denial in this area. There are lots of rights guaranteed on paper or assumed to exist, but in reality, when it comes to privacy, freedoms, and protection from unreasonable government actions, the situation is considerably worse than in many other countries. Many policy decisions in the US seem to be hidden behind code words, and informed public debate seems to rarely takes place.
I think it would be unfortunate if Germany adopted this proposed policy (and that's all it is for now). But at least there is an open debate about it and the cards are on the table. I think if it were to be implemented, it would likely come along with other legal provisions that protect consumers. For example, one thing to put on the table for the purpose of negotiations might be a requirement for publishers to publish their content in formats that allow copying. That could be a reasonable tradeoff, giving publishers a bit more confidence that they can effectively shut down pirate sites, in return for publishing stuff in a way that doesn't lock it up in perpetuity.
C is a "good language for doing systems work" if safety, security, and correctness are not very high priorities and if your programs are reasonably small. That was true of the original UNIX system. It isn't true of something like SSH or other network services (security is of paramount importance) and it isn't true either of huge GUI applications (too many potential sources of errors to ever get something really reliable).
(In theory, C++ could be a little better, but in practice, the way C++ is actually used, the same comments apply to C++.)
In C, it's very hard to get this right: just about every statement can lead to these kinds of problems: unchecked overflows, unchecked pointer dereferences, etc. People simply cannot handle that complexity and also get the code to work right. There are doubtlessly lots and lots of other problems like this in ssh, as well as most other Linux, UNIX, and Windows programs. (C++ lets you do a little better in principle, but the way most people use it, it's just as bad.)
If you want to write code that doesn't suffer from these problems without spending many times as much time on trying to find such silly bugs compared to expressing the actual algorithm, use a language that has some built-in error checking. Java, Modula-2, Modula-3, Ada, Oberon, whatever.
Clunky? Inconvenient? Not as many libraries available in those languages? All true. But that's because they aren't used enough, not because there is anything inherently wrong with them.
If you have battery backup for the solid state cache and if it's reasonably large, then you get pretty much the same effect as if you had a disk consisting of all RAM. Sun used to sell something like that for speeding up NFS called "PrestoServe".
Of course, Linux already has non-battery-backed-up RAM caches built in. The interesting thing is that even if the kernel crashes, you can usually recover the unwritten data from RAM and (after verifying something like a checksum) write it out to disk (this fails, of course, on platforms where the BIOS messes around with memory before the OS boots).
So, the best thing to do is probably to have battery backup for your RAM and processor and use an operating system that recovers information from RAM after a crash. That way, you can use normal RAM for caching, and if your machine crashes, you can recover quickly and with no or minimal loss of data.
I'd be willing to pay, say, $30/month for such a service. That would be a little more expensive than dial-up, but it would be a convenience around the house and to take to a cafe or park.
At issue is the clunky way in which most current GUIs, including the Macintosh and Window burden the user with concepts like "files" and "applications".
As a criticism of OS X, Raskin is right, and what he says applies equally to Windows, Gnome, and KDE. But Apple didn't have a choice: they were trapped in their own legacy. That was a problem Raskin himself could have helped avoid in the 1980s.
Meanwhile, devices and services like Apple's own Newton, Palm Pilots, broadband phones, web-based applications, and game consoles are already redefining what "operating system" and "application" mean.
Then came along Apple with their underpowered Macintosh programmed in assembly language and Pascal. They produced something that looked nice, but its model of applications and data was not much different from your average DOS machine. And that metaphor has held the desktop in a tight grip ever since and been copied over and over again, by Windows and now Gnome and KDE.
I think what Raskin is complaining about is ultimately due to Apple and their initial success with what was already then a broken paradigm. It seems like adding insult to injury for an Apple employee to come back now, 15 years later, and say that everybody is doing things wrong. Well, of course we are doing things wrong. That's because the market and users expect things to be done "wrong". Undoing the damage now will be much harder because everybody now expects things to be done that way.
You can get a similar look with the Sawfish "nanoGUI" theme.
It's hard to see how uwm could be considered "ugly" since it largely just left your windows alone. In fact, I think "twm" looked worse, but it ended up being more usable for new X11 users because they could just grab title bars, without using any keys.
There is nothing wrong with Linux. There is plenty wrong with companies that think they can build huge business empires on repackaged free software. Packaging distributions will at best be a small margin business. Actually, it will probably turn into a loss leader for other services. With better package systems and Internet upgrade support, "distributions" themselves may become an anachronism.
SuSE, of course, seems to be trying particularly hard to turn Linux into something commercial. The demo disks I have gotten from them have not been all that useful, and unlike many other vendors, they do not seem to provide ISO images of their distribution on-line.
Let's hope that all this greed from VCs and business people won't end up giving Linux and free software a bad name. Those people placed poor bets, and they only have themselves to blame.
If you buy commercial software, you pay a lot more for each release than the incremental enhancements that actually occurred. You do this because it would be too costly to switch. To add insult to injury, many of the enhancements in commercial software come from the customers in the first place.
You can get the first kind of experience by working really hard. But to have first hand experience of how a software system you built evolves over ten years in the real world, you have to be there for ten years.
There are other kinds of experience that are difficult to accomplish simply through effort alone. The long-term coming and going of corporate strategies, new languages, platforms, etc. is hard to understand even if you were to become a computer historian.
Sometimes that kind of long-term experience doesn't help, sometimes it even gets in the way, and sometimes, it's vitally important. I suspect that when people don't listen to you, it's in areas where they consider that kind of experience important.
Which leaves me wondering: why is this being dredged up now? Is the administration preparing for another assault on cryptography?