*Web Accelerator can load certain Web page text and graphics faster than with a standard 56k dial-up Internet service. Actual speeds may vary. **Pop-up Blocker requires Internet Explorer® 5.5 or higher. *** E-mail acceleration may not be compatible with certain computer systems.
I heard an ad on the radio yesterday for netscape internet, for $9.95 a month (www.getnetscape.com). Apparently they are trying to compete with netzero. I wonder which of the 4 groups this will be a part of.
You're right, it is terminate that gets called, and what's worse, the standard doesn't guarantee that the stack gets unwound when terminate is called. After terminate is called, it would be a bad idea to force the stack to be unwound, and it would be a bad idea to not clean up resources by unwinding the stack. So scratch my original idea and just catch(...) for every system call. This is what I do when I wrap C++ code with Ruby, and it works pretty well.
There are a number of cases where a valid C program is not a valid C++ program. The easiest example is a program that uses "class" as an identifier; it will work fine with a C compiler, but it will fail to compile in C++, as "class" is a reserved keyword.
An uncaught exception is a kernel panic. By contrast, an unknown error return is still an error, and usually the right thing happens.
An uncaught exception results in a call to unexpected(), which by default calls std::terminate(). This behavior can be overridden using std::set_unexpected() to, for example, return an unknown error to the caller of the currently executing system call.
Oh dear. Another person who thinks that exceptions should never be thrown.
If exceptions were never meant to be thrown, they wouldn't be in the language. Exceptions are an abstraction for dealing with exceptional conditions -- conditions that do not normally occur, but can occur. At the expense of some additional complexity, they make error checking a little simpler and less bug-prone. When (not if -- assuming you are a believer in Murphy's law) those exceptional conditions occur, your program better be able to handle them correctly.
You are right that some people do use exceptions when not appropriate. Exceptions are (generally) not appropriate for exiting loops, for example. But they are more than appropriate for out of memory conditions, out of disk space conditions, etc.
The reason they are not viable performance-wise is not because they are too expensive to throw; it is because they are too expensive when they are never thrown at all. There's generally a 5-10% performance hit just from having code that might possibly throw an exception, depending on your compiler's implementation. The numbers on the netlab page are for throwing exceptions, unfortunately; I would be interested in seeing if they got a performance benefit when exceptions are not thrown. Guess I'll have to dig to find a copy of the paper.
Any kernel project that uses C++ is most likely doomed to be an experimental project and will most likely never be included in the kernel. IMO, there's good reason for that, too. The added complexity just doesn't outweigh the benefits of using C++ over C.
In fact, there was a good post on kerneltrap not to long ago about C++ inside the linux kernel:
The Ruby interpreter will not run python code, nor will it run perl code.
Ruby borrows features and ideas from perl, scheme, and smalltalk. From perl it gets powerful regular expressions and other features that are generally useless but are great for one-liners. From scheme it gets continuations and lambdas. From smalltalk it gets blocks, which are a very powerful way to represent acquiring and releasing of resources.
I don't know what ruby might borrow from python, but I'm sure there's something. The syntax is similar, at any rate.
All this borrowing is a good thing. It means that Ruby can take the best of what's out there and combine it into a single package. But when it does that, it loses something in the process. Ruby isn't good for purely functional-style programming; use scheme for that. In ruby almost everything is an object, but if you want everything to be an object (even your control structures) you should consider smalltalk. And ruby isn't the fastest interpreter out there; if you want something faster, determine your requirements and write some benchmarks to find something that suits your needs.
Ruby is a great language, but what's even better is its community. It's a small community right now, and with a small community comes a quaintness and a friendliness that is generally not found in larger communities. Unfortunately, a side efefect of ruby's small community is that there are fewer libraries available for ruby than for, say, perl or python. Plus a nice small community is something that cannot last; as ruby gains in popularity, it will attract trolls and garbage library writers.
Give ruby a try, but don't expect it to solve all your problems. It will not make breakfast for you in bed or greet you with a kiss.
In order to sell their games, creators of MMO games must convince their audience that there is a reason to play the game, that there is something at stake. There is an illusion of power achieved once you reach the top. In order to achieve that power (or a perverted form of that power -- in the case of someone who simply ruins others' experience), there are people who are willing to do whatever is necessary, no matter the cost.
The problem isn't that the game is too close to reality, but in order to keep interest, it must maintain an illusion of certain aspects of reality, otherwise participants will either play only from time to time (as in a hobby) or realize that there is more to life than online gaming and find something better to do. Obviously game manufacturers make more money if more people play more often.
So we find scenarios in games where people form friendships and close relationships. We find cases where the "love" between two individuals is just as strong as in real life, and the consequences of breaking trust just as severe. We find cases where people have real envy, because the game creators create the illusion that there really is something worth envying. We find cases where people become attached to the things they "own" -- when they really own nothing.
Unless human nature is suspended during the course of the game, it's no surprise that crimes and other perversions will happen. And if that happens the game becomes no more interesting than tic-tac-toe or a first-person shooter.
if the kernel expects a 32-bit FILE * and you send it a 64-bit one, you're going to have trouble doing I/O
Apps don't pass FILE*'s to the kernel. The FILE type is used only by the C library. File access to the kernel is done using ints (file descriptors), not file pointers.
In the 80's a man by the name of William Chamberlain wrote a program called Racter , which had the ability to write poetry. Racter even has a book out called The Policeman's Beard is Half-Constructed.
Racter had two serious objections. For one, Racter's poetry sounds much like the ramblings of a madman, e.g.:
Bill sings to Sarah. Sarah sings to Bill. Perhaps they will do other dangerous things together. They may eat lamb or stroke each other. They may chant of their difficulties and their happiness. They have love but they also have typewriters. That is interesting
The other serious objection people have to Racter is that because the author had such a strong influence on the parameters used to generate the poetry that he is the true author and not the computer.
If these same objections can be applied to Kurzweil's work, then the cybernetic poet is no better than Racter and isn't particularly interesting. According to the article, the author claims that his program is more sophisticated than other software out there, but the article doesn't include any specific comparisons.
Is this really a major leap forward or is this just another stab at artificial insanity?
The point about mmap(2) is to let the system (the VM subsystem of the kernel) manage the caching for the userland processes using it, avoiding extra copies to/from buffers in userland and eliminating in several cases the need for custom caching code (processes don't have to worry about data being available in RAM: the kernel automatically takes care of that when needed).
Most applications, however, do not take full advantage of mmap. Most applications don't even need to take advantage of mmap. Those that do use mmap for something other than memory allocation (malloc uses mmap under the hood) or loading shared libraries don't mmap large files. It's just as simple to use a database for most applications, plus with a database you get all sorts of querying abilities without the extra development time it would take to do the same with an mmap-based solution. And databases don't get dumped with the rest of the core when an application segfaults (on Linux, mmap'd memory gets dumped to disk with core, and afaict there's no way to disable this).
I seriously doubt we'll be seeing applications any time soon taking advantage 64-bits of address space by using mmap().
... or perhaps multiple things going around. I've received at least 100 emails in the last 12 hours that got past spamassassin.
One program appears to be a 140K executable disguised as a Microsoft update. This one is Swen (aka Gibe.F):
http://www.securityfocus.com/archive/1/338121/2003 -09-16/2003-09-22/0
http://www.f-secure.com/v-descs/swen.shtml
http://news.com.com/2100-7349_3-5078696.html
http://www.us.sophos.com/virusinfo/analyses/w32gib ef.html
http://www.topnic.com/virus_warnings.shtml
The other appears to be much smaller at about 0.1K and shows up as mail returned to sender. I have not been able to find any information on this one.
Both appear to use "SUBJECT:" instead of "Subject:", so they should be easy to filter with nothing more than procmail.
I suspect the reason for that scene was solely to keep religious groups from doing to the sequel what the did to the first movie: tear it apart limb for limb by analyzing every bit religious allusion they could find. I even know of people who went so far as to use the Matrix as a tool for evangelism. Right or wrong, I think this is what the producers wanted to avoid.
Slashdot Mirror
BTW, I found their fine print a bit funny:
*Web Accelerator can load certain Web page text and graphics faster than with a standard 56k dial-up Internet service. Actual speeds may vary. **Pop-up Blocker requires Internet Explorer® 5.5 or higher. *** E-mail acceleration may not be compatible with certain computer systems.
I heard an ad on the radio yesterday for netscape internet, for $9.95 a month (www.getnetscape.com). Apparently they are trying to compete with netzero. I wonder which of the 4 groups this will be a part of.
It's spelled p-a-c-k-b-o-t but it's pronounced "dah'-lek".
You're right, it is terminate that gets called, and what's worse, the standard doesn't guarantee that the stack gets unwound when terminate is called. After terminate is called, it would be a bad idea to force the stack to be unwound, and it would be a bad idea to not clean up resources by unwinding the stack. So scratch my original idea and just catch(...) for every system call. This is what I do when I wrap C++ code with Ruby, and it works pretty well.
There are a number of cases where a valid C program is not a valid C++ program. The easiest example is a program that uses "class" as an identifier; it will work fine with a C compiler, but it will fail to compile in C++, as "class" is a reserved keyword.
An uncaught exception is a kernel panic. By contrast, an unknown error return is still an error, and usually the right thing happens.
An uncaught exception results in a call to unexpected(), which by default calls std::terminate(). This behavior can be overridden using std::set_unexpected() to, for example, return an unknown error to the caller of the currently executing system call.
C++ is not a superset of C. C++, C89, and C99 all share a common subset.
Oh dear. Another person who thinks that exceptions should never be thrown.
If exceptions were never meant to be thrown, they wouldn't be in the language. Exceptions are an abstraction for dealing with exceptional conditions -- conditions that do not normally occur, but can occur. At the expense of some additional complexity, they make error checking a little simpler and less bug-prone. When (not if -- assuming you are a believer in Murphy's law) those exceptional conditions occur, your program better be able to handle them correctly.
You are right that some people do use exceptions when not appropriate. Exceptions are (generally) not appropriate for exiting loops, for example. But they are more than appropriate for out of memory conditions, out of disk space conditions, etc.
The reason they are not viable performance-wise is not because they are too expensive to throw; it is because they are too expensive when they are never thrown at all. There's generally a 5-10% performance hit just from having code that might possibly throw an exception, depending on your compiler's implementation. The numbers on the netlab page are for throwing exceptions, unfortunately; I would be interested in seeing if they got a performance benefit when exceptions are not thrown. Guess I'll have to dig to find a copy of the paper.
Any kernel project that uses C++ is most likely doomed to be an experimental project and will most likely never be included in the kernel. IMO, there's good reason for that, too. The added complexity just doesn't outweigh the benefits of using C++ over C.
In fact, there was a good post on kerneltrap not to long ago about C++ inside the linux kernel:
http://kerneltrap.org/node/view/2067
Worth a read if you've got a few minutes to burn.
Will it repond to human voice ala hal9000 or furby?
Some search engines:
www.lycos.com
www.altavista.com
www.infoseek.com
www.hotbot.com
www.excite.com
www.webcrawler.com
www.askjeeves.com
www.searchengines.net
www.metacrawler.com
BTW, inference find (www.infind.com) used to be my favorite engine of all, but alas, they are no more.
The Ruby interpreter will not run python code, nor will it run perl code.
Ruby borrows features and ideas from perl, scheme, and smalltalk. From perl it gets powerful regular expressions and other features that are generally useless but are great for one-liners. From scheme it gets continuations and lambdas. From smalltalk it gets blocks, which are a very powerful way to represent acquiring and releasing of resources.
I don't know what ruby might borrow from python, but I'm sure there's something. The syntax is similar, at any rate.
All this borrowing is a good thing. It means that Ruby can take the best of what's out there and combine it into a single package. But when it does that, it loses something in the process. Ruby isn't good for purely functional-style programming; use scheme for that. In ruby almost everything is an object, but if you want everything to be an object (even your control structures) you should consider smalltalk. And ruby isn't the fastest interpreter out there; if you want something faster, determine your requirements and write some benchmarks to find something that suits your needs.
Ruby is a great language, but what's even better is its community. It's a small community right now, and with a small community comes a quaintness and a friendliness that is generally not found in larger communities. Unfortunately, a side efefect of ruby's small community is that there are fewer libraries available for ruby than for, say, perl or python. Plus a nice small community is something that cannot last; as ruby gains in popularity, it will attract trolls and garbage library writers.
Give ruby a try, but don't expect it to solve all your problems. It will not make breakfast for you in bed or greet you with a kiss.
I think they are almost opposites.
I've timed out in conversation on more than one oc
In order to sell their games, creators of MMO games must convince their audience that there is a reason to play the game, that there is something at stake. There is an illusion of power achieved once you reach the top. In order to achieve that power (or a perverted form of that power -- in the case of someone who simply ruins others' experience), there are people who are willing to do whatever is necessary, no matter the cost.
The problem isn't that the game is too close to reality, but in order to keep interest, it must maintain an illusion of certain aspects of reality, otherwise participants will either play only from time to time (as in a hobby) or realize that there is more to life than online gaming and find something better to do. Obviously game manufacturers make more money if more people play more often.
So we find scenarios in games where people form friendships and close relationships. We find cases where the "love" between two individuals is just as strong as in real life, and the consequences of breaking trust just as severe. We find cases where people have real envy, because the game creators create the illusion that there really is something worth envying. We find cases where people become attached to the things they "own" -- when they really own nothing.
Unless human nature is suspended during the course of the game, it's no surprise that crimes and other perversions will happen. And if that happens the game becomes no more interesting than tic-tac-toe or a first-person shooter.
In true Car Talk style... I like this post. :)
You are mistaken. You have been assimiliated.
if the kernel expects a 32-bit FILE * and you send it a 64-bit one, you're going to have trouble doing I/O
Apps don't pass FILE*'s to the kernel. The FILE type is used only by the C library. File access to the kernel is done using ints (file descriptors), not file pointers.
I love it when a post gets modded down for being a troll when someone does little more than point out a flaw in logic.
In the 80's a man by the name of William Chamberlain wrote a program called Racter , which had the ability to write poetry. Racter even has a book out called The Policeman's Beard is Half-Constructed.
Racter had two serious objections. For one, Racter's poetry sounds much like the ramblings of a madman, e.g.:
The other serious objection people have to Racter is that because the author had such a strong influence on the parameters used to generate the poetry that he is the true author and not the computer.
If these same objections can be applied to Kurzweil's work, then the cybernetic poet is no better than Racter and isn't particularly interesting. According to the article, the author claims that his program is more sophisticated than other software out there, but the article doesn't include any specific comparisons.
Is this really a major leap forward or is this just another stab at artificial insanity?
The point about mmap(2) is to let the system (the VM subsystem of the kernel) manage the caching for the userland processes using it, avoiding extra copies to/from buffers in userland and eliminating in several cases the need for custom caching code (processes don't have to worry about data being available in RAM: the kernel automatically takes care of that when needed).
Most applications, however, do not take full advantage of mmap. Most applications don't even need to take advantage of mmap. Those that do use mmap for something other than memory allocation (malloc uses mmap under the hood) or loading shared libraries don't mmap large files. It's just as simple to use a database for most applications, plus with a database you get all sorts of querying abilities without the extra development time it would take to do the same with an mmap-based solution. And databases don't get dumped with the rest of the core when an application segfaults (on Linux, mmap'd memory gets dumped to disk with core, and afaict there's no way to disable this).
I seriously doubt we'll be seeing applications any time soon taking advantage 64-bits of address space by using mmap().
... or perhaps multiple things going around. I've received at least 100 emails in the last 12 hours that got past spamassassin.
3 -09-16/2003-09-22/0b ef.html
One program appears to be a 140K executable disguised as a Microsoft update. This one is Swen (aka Gibe.F):
http://www.securityfocus.com/archive/1/338121/200
http://www.f-secure.com/v-descs/swen.shtml
http://news.com.com/2100-7349_3-5078696.html
http://www.us.sophos.com/virusinfo/analyses/w32gi
http://www.topnic.com/virus_warnings.shtml
The other appears to be much smaller at about 0.1K and shows up as mail returned to sender. I have not been able to find any information on this one.
Both appear to use "SUBJECT:" instead of "Subject:", so they should be easy to filter with nothing more than procmail.
Using their name servers listed at:
http://www.opennic.unrated.net/cgi-bin/get_tier2 .sh
I get:
[me@mymachine]$ host slkdfjsdf.com 144.162.120.230
Using domain server:
Name: 144.162.120.230
Address: 144.162.120.230#53
Aliases:
slkdfjsdf.com has address 64.94.110.11
And since their website's latest news is from Februrary, somehow I don't think they will be addressing this issue any time soon.
If peple would lern to spel we wuld not have theze problums.
I suspect the reason for that scene was solely to keep religious groups from doing to the sequel what the did to the first movie: tear it apart limb for limb by analyzing every bit religious allusion they could find. I even know of people who went so far as to use the Matrix as a tool for evangelism. Right or wrong, I think this is what the producers wanted to avoid.