Re:Styx / 9P is so much better, and simpler
on
Perl and .NET
·
· Score: 2
I can see where this would have it's uses. For the majority of my stuff, XML-RPC is best because I need to format it to XML anyways, so the RPC pretty much just passes through an XSLT based on the accept mime-types of the caller. That being said, there are definately circumstances that streaming would be preferable.
I'm not too sure about the "mounting" metaphor. It seems like an extra bit of complexity if it is necessary (i.e. there's no automount for rare RPCs). I can understand why it would be needed for highly used RPCs, just for the efficiency of it. There may also be connection pooling aspects to consider. But I don't know if I agree with keeping the memory overhead of that many mounts.
Anyways, cool stuff. I'll have to look into it more.
Inefficienct but useable and can do more
on
Perl and .NET
·
· Score: 5
I'll agree that XML-RPC is inefficient compared to CORBA, but you would be surprised at how useable it is. A long time ago I decided that I wouldn't shun a technology because it was billed as slow until benchmarks show it really is too slow for what I am using it for. I used XML-RPC in enterprise medical systems, and it was never shown to be an important bottleneck.
Plus, you can do so much more with it. The area I found it to excel the greatest in was in security. When you are bulding the XML response, you can be choosy as to what fields you include beased on the user in the session. Contrast this to passing an object by value. It becomes an all or nothing prospect.
Then there is the small bonus that testing your client involves writing a static XML file served to it when it makes the call. It makes automated tests a lot easier. This is a good thing for an XPer, like myself.
Another thing is that is does greatly simplify a design. You don't have to force everything into terms of object models. You just think of it as formatted data, formatted however is logical for the call. This really is a great, and better experienced than explained.
One final note (although there are other good things about XML-RPC), if you are making a web applications, using XML-RPC to distribute the system, gives a homogeny to the model. This is a good thing, because it also makes the overall metaphor for the architecture easier to understand.
It is important to note that XML-RPC is not intrinsic to.NET. The systems I've worked on with it have all been J2EE systems. I just finished a JSP taglib, that, among other things, allows you to select blocks of JSP to include based on the Accept tag. It also does XML/XSLT with xalan. With this, you can use the same application logic for HTML, WML, and XML agents. You can use XMl-RPC to call into.NET (I've done this calling into ASPs before.NET) and.NET can call into J2EE systems. And Sun is a large SOAP supporter.
C++ does not hide your data very well, but at least it gives you an easy way to separate the interface of a class from its implementation -.cpp and.h. With Java, you can often do so only by subclassing.
This is an often visited rift in "the way C/C++ does things" vs "the way Java does things". Java does do this. It's with a tool called Javadoc that pulls the interface of your classes and puts them into HTML files for browsing. This is no worse than how C++ does it, and is arguably better. Those that are looking at the interface cannot even be tempted to change it.
Java is NOT bad and it's debugging is extremely
more Verbose that most C++ compilers I have had
the unfortunate time to use
Debugging facility is VM-specific for Java. Java VM does not guarantee anything except maybe reliably running your code. That of C++ aren't bad either. For example, there are lots of good C++ ASSERT libraries out there, and they can be very useful in good hands.
Actually, there are many parts of the Java specification that deal with what is required in the dubugging information within Java classes. More importantly, the API spec defines that "printStackTrace()" will print the call stack of an exception from wherever it was thrown. The fact of the matter is that I can debug Java no problem without a debugger. I can't do that with C++ (and I have more years experience with C++).
If true OO design philosophies are held so
highly by all of the geniuses on Slashdot why
do programmers for Linux make EVERYHING in C and
then try to fool themselves and their programs into thinking they are actually OO when they are
not?
OO is a *language-independent concept*. You can implement a program using the OO philosophies in C. Please do some research before you post.
To be object oriented, you must have the 3 concepts of encapsulation, polymorphism, and inheritance. You cannot have encapsulation in C, as there is no private data. That alone makes C a non-object oriented language.
Yes you can use function pointers, yes ou can do abstraction (a procedural concept, actually, though often atrribed to OO). But to say C supports inheritance is too much of a strech. It is more accurate to say that C programmers support it. Polymorphism is part of C, but it has limited use.
Finally, the original poster is right. People do look at a program and go "well this is all abstracted and uses OO philosphy so it's OO". Well it ain't. Because in C I can take your struct and route through its insides. Just because you don't doesn't make you OO. It's the fact you can't.
As a multiple inherenance enthusiast, I have to emplor you to not use C++'s broken implementation of MI dirty what is a good OO mechanism. The heart of the problem with C++'s MI is that is allows for ambiguity. It is possible to have MI with no ambiguity.
Give the graphical cowboy example, this is illustrated with the following code: // Draw a cowboy with his gun drawnGraphicalCowboy gc;gc.Cowboy::draw();gc.Graphic::draw();
The problem with C++ MI stems from the language designer's confusing the concept of a method signature and a method contract. A method signature is a short hand for the contract, since it would be futile to write out the contract each time you wanted to invoke the method. So instead of saying "draw your gun" you just say "draw()".
But it is possible to maintain the connection between contract and signature as long as the signature is kept within the context where they are defined. Thus, even though Graphic and Cowboy both have the same signatured method "draw()", they are contractually different and this is reflected by quialifying the class that originally defined it.
Similarily, a class should be able to make a new method with the same signature as a subclass without overriding the base class and have both contracts callable by addressing the right signature.
Now, for thos of you who are all "We can do everything with interfaces," the fact of the matter is that if you are using a 3rd party API that is not designed with interfaces in mind, then you will have to resort to aggregation and delegation. To those of you who say "that's not that bad", you're right, but inheritance is only aggregation and delegation and if you ask "what's the point when you can do MI that way," you have to ask "what's the point of having inheritance at all." It's syntax that helps the design. And honestly, interfaces can often muddle the design.
You can even have multiple instances of the same class loaded in Java. Thus, a "static" method isn't really that "static", but static to the instance of the class. If you load the class twice with a noncaching classloader, you can modify one static variable's values, and they won't effect the same static variable in the other class instance.
In this respect, there is no difference between Java's classes as objects and Smalltalks.
I was thinking yesterday, while watching TV, "why is it that TV commercials are more effective at getting me to buy things than Web adverts." The fact of the matter is that I will see a commercial and will often decide I will buy the product/go to the restaurant/etc/
The miggest thing I could see is that I enjoy TV commercials. Many of them are at the least cute, if not downright funny. I've even paid to see commercials, by going to the World's Greatest Commercials showings at the movie theater.
Even if they aren't funny, then they are pleasurable to watch. Most restaurant commercials have my eyes glued to their great looking food. Gap commercials have fun exciting people doing fun and exciting things. In short, TV commercials fit into their medium because TV is meant to entertain and TV commercials entertain.
Contrast this to Web ads. I find it rare that I even notice an ad on a web page. Market researchs have also found this for average web surfers. But there isn't enough bandwidth to make an ad as entertaining as a TV ad. So, a very large number of ads have tried to do the "flashy catch-you eye" thing which isn't entertaining, it's annoying. When you do look, you feel gypped and you move on, forgetting the whole thing a few seconds later.
And that is the best case on a website that is meant to be entertaining. Remember that I said TV ads fit their medium. The web allows for more than entertainment. You can have informational resources as well (I don't feel that TV allows this, because TV can never cover the right amount of information. What you get is infotainment or entertainment news). A web ad also cannot project enough information about a product within the limitations of the ad.
What I envision more and more is a rise of full articles that are actually ads, like those in magazines. Ads will try to blend in more with content, because content is what we look for on the web. But the ads can be out of place. You can't have a paragraph talking about an Isuzu Trooper in the middle of the Onion. Editors won't want theri reader to get the gypped feeling because they may stop going to the website all together.
All and all, I think the most important thing to consider is that the Web is a new medium, and as such we are still learning how to advertise effectivly. I highly doubt popups are it. They will just annoy more people, and you don't want to annoy your ad viewers, you want them to want to see your ad.
Judging from the context that "Read aloud" is in, it probably means that you cannot instruct your ebook viewer to read it aloud using voice synth. Those aren't license agreements, they are permissions. You can't copy it, you can't print it. These are standard PDF permissions. The ebook reader probably has other funtions (or will in later releases) for lending, giving, and reading books aloud.
There's an recent article on Kuro5hin about fear of XHTML. The most relevent thing in it is how people will violently stick to what they know. They learned to use font tags instead of CSS, and so they like it that way. They fear that their pages will not work in the future, and they fear that they can't do the same things in XHTML as in HTML.
This is an example of how advocacy (in this case HTML over XHTML/CSS) is very bad for everyone involved. People do not want to leave HTML, so parsers will have to continue to be complex. Browser incomatibilities will widen even more.
I often see this kind of thing. A new standard comes out, and it solves more problems than before, but there is this inertia on the existing standard. It's almost as if people decide that they have learned enough for them to retire on.
<shudder> You just reminded me of a job I once had where they had a lot of FORTRAN programmers who were working on a large C system. What they had done was created a header file like so: #define BEGIN { #define END } #define IF if ( #define THEN ) { #define ELSIF } else if ( #define ELSE } else { #define ENDIF }
Every C file used this syntax instead of C's. I agree that syntax wars are the lowest form of language advocacy, but that was aweful. My feeling is if you are going to use C, use C. I also don't believe in abusing the preprocessor.
Not nearly as bad as one guy there who did the following though: #define TRUE 0 #define FALSE -1
Throughout his code, he used these values consistently. In IF (not if, IF, see above), statements he would always compare the boolean return to TRUE. After I inherited his code, I was adding some stuff and did a WHILE TRUE DO (yes, I had to use the macros, because they wanted their source to remain consistent) with a break condition. It took me quite a while to figure out why it wouldn't execute. At first I thought it was a bug in the compiler optimization.
Of course, this is just a guess, but if I had been writing the FAQ, I would have been afraid to say ``You don't need linked lists in Perl'' and leave it at that, because I would have imagined someone reading that answer and concluding that it was an evasion and that linked lists couldn't be done at all in Perl.
This part of the article reminded me of a similar problem with Java. When Java first came out, it was billed as "safe" and "has no pointers". This often lead people to ask in comp.lang.java "How do you make a linked list in Java"? Similar to perl, the right answer was to use a java.util.Vector (now the right answer is java.util.ArrayList), since it will provide most of what you need from a linked list.
But people took this to mean that you couldn't make a linked list in Java and instead had to use special built-in classes. In actuality, making a linked list in Java is easy: class LinkedList { Object value; LinkedList next; }
But people were willing to believe that this was a failure in Java, even though it A) wasn't a failure since you could do it anyways and B) had a standard and often better (O(1) lookup) way of doing things.
Yeah, but try finding enough class A programmers to do a large project. By class A, I mean, they can think for themselves, solve problems quickly by themselves, can understand other poeple code and integrate their code with others, and rigorously test the shit out of their code. I've interviewed a lot of people try to fill enough for projects. Most people suck so bad, when an o.k. person comes along, you're happy to hire.
"I mean, everything in Unix is ultimately based on command line interactions. You can try to overcome that, but it's very hard. Unix's whole philosophy on how to do internal management and how to manage timing is based on that set of assumptions, so you have to fight it at a thousand levels."
In a lot of ways this is true for all operating systems. In Windows, you can see the command line present when you are associating an action to a file extension. You will 9 times out of 10 be setting up a command line that launches a program on the file. The other 1 time out of 10, it will support DDE or something.
My feeling is that the command line is a programming language. Often it is handy to use that programming language in a GUI (for example when setting up associations). Because of this, it will always be hard to get entirely away from the command line. Especially when the command line is a large part of our programming languages (ANSI C and Java define main to take parameters from a "command line").
So I don't see how any one operating system has a more "command line feel" than another.
Then again, I've never tried to build a virtual reality interface on top of UNIX.
The point is that the play button is an icon. You press it, just like you would press an icon in a GUI. Even icons in GUIs are labeled. The difference is that the CD player isn't just a box with no labels or buttons that you have to remember the commands for.
I do prefer CLI, though, since I can remember many of the commands. Plus it's a lot easier to put in a document what commands to type rather than Which|Tab|To|Go To to check which box.
>The result was that punishment for horse theft was DEATH or worse.
The result of what? The penalty for horse theft was probably so high because a horse was *so* valuable in the old West.
No, the penalty was high because, like the original poster said, it was a deterent to a crime that could be easily gotten away with. It was for "rustling," not stealing a single horse. It was for rustling cattle, as well. The problem was that it was easy for people to come in at night and rustle animals. To prevent people from doing this, a high penalty was given. If it was just 6 months in jail, then it was be worth it to take the risk of rustling. If it's death, then the risk is often too high (but not always, apparently).
Density does effect gravity. This is because gravity is inversly proportional to the square of the distance between the two masses. While this relationship is difficult to model for a vastly large body, like th Earth, you can simplify it by thinking of the distance being to the center of the Earth. Mass closer will exhert more gravity, mass farth will exhert less, but it mostly works out. If you strech the mass of the Earth over 10000 times the volume (no where near the size of a nebula, BTW), you would get 1/(10000)^2/3 ~= 1/464 times the gravity (the cube root is because it is square to the distance, which is found by the cube root of the volume).
Of course, this isn't to say that density is the actual important factor. It is of course, Gravity. A 10000 times larger body with 464 times more mass would have the same gravity and could sustain an atmosphere like earths.
The problem is that someone is going to have to go through the legal fees of proving that there is prior art inorder to show that this patent is ludicrous.
I actually bought tickets to the Hootie concert just to see TMBG. I was very pissed off when they announced the last minute that instead 54'40 was playing instead and would not refund the tickets (since they were for Hootie and the Blowfish, not TMBG. The tickets didn't even say TMBG on them).
I did get to see them on the severe tire damage tour, though. They are a great show and I highly recommend going to anyone who is a fan.
To the moderator who moderated this offtopic: They Might Be Giants has a song, titled "Older" (note the title of this thread). The refrain of that song is "You're older than you've ever been, and now you're even older/Now you're even older/Now you're even older/You're older than you've ever been, and now you're even older/Now you're even older still". I fail to see how this is offtopic.
To all moderators: if you don't understand a comment, don't moderate it down. It may still actually mean something.
You can use a service like Surfola to get around these filters at work. Surfola gets the pages, relinks them to use their CGI, and then send them to you from their site. According to the SmartFilterWhere, there is no listing for it.
Slashdot Mirror
I can see where this would have it's uses. For the majority of my stuff, XML-RPC is best because I need to format it to XML anyways, so the RPC pretty much just passes through an XSLT based on the accept mime-types of the caller. That being said, there are definately circumstances that streaming would be preferable.
I'm not too sure about the "mounting" metaphor. It seems like an extra bit of complexity if it is necessary (i.e. there's no automount for rare RPCs). I can understand why it would be needed for highly used RPCs, just for the efficiency of it. There may also be connection pooling aspects to consider. But I don't know if I agree with keeping the memory overhead of that many mounts.
Anyways, cool stuff. I'll have to look into it more.
I'll agree that XML-RPC is inefficient compared to CORBA, but you would be surprised at how useable it is. A long time ago I decided that I wouldn't shun a technology because it was billed as slow until benchmarks show it really is too slow for what I am using it for. I used XML-RPC in enterprise medical systems, and it was never shown to be an important bottleneck.
Plus, you can do so much more with it. The area I found it to excel the greatest in was in security. When you are bulding the XML response, you can be choosy as to what fields you include beased on the user in the session. Contrast this to passing an object by value. It becomes an all or nothing prospect.
Then there is the small bonus that testing your client involves writing a static XML file served to it when it makes the call. It makes automated tests a lot easier. This is a good thing for an XPer, like myself.
Another thing is that is does greatly simplify a design. You don't have to force everything into terms of object models. You just think of it as formatted data, formatted however is logical for the call. This really is a great, and better experienced than explained.
One final note (although there are other good things about XML-RPC), if you are making a web applications, using XML-RPC to distribute the system, gives a homogeny to the model. This is a good thing, because it also makes the overall metaphor for the architecture easier to understand.
It is important to note that XML-RPC is not intrinsic to .NET. The systems I've worked on with it have all been J2EE systems. I just finished a JSP taglib, that, among other things, allows you to select blocks of JSP to include based on the Accept tag. It also does XML/XSLT with xalan. With this, you can use the same application logic for HTML, WML, and XML agents. You can use XMl-RPC to call into .NET (I've done this calling into ASPs before .NET) and .NET can call into J2EE systems. And Sun is a large SOAP supporter.
This is an often visited rift in "the way C/C++ does things" vs "the way Java does things". Java does do this. It's with a tool called Javadoc that pulls the interface of your classes and puts them into HTML files for browsing. This is no worse than how C++ does it, and is arguably better. Those that are looking at the interface cannot even be tempted to change it.
Actually, there are many parts of the Java specification that deal with what is required in the dubugging information within Java classes. More importantly, the API spec defines that "printStackTrace()" will print the call stack of an exception from wherever it was thrown. The fact of the matter is that I can debug Java no problem without a debugger. I can't do that with C++ (and I have more years experience with C++).
To be object oriented, you must have the 3 concepts of encapsulation, polymorphism, and inheritance. You cannot have encapsulation in C, as there is no private data. That alone makes C a non-object oriented language.
Yes you can use function pointers, yes ou can do abstraction (a procedural concept, actually, though often atrribed to OO). But to say C supports inheritance is too much of a strech. It is more accurate to say that C programmers support it. Polymorphism is part of C, but it has limited use.
Finally, the original poster is right. People do look at a program and go "well this is all abstracted and uses OO philosphy so it's OO". Well it ain't. Because in C I can take your struct and route through its insides. Just because you don't doesn't make you OO. It's the fact you can't.
As a multiple inherenance enthusiast, I have to emplor you to not use C++'s broken implementation of MI dirty what is a good OO mechanism. The heart of the problem with C++'s MI is that is allows for ambiguity. It is possible to have MI with no ambiguity.
Give the graphical cowboy example, this is illustrated with the following code:
// Draw a cowboy with his gun drawn
GraphicalCowboy gc;
gc.Cowboy::draw();
gc.Graphic::draw();
The problem with C++ MI stems from the language designer's confusing the concept of a method signature and a method contract. A method signature is a short hand for the contract, since it would be futile to write out the contract each time you wanted to invoke the method. So instead of saying "draw your gun" you just say "draw()".
But it is possible to maintain the connection between contract and signature as long as the signature is kept within the context where they are defined. Thus, even though Graphic and Cowboy both have the same signatured method "draw()", they are contractually different and this is reflected by quialifying the class that originally defined it.
Similarily, a class should be able to make a new method with the same signature as a subclass without overriding the base class and have both contracts callable by addressing the right signature.
Now, for thos of you who are all "We can do everything with interfaces," the fact of the matter is that if you are using a 3rd party API that is not designed with interfaces in mind, then you will have to resort to aggregation and delegation. To those of you who say "that's not that bad", you're right, but inheritance is only aggregation and delegation and if you ask "what's the point when you can do MI that way," you have to ask "what's the point of having inheritance at all." It's syntax that helps the design. And honestly, interfaces can often muddle the design.
You can even have multiple instances of the same class loaded in Java. Thus, a "static" method isn't really that "static", but static to the instance of the class. If you load the class twice with a noncaching classloader, you can modify one static variable's values, and they won't effect the same static variable in the other class instance.
In this respect, there is no difference between Java's classes as objects and Smalltalks.
The funny thing about that commercial is that he was enjoying he snickers so much, he voted for Bucchanan.
I was thinking yesterday, while watching TV, "why is it that TV commercials are more effective at getting me to buy things than Web adverts." The fact of the matter is that I will see a commercial and will often decide I will buy the product/go to the restaurant/etc/
The miggest thing I could see is that I enjoy TV commercials. Many of them are at the least cute, if not downright funny. I've even paid to see commercials, by going to the World's Greatest Commercials showings at the movie theater.
Even if they aren't funny, then they are pleasurable to watch. Most restaurant commercials have my eyes glued to their great looking food. Gap commercials have fun exciting people doing fun and exciting things. In short, TV commercials fit into their medium because TV is meant to entertain and TV commercials entertain.
Contrast this to Web ads. I find it rare that I even notice an ad on a web page. Market researchs have also found this for average web surfers. But there isn't enough bandwidth to make an ad as entertaining as a TV ad. So, a very large number of ads have tried to do the "flashy catch-you eye" thing which isn't entertaining, it's annoying. When you do look, you feel gypped and you move on, forgetting the whole thing a few seconds later.
And that is the best case on a website that is meant to be entertaining. Remember that I said TV ads fit their medium. The web allows for more than entertainment. You can have informational resources as well (I don't feel that TV allows this, because TV can never cover the right amount of information. What you get is infotainment or entertainment news). A web ad also cannot project enough information about a product within the limitations of the ad.
What I envision more and more is a rise of full articles that are actually ads, like those in magazines. Ads will try to blend in more with content, because content is what we look for on the web. But the ads can be out of place. You can't have a paragraph talking about an Isuzu Trooper in the middle of the Onion. Editors won't want theri reader to get the gypped feeling because they may stop going to the website all together.
All and all, I think the most important thing to consider is that the Web is a new medium, and as such we are still learning how to advertise effectivly. I highly doubt popups are it. They will just annoy more people, and you don't want to annoy your ad viewers, you want them to want to see your ad.
Judging from the context that "Read aloud" is in, it probably means that you cannot instruct your ebook viewer to read it aloud using voice synth. Those aren't license agreements, they are permissions. You can't copy it, you can't print it. These are standard PDF permissions. The ebook reader probably has other funtions (or will in later releases) for lending, giving, and reading books aloud.
There's an recent article on Kuro5hin about fear of XHTML. The most relevent thing in it is how people will violently stick to what they know. They learned to use font tags instead of CSS, and so they like it that way. They fear that their pages will not work in the future, and they fear that they can't do the same things in XHTML as in HTML.
This is an example of how advocacy (in this case HTML over XHTML/CSS) is very bad for everyone involved. People do not want to leave HTML, so parsers will have to continue to be complex. Browser incomatibilities will widen even more.
I often see this kind of thing. A new standard comes out, and it solves more problems than before, but there is this inertia on the existing standard. It's almost as if people decide that they have learned enough for them to retire on.
<shudder> You just reminded me of a job I once had where they had a lot of FORTRAN programmers who were working on a large C system. What they had done was created a header file like so:
#define BEGIN {
#define END }
#define IF if (
#define THEN ) {
#define ELSIF } else if (
#define ELSE } else {
#define ENDIF }
Every C file used this syntax instead of C's. I agree that syntax wars are the lowest form of language advocacy, but that was aweful. My feeling is if you are going to use C, use C. I also don't believe in abusing the preprocessor.
Not nearly as bad as one guy there who did the following though:
#define TRUE 0
#define FALSE -1
Throughout his code, he used these values consistently. In IF (not if, IF, see above), statements he would always compare the boolean return to TRUE. After I inherited his code, I was adding some stuff and did a WHILE TRUE DO (yes, I had to use the macros, because they wanted their source to remain consistent) with a break condition. It took me quite a while to figure out why it wouldn't execute. At first I thought it was a bug in the compiler optimization.
Sigh.
Of course, this is just a guess, but if I had been writing the FAQ, I would have been afraid to say ``You don't need linked lists in Perl'' and leave it at that, because I would have imagined someone reading that answer and concluding that it was an evasion and that linked lists couldn't be done at all in Perl.
This part of the article reminded me of a similar problem with Java. When Java first came out, it was billed as "safe" and "has no pointers". This often lead people to ask in comp.lang.java "How do you make a linked list in Java"? Similar to perl, the right answer was to use a java.util.Vector (now the right answer is java.util.ArrayList), since it will provide most of what you need from a linked list.
But people took this to mean that you couldn't make a linked list in Java and instead had to use special built-in classes. In actuality, making a linked list in Java is easy:
class LinkedList {
Object value;
LinkedList next;
}
But people were willing to believe that this was a failure in Java, even though it A) wasn't a failure since you could do it anyways and B) had a standard and often better (O(1) lookup) way of doing things.
Yeah, but try finding enough class A programmers to do a large project. By class A, I mean, they can think for themselves, solve problems quickly by themselves, can understand other poeple code and integrate their code with others, and rigorously test the shit out of their code. I've interviewed a lot of people try to fill enough for projects. Most people suck so bad, when an o.k. person comes along, you're happy to hire.
Try the K Browser by 4th pass. It will allow you to access WAP applications from a Palm.
In the article Lanier says
"I mean, everything in Unix is ultimately based on command line interactions. You can try to overcome that, but it's very hard. Unix's whole philosophy on how to do internal management and how to manage timing is based on that set of assumptions, so you have to fight it at a thousand levels."
In a lot of ways this is true for all operating systems. In Windows, you can see the command line present when you are associating an action to a file extension. You will 9 times out of 10 be setting up a command line that launches a program on the file. The other 1 time out of 10, it will support DDE or something.
My feeling is that the command line is a programming language. Often it is handy to use that programming language in a GUI (for example when setting up associations). Because of this, it will always be hard to get entirely away from the command line. Especially when the command line is a large part of our programming languages (ANSI C and Java define main to take parameters from a "command line").
So I don't see how any one operating system has a more "command line feel" than another.
Then again, I've never tried to build a virtual reality interface on top of UNIX.
The point is that the play button is an icon. You press it, just like you would press an icon in a GUI. Even icons in GUIs are labeled. The difference is that the CD player isn't just a box with no labels or buttons that you have to remember the commands for.
I do prefer CLI, though, since I can remember many of the commands. Plus it's a lot easier to put in a document what commands to type rather than Which|Tab|To|Go To to check which box.
No, the penalty was high because, like the original poster said, it was a deterent to a crime that could be easily gotten away with. It was for "rustling," not stealing a single horse. It was for rustling cattle, as well. The problem was that it was easy for people to come in at night and rustle animals. To prevent people from doing this, a high penalty was given. If it was just 6 months in jail, then it was be worth it to take the risk of rustling. If it's death, then the risk is often too high (but not always, apparently).
The inhabitants would have significant advantages in the world of e-commerce. They are already running on "internet time".
Density does effect gravity. This is because gravity is inversly proportional to the square of the distance between the two masses. While this relationship is difficult to model for a vastly large body, like th Earth, you can simplify it by thinking of the distance being to the center of the Earth. Mass closer will exhert more gravity, mass farth will exhert less, but it mostly works out. If you strech the mass of the Earth over 10000 times the volume (no where near the size of a nebula, BTW), you would get 1/(10000)^2/3 ~= 1/464 times the gravity (the cube root is because it is square to the distance, which is found by the cube root of the volume).
Of course, this isn't to say that density is the actual important factor. It is of course, Gravity. A 10000 times larger body with 464 times more mass would have the same gravity and could sustain an atmosphere like earths.
I also wonder if their soundtracking Fox's "Malcolm in the Middle" is also having a positive effect on the band's popularity.
The problem is that someone is going to have to go through the legal fees of proving that there is prior art inorder to show that this patent is ludicrous.
I actually bought tickets to the Hootie concert just to see TMBG. I was very pissed off when they announced the last minute that instead 54'40 was playing instead and would not refund the tickets (since they were for Hootie and the Blowfish, not TMBG. The tickets didn't even say TMBG on them).
I did get to see them on the severe tire damage tour, though. They are a great show and I highly recommend going to anyone who is a fan.
To the moderator who moderated this offtopic: They Might Be Giants has a song, titled "Older" (note the title of this thread). The refrain of that song is "You're older than you've ever been, and now you're even older/Now you're even older/Now you're even older/You're older than you've ever been, and now you're even older/Now you're even older still". I fail to see how this is offtopic.
To all moderators: if you don't understand a comment, don't moderate it down. It may still actually mean something.
The the metamoderator: sick em! :)
You can use a service like Surfola to get around these filters at work. Surfola gets the pages, relinks them to use their CGI, and then send them to you from their site. According to the SmartFilterWhere, there is no listing for it.
This is news for nerds, not news for geeks.