It does in fact work with Linux, It's just not officially documented or supported. Mac users are in the same boat for now, if not worse off--anyone know whether ethernet-over-USB is supported in Darwin/OSX?
I'm typing this post on my 802.11b-equipped Zaurus btw... The keyboard isn't so bad--easily 2x faster than Graffiti.
Fair enough... You'll end up with something analogous to return receipts, where a sender who runs her own IMTP server will know when any particular recipient has elected to download the message.
Many people would use their ISP's mail server though, in which case only their ISP would be able to find out whether recipients had downloaded mail. Or, server software could simply neglect to log the retrieval requests.
As with any alternative to a mainstream system, there are tradeoffs...
Part of what makes RF radio stations economical--and even occasionally profitable--is that the marginal cost of providing the broadcast service to an additional listener is essentially nil, modulo geographic saturation and transmitter power.
Today's streaming media services, however, incur a high marginal cost per additional listener--cost scales linearly with the number of listeners. There have been several attempts (Akamai, RBN) to get listeners to use a "nearby" transmitter, but these only flatten the cost-per-additional-listener line a bit by saving money close to the originating transmitter.
The Internet evolved a more bandwidth- and cost-efficient distribution model years ago in the form of multicast, but it was never widely implemented in enough of the places where it would have made a difference--backbones, routers, terminal servers, DSLAMs, cable companies, etc.
The idea is that a multicast packet stream should have a very small bandwidth footprint for the most expensive parts of the trip from transmitter to the receivers, only needing to be duplicated at the last few legs of the trip, where receivers aren't on the same physical network.
IOW, no matter how many of an ISP's customers are listening to a multicast stream, the ISP only has to transfer the packets from the expensive Internet once, and then make sure they get routed down the cheaper links to those customers who are listening.
Now that NAT is becoming more and more widespread, the situation doesn't look good--but hopefully IPv6 will kill NAT, and improve the multicast situation by opening up a vastly larger range of multicast addresses, and therefore a larger maximum number of simultaneous multicast connections.
There is another solution... Invert the Internet mail infrastructure so that email is hosted centrally by senders, and they pay all the inbound bandwidth charges incurred when (if) recipients retrieve the mail.
Dan Bernstein's IM2000 idea is a step in that direction. If everyone used IM2000, normal users would "pay" about the same amount for their outgoing email (unless they were in the habit of spamming their friends with the joke of the week), but spammers would "pay" much more as the flood of retrieval requests came in.
Legitimate bulk mailers would be paying for a more realistic share of the costs of Internet mail infrastructure. ISPs would save money because on the whole, normal users receive more mail than they send.
No, "A mixin is a type that a class can implement in addition to its "primary type" to declare that it provides some optional behaviour." [Bloch01]
In a language like Java that has interfaces and lacks multiple inheritance, mixins can be implemented using delegation, or they can be implemented "in-place".
For example, any object that you want to sort by must be Comparable. If you implement a Colour class and you want to be able maintain a SortedSet of them in "rainbow" order, you could either implement a ColourComparer class and delegate the equals() and compareTo() methods to it, or implement them in the Colour class. In either case, the Colour class's implementation of Comparable constitutes a mixin.
It depends on what you mean by "an object that needs to be treated as two entirely separate objects".
The use of multiple types allows the same object to be used in multiple contexts. Using interfaces (or classes containing only pure virtual functions in C++) instead of MI means that you can export multiple APIs without allowing clients knowledge of any particular implementations of the types specified by those APIs. You don't end up with increased binding to the messy innards of the Mammal or Earthling classes, you just have multiple roles that you can implement however you want, whether through a simple, across-the-board delegation or more selectively.
It's good pratice to be as general as possible when declaring member and parameter types--for instance, if your method only requires functionality that can be provided by any Map implementation, don't ask for a HashMap in your parameter list, as you could be constrained in future by your choice. Similarly, member variables should be declared using the most abstract type (interfaces are more abstract than classes) that will provide the functionality you need.
This can help make your multiple-interfaced class even more flexible, since you'll know at compile time if you're relying on the more-specific API of any particular concrete implementation of the interfaces you export.
Also, when you use delegation and composition rather than MI, you can change behaviour at runtime by using a different concrete implementation!
As regards "one should treat an interface as a generic object that implements these functions verses an object that actually is this thing", an interface is not a generic object, it's a contract indicating that a particular implementation supports some particular (set of) behaviour(s). When you implement an interface, you're promising to implement that behaviour. When you use a reference to an interface, you're treating that reference as a black box which could contain any one of a number of functionally-equivalent implementations.
A more concrete version of your example, in Java:
interface Mammal {
void suckle();
}
interface PlanetDweller {
double getWeight();// in Newtons
}
void moveToMars() {
_planetDweller = new Martian();
}
void moveToEarth() {
_planetDweller = new Earthling();
}
// Sorry about the mixed metaphor...
void moveToOrbit() {
_planetDweller = new Spaceling();
}
}
As with all contrived but off-the-cuff examples, this one doesn't make as much sense as one would like, but it illustrates an elegant way for an object to have multiple types without needing MI.
Wow, and ad hominem attack, an appeal to authority and a threat, all in one post! What a refreshingly rare thing to find on Slashdot!
I did quite clearly include the universally-understood letters "IMO" in my post, indicating that what followed should have been interpreted as a statement of opinion rather than fact.
It is an unquestionable fact that multiple inheritance works, inasmuch as software that uses it can be made to successfully compile and run. My opinion, however, is that MI should be avoided, chiefly because it can lead to needless complexity and subtle bugs.
Obviously, every tool affords some functionality that is easy to make use of, and some that works but is not optimal for a variety of reasons. In these cases, you're often better off using a different tool.
You don't need multiple inheritance--IMO it is a fundamentally unworkable concept. See the "diamond problem."
In a singly-inherited language like Java, you get much more flexibility by simulating "mixin-style" multiple inheritance by using multiple interfaces and delegation.
This example stolen from Joshua Bloch's excellent book Effective Java:
public interface Singer {
AudioClip sing( Song s );
}
public interface Songwriter {
Song compose( boolean hit );
}
// My own addition
public class Debutante implements SingerSongwriter {
private Singer _singer = new ConcreteSingerImpl();
private Songwriter _songwriter = new ConcreteSongwriterImpl();
public AudioClip sing( Song s ) {
return _singer.sing(s);
}
public Song compose( boolean hit ) {
return _songwriter.compose(hit);
}
public void actSensitive() { }
public AudioClip strum() { }
}
I liked Eclipse for the most part... It had some of the good features of VisualAge but was less annoying and didn't hide all your code in a repository database.
However, there's a feature of the Java and/or JDE modes in XEmacs that I've become unable to live without:
When you hit Tab, it doesn't necessarily insert some fixed number of spaces or tabs. It simply indents the current line properly. You know immediately that you're missing a bracket or a semicolon when you hit Tab and:
Nothing happens, or;
The line gets indented bizarrely.
It would probably only take me a few days to adapt to a new editor, but why would I bother?:)
By "differential survival" I mean the direct causal effect of the process of natural selection upon organisms, i.e. the death, before the production of viable offspring, of less-well-adapted or just plain unlucky individuals.:)
It was your comment that "Evolution cares about maximizing survival of the species" I was responding to--my point being that it's not species which are the principally subject to natural selection, it's genes.
Species are more of a population genetics phenomenon--think of how fuzzy the boundaries between two closely-related, recently-divergent subspecies can be over even a human historical timescale. Darwin's Dangerous Idea by Daniel C. Dennett contains a very elegant treatment of the very interesting question of speciation.
When you say "any species that don't have survival as a goal don't last very long, by definition" you're obscuring the reality that it's the genes that code for particular adaptations, spread throughout a population, which are responsible for the survival of a species.
Species, in and of themselves, can only be considered to have adaptations and behaviour because of the genes that enable the species' constituent organisms to replicate successfully.
I think it's obvious we don't disagree on the mechanism or historical fact of evolution, it's just a semantic quibble.:)
That's the trick--anyone who thinks that anything but differential replication of genes accounts for the observed fact of evolution by natural selection is more than welcome to try to come up with a mechanism capable of explaining the same results.
But no such mechanism has yet been found that can survive an encounter with Occam's Razor.:)
Stephen Pinker wrote quite eloquently about this question in his book How the Mind Works.
In the simplest cases, individuals benefit from expending resources to enhance the survival of their family members because they share genes in common.
Parents evolve to work to ensure the survival of their children because each parent shares 50% of her genes with each of her children (and 25% with each of her grandchildren).
Likewise, it's in the evolutionary interest of siblings to cooperate--even at significant personal cost--because on average, half of their genes are common.
Non-kin altruism, in which individuals help others with whom they have relatively few genes in common, has been attributed to a wide range of factors, including the expectation of reciprocal altruism, adaptations for living in large groups consisting mainly of non-genetically-related others, etc.
Evolution has nothing to do with the differential survival of species, and everything to do with that of genes (individual organisms and close relatives, by extension).
Recall "suicidal" lemmings. Early biologists believed that lemmings (a) practice mass suicide and (b) that this trait is an adaptation benefiting the group. They reasoned that if the lemming population exceeds the carrying capacity of the local environment (if they exhaust food supplies) that the group will become extinct. To prevent group extinction, lemmings kill themselves. The gene for mass suicide is an adaptation benefiting the group to the disadvantage of the individual.
This explanation has several problems. First, lemmings don't kill themselves. They migrate to new areas. They are excellent swimmers. By swimming across fjords in groups, an individual lemming is less likely to be swallowed by predators (safety in numbers).
Second, a gene for suicide will not persist. Vehicles (lemmings) with the suicide gene do not reproduce?they kill themselves. In a population of lemmings with suicide genes, consider that a non-suicidal mutation would be very successful. If some lemmings refrain from killing themselves, they would be reproduce more than suicidal individuals and nonsuicidal genes would quickly predominate.
Richard Dawkins has written about this common misconception at length.
Allen Holub, OO luminary and gadfly, included an interesting geek's-eye-view of the proper place of marketing and sales in this article at IBM DevWorks. A short paraphrase:
The job of Marketing is to determine the minimum feature set required for a product to succeed in the marketplace at a given price.
The job of Sales is to sell the stuff that marketing has specified and Development has built. Sales should not be asking Development for features when some customer wants them--they need to talk to Marketing first.
Actually, it's more likely that autism (remember, "aut" = "self") is, at least in part, an inability on the part of the affected person to infer the existence of a mind in others.
While they may be conscious of more details of the world, that in itself is not causing problems--they just don't realize that other people are actually people "just like me" who can be communicated with, etc.
Even if I weren't already a fan of wilwheaton.net I would still consider this interview to be one of the best I remember. Wil is a fabulous guy (even if he hasn't answered my email) and it's great to have him in our community.
Actually, Wreck Beach (warning: crappy site, some very low-res nudity) is a nude beach, not (just) topless.
A few years ago the Powers That Be wanted to build an "emergency access" road down to the beach, but the proposal was shelved after vociferous public protest.
As it stands, you can get there either by walking at low tide along the beach from Spanish Banks, or down the cliff via many many steps.
For some reason you seem to have confused Sri Lanka (formerly known as Ceylon) with Cypress, the large island whose ownership is disputed between Greece and Turkey.
I think the out-of-phase coloured bits may have been caused by movement of the subjects. IIRC from reading the article, the three separations were taken *almost* simultaneously.
Not really, with typical smp boxes, if a cpu goes bad then your entire machine crashes.
Actually, they're not SMP at all. Crusoe doesn't support SMP. Each "blade" has one CPU, and is a completely independent server.
I don't think the server in question has that capability
Not in and of itself; they're all separate servers. But you could easily dedicate one or more of the "blades" to a load-balancing and/or failover role.
Slashdot Mirror
It does in fact work with Linux, It's just not officially documented or supported. Mac users are in the same boat for now, if not worse off--anyone know whether ethernet-over-USB is supported in Darwin/OSX?
I'm typing this post on my 802.11b-equipped Zaurus btw... The keyboard isn't so bad--easily 2x faster than Graffiti.
Fair enough... You'll end up with something analogous to return receipts, where a sender who runs her own IMTP server will know when any particular recipient has elected to download the message.
Many people would use their ISP's mail server though, in which case only their ISP would be able to find out whether recipients had downloaded mail. Or, server software could simply neglect to log the retrieval requests.
As with any alternative to a mainstream system, there are tradeoffs...
Part of what makes RF radio stations economical--and even occasionally profitable--is that the marginal cost of providing the broadcast service to an additional listener is essentially nil, modulo geographic saturation and transmitter power.
Today's streaming media services, however, incur a high marginal cost per additional listener--cost scales linearly with the number of listeners. There have been several attempts (Akamai, RBN) to get listeners to use a "nearby" transmitter, but these only flatten the cost-per-additional-listener line a bit by saving money close to the originating transmitter.
The Internet evolved a more bandwidth- and cost-efficient distribution model years ago in the form of multicast, but it was never widely implemented in enough of the places where it would have made a difference--backbones, routers, terminal servers, DSLAMs, cable companies, etc.
The idea is that a multicast packet stream should have a very small bandwidth footprint for the most expensive parts of the trip from transmitter to the receivers, only needing to be duplicated at the last few legs of the trip, where receivers aren't on the same physical network.
IOW, no matter how many of an ISP's customers are listening to a multicast stream, the ISP only has to transfer the packets from the expensive Internet once, and then make sure they get routed down the cheaper links to those customers who are listening.
Now that NAT is becoming more and more widespread, the situation doesn't look good--but hopefully IPv6 will kill NAT, and improve the multicast situation by opening up a vastly larger range of multicast addresses, and therefore a larger maximum number of simultaneous multicast connections.
Some fun links:
An Introduction to IP Multicast Routing (from Google cache, the site seems to be down)
Some stuff from Cisco
RFC2375: IPv6 Multicast Address Assignments
IPv6 Multicast Standards
There is another solution... Invert the Internet mail infrastructure so that email is hosted centrally by senders, and they pay all the inbound bandwidth charges incurred when (if) recipients retrieve the mail.
Dan Bernstein's IM2000 idea is a step in that direction. If everyone used IM2000, normal users would "pay" about the same amount for their outgoing email (unless they were in the habit of spamming their friends with the joke of the week), but spammers would "pay" much more as the flood of retrieval requests came in.
Legitimate bulk mailers would be paying for a more realistic share of the costs of Internet mail infrastructure. ISPs would save money because on the whole, normal users receive more mail than they send.
I've been thinking of implementing it...
rancid mystery loaves
steady micron slavery
comedy striven salary
trendy mosaic slavery
convert already missy
scary devil monastery
misty adversary clone
mail covers dysentary
discover anal mystery
(alt.sysadmin.recovery)
Official acronym list from the ASR FAQ
No, "A mixin is a type that a class can implement in addition to its "primary type" to declare that it provides some optional behaviour." [Bloch01]
In a language like Java that has interfaces and lacks multiple inheritance, mixins can be implemented using delegation, or they can be implemented "in-place".
For example, any object that you want to sort by must be Comparable . If you implement a Colour class and you want to be able maintain a SortedSet of them in "rainbow" order, you could either implement a ColourComparer class and delegate the equals() and compareTo() methods to it, or implement them in the Colour class. In either case, the Colour class's implementation of Comparable constitutes a mixin.
It depends on what you mean by "an object that needs to be treated as two entirely separate objects".
// in Newtons
// Sorry about the mixed metaphor...
The use of multiple types allows the same object to be used in multiple contexts. Using interfaces (or classes containing only pure virtual functions in C++) instead of MI means that you can export multiple APIs without allowing clients knowledge of any particular implementations of the types specified by those APIs. You don't end up with increased binding to the messy innards of the Mammal or Earthling classes, you just have multiple roles that you can implement however you want, whether through a simple, across-the-board delegation or more selectively.
It's good pratice to be as general as possible when declaring member and parameter types--for instance, if your method only requires functionality that can be provided by any Map implementation, don't ask for a HashMap in your parameter list, as you could be constrained in future by your choice. Similarly, member variables should be declared using the most abstract type (interfaces are more abstract than classes) that will provide the functionality you need.
This can help make your multiple-interfaced class even more flexible, since you'll know at compile time if you're relying on the more-specific API of any particular concrete implementation of the interfaces you export.
Also, when you use delegation and composition rather than MI, you can change behaviour at runtime by using a different concrete implementation!
As regards "one should treat an interface as a generic object that implements these functions verses an object that actually is this thing", an interface is not a generic object, it's a contract indicating that a particular implementation supports some particular (set of) behaviour(s). When you implement an interface, you're promising to implement that behaviour. When you use a reference to an interface, you're treating that reference as a black box which could contain any one of a number of functionally-equivalent implementations.
A more concrete version of your example, in Java:
interface Mammal {
void suckle();
}
interface PlanetDweller {
double getWeight();
}
class Martian implements PlanetDweller {
double _mass;
double getWeight() {
return _mass * 3.724d;
}
}
class Earthling implements PlanetDweller {
double _mass;
double getWeight() {
return _mass * 9.8d;
}
}
class Spaceling implements PlanetDweller {
double getWeight() {
return 0.0d;
}
}
abstract class AbstractHuman implements Mammal, PlanetDweller {
PlanetDweller _planetDweller = new Earthling();
void suckle() { }
double getWeight() {
return _planetDweller.getWeight();
}
void moveToMars() {
_planetDweller = new Martian();
}
void moveToEarth() {
_planetDweller = new Earthling();
}
void moveToOrbit() {
_planetDweller = new Spaceling();
}
}
As with all contrived but off-the-cuff examples, this one doesn't make as much sense as one would like, but it illustrates an elegant way for an object to have multiple types without needing MI.
Wow, and ad hominem attack, an appeal to authority and a threat, all in one post! What a refreshingly rare thing to find on Slashdot!
I did quite clearly include the universally-understood letters "IMO" in my post, indicating that what followed should have been interpreted as a statement of opinion rather than fact.
It is an unquestionable fact that multiple inheritance works, inasmuch as software that uses it can be made to successfully compile and run. My opinion, however, is that MI should be avoided, chiefly because it can lead to needless complexity and subtle bugs.
Obviously, every tool affords some functionality that is easy to make use of, and some that works but is not optimal for a variety of reasons. In these cases, you're often better off using a different tool.
You don't need multiple inheritance--IMO it is a fundamentally unworkable concept. See the "diamond problem."
In a singly-inherited language like Java, you get much more flexibility by simulating "mixin-style" multiple inheritance by using multiple interfaces and delegation.
This example stolen from Joshua Bloch's excellent book Effective Java:
public interface Singer {
AudioClip sing( Song s );
}
public interface Songwriter {
Song compose( boolean hit );
}
public interface SingerSongwriter extends Singer, Songwriter {
AudioClip strum();
void actSensitive();
}
// My own addition
public class Debutante implements SingerSongwriter {
private Singer _singer = new ConcreteSingerImpl();
private Songwriter _songwriter = new ConcreteSongwriterImpl();
public AudioClip sing( Song s ) {
return _singer.sing(s);
}
public Song compose( boolean hit ) {
return _songwriter.compose(hit);
}
public void actSensitive() { }
public AudioClip strum() { }
}
Wow, I guess that's why it's NOT RELEASED YET.
All the same, I think it's great that the attempt is being made, and I hope they pull it off and make millions.
Auto-indentation would be a nice hack indeed... Maybe I'll push it onto my pet projects stack. *sigh*
However, there's a feature of the Java and/or JDE modes in XEmacs that I've become unable to live without:
When you hit Tab, it doesn't necessarily insert some fixed number of spaces or tabs. It simply indents the current line properly. You know immediately that you're missing a bracket or a semicolon when you hit Tab and:
It would probably only take me a few days to adapt to a new editor, but why would I bother? :)
By "differential survival" I mean the direct causal effect of the process of natural selection upon organisms, i.e. the death, before the production of viable offspring, of less-well-adapted or just plain unlucky individuals. :)
:)
It was your comment that "Evolution cares about maximizing survival of the species" I was responding to--my point being that it's not species which are the principally subject to natural selection, it's genes.
Species are more of a population genetics phenomenon--think of how fuzzy the boundaries between two closely-related, recently-divergent subspecies can be over even a human historical timescale. Darwin's Dangerous Idea by Daniel C. Dennett contains a very elegant treatment of the very interesting question of speciation.
When you say "any species that don't have survival as a goal don't last very long, by definition" you're obscuring the reality that it's the genes that code for particular adaptations, spread throughout a population, which are responsible for the survival of a species.
Species, in and of themselves, can only be considered to have adaptations and behaviour because of the genes that enable the species' constituent organisms to replicate successfully.
I think it's obvious we don't disagree on the mechanism or historical fact of evolution, it's just a semantic quibble.
That's the trick--anyone who thinks that anything but differential replication of genes accounts for the observed fact of evolution by natural selection is more than welcome to try to come up with a mechanism capable of explaining the same results.
:)
But no such mechanism has yet been found that can survive an encounter with Occam's Razor.
In the simplest cases, individuals benefit from expending resources to enhance the survival of their family members because they share genes in common.
Parents evolve to work to ensure the survival of their children because each parent shares 50% of her genes with each of her children (and 25% with each of her grandchildren).
Likewise, it's in the evolutionary interest of siblings to cooperate--even at significant personal cost--because on average, half of their genes are common.
Non-kin altruism, in which individuals help others with whom they have relatively few genes in common, has been attributed to a wide range of factors, including the expectation of reciprocal altruism, adaptations for living in large groups consisting mainly of non-genetically-related others, etc.
Here's a nice quote on the subject from something I just Googled up:
Richard Dawkins has written about this common misconception at length.The job of Marketing is to determine the minimum feature set required for a product to succeed in the marketplace at a given price.
The job of Sales is to sell the stuff that marketing has specified and Development has built. Sales should not be asking Development for features when some customer wants them--they need to talk to Marketing first.
While they may be conscious of more details of the world, that in itself is not causing problems--they just don't realize that other people are actually people "just like me" who can be communicated with, etc.
See this bit on the so-called Theory of Mind.
This DDJ article tells you how Intel started implementing 36-bit memory addressing way back in P5 (Pentium) days.
Actually, 2^64 bytes is 1.84467E+19 bytes, or approx. 18.4 exabytes
Even if I weren't already a fan of wilwheaton.net I would still consider this interview to be one of the best I remember. Wil is a fabulous guy (even if he hasn't answered my email) and it's great to have him in our community.
A few years ago the Powers That Be wanted to build an "emergency access" road down to the beach, but the proposal was shelved after vociferous public protest.
As it stands, you can get there either by walking at low tide along the beach from Spanish Banks, or down the cliff via many many steps.
For some reason you seem to have confused Sri Lanka (formerly known as Ceylon) with Cypress, the large island whose ownership is disputed between Greece and Turkey.
I think the out-of-phase coloured bits may have been caused by movement of the subjects. IIRC from reading the article, the three separations were taken *almost* simultaneously.
Actually, they're not SMP at all. Crusoe doesn't support SMP. Each "blade" has one CPU, and is a completely independent server.
Not in and of itself; they're all separate servers. But you could easily dedicate one or more of the "blades" to a load-balancing and/or failover role.