You're not really disagreeing with me here. I agree that they are not a part of the C Language, but they are a part of the established ISO/ANSI Standard known as "Standard C" aka "ANSI C", and therefore they are required for all implementations which conform to this standard. And stdio and stdlib are just the names of the header files which contain certain functions from the Standard C library specification. There is no requirement that they represent actual library names. Most commonly the functions specified in the stdio and stdlib header are both contain in a library which is actually called "libc".
I disagree. Oh, you mean, the GPL is superior because is restricts what I can do with the code.
They key problem with your statement here (and everyone else who makes these claims) is the confusion about who "I" is referring to. By stating your point in this manner, you leave a grey area that leads people to assume that the GPL somehow abridges the rights of the person who created the content (as compared to a BSD-style license).
The truth of the matter is that as compared to a BSD-style license, none of the author's rights are further abridged by going GPL - it is the end-user's rights which are further abridged.
GPL = I make code. I give code to everyone. Everyone shares my creation in the spirit that I originally created it, or they're not allowed to share in it at all.
BSD = I make code. I give code to everyone. Nice people share my creation in the spirit that I originally created it, but mean people are free to steal my ideas and their augmentations from the free community and make a killing off of it, and there's not a damn thing I can do about it.
The only tenable position from which one can argue that their rights were restricted by the GPL is the position of the mean guy above, who was trying to rip off the open source coder. In which case you can suck it.
That would be your easiest route. It's all C, it's a decent toolkit, it's fairly portable, etc...
If it were me, I'd explore that first - but if that didn't work out right (say you want odd shaping of how the GUI overlays the GL stuff), then I'd switch to rendering the GUI into textures and letting OpenGL put the GUI on the screen. Just about anything (GTK or what-have-you) can be made to render to a bitmap in memory which serves as the texture for an OpenGL polygon that's placed where it needs to be for the GUI to look right.
Sounds great till he falls and breaks his hip.
on
A Killer App For Segway
·
· Score: 2, Funny
What a great idea for a fragile old man who has trouble walking - stick him standing up on a gyro-balanced thing that walks faster than we ever could and hope he doesn't manage to fall off.
I would hardly call the current US healthcare system an experiment in free markets. It is the non-"free market" aspects of the current healthcare system that are causing it to suck so bad. Luckily it's in the process of correcting itself as best it can in spite of government interference. When healthcare ultimately does operate as a smooth free market, Doctors will have suffered a significant loss in their pay compared to how things used to be, insurance companies won't get to do the evil things they currently do, and everyone will actually be able to afford decent healthcare. Insurance will be for traumatic events and serious illness, and will be unneccesary for routine medical treatment, which will be affordable.
stdio/stdlib aren't really libraries, they're just header files. The technical distinction you're looking for is actually between 4 things:
1) The C language (the half page of reserved keywords you mentioned - you get no header files with this (I don't think?))
2) "Standard C" or "The Standard C Library", which now comes in two major flavors - C89 and C99. This is all those headers like stdlib.h and stdio.h. This is an official standard, and barring a few isolated compilers made for specialized embedded systems that might support the core C syntax but not the Standard C environment, almost all remotely modern C compiler environments support "Standard C" (aka ISO C, aka ANSI C, whatever...).
3) POSIX, which comes in a few different levels, flavors, and revisions. POSIX builds on top of Standard C and adds a few more portable things. Most OSes support the vast majority of POSIX, and they'll usually document somewhere what parts of POSIX they're conformant with to what degree. Related to POSIX are several other standards and pseudo-standards that are more unix-centric than POSIX (POSIX is quite unixy in its nature, but it also focuses on being as OS-neutral as it can) with names like SUS (Single Unix Standard), X/OPEN, SVR4, BSD, SVID, Unix98, etc... Many of them overlap (and sometimes contradict) the areas that POSIX and Standard C cover, and many unixes support some set of those standards to some degree.
4) Other libraries... this is where you branch out into all the millions of libraries that may or may not exist on various systems and may or may not be covered by their own standards.
Actually, with the interventionist picocells discussed above for allowing emergency calls, I suspect it's only a matter of time before they twist this right to the local airwaves in their establishment into a right to intercept local cell calls and precede them with audio advertisements. Imagine a shopping mall installed one of these, allowing all calls through, but injecting a 15-second audio-ad about a sale at some store in the mall before letting you proceed with your call...:(
Yes, I agree that from some god's-eye view, one could make an algorithm that does everything a human brain does. However, I don't think a human (or a team of humans) can create such an algorithm by hand. The task is simply much too complex to consider.
I think there might perhaps be multiple ways of achieving true human-level AI, and the one we're most likely to end up discovering and succeeding at is one that models our own brain and how it evolved.
That being said, I doubt that many of the current "AI building blocks" that people bandy about as AI will actually end up being true building blocks of the "right" solution. They are more like early research and theory-testing that is statistically unlikely to do anything but prove how not to accomplish the goal.
If I were to go out on a limb as an interested layman, I would say that I expect that any AI effort that truly succeeds will probably have the following properties:
1) It won't be "designed" from a high-level algorithmic viewpoint. We will design the basic elements correctly (neuron-like elements), and design some general rules about how they interconnect with each other and how those interconnects are allowed to change, and that's pretty much it. Determining the right "formula" for these things is very hard, and currently unsolved.
2) Some of the design in (1) above, and nearly all layers of design beyond that (specifics of how things are interconnected in the initial state when the AI entity first boots, equivalent to human birth) will probably be "naturally" evolved through some sort of genetic evolution process (much like current effort in genetic evolution of circuitry and algorithms).
3) A certain amount of non-determinism will be crucial. This could either come from some internal true-RNG sources, or perhaps more likely it comes from the confluence of random external data streaming in from all of the external sensors. Assuming the sensory-input approach as opposed to the internal RNG approach, it might even be valid to say that true AI will be impossible without a large amount of input data from the real world in the form of sensors - that it just doesn't work in "isolation" when the only I/O is simple and fairly deterministic.
4) Virtually everything should have some chance of being able to affect virtually everything. That is to say, there should always be a small chance that the slight change in room temperature picked up by some sensor might alter the AI entity's choice of words as it translates a german novel into english by reading and speaking aloud.
I don't think that the kinds of "AI" discussed in this article, or other similar efforts, deserve the label AI, as I don't feel they really come close to the "right" final solution, and I don't feel they're even building blocks along the way - except in the sense that they're tools to help AI researchers better wrap their own brains around the problem and come up with new and different approaches.
I'm still using my commercial Vonage service as my primary home line. It has never had any any audio quality problems or service outages that I've noticed, and it's a steal price-wise. With the activation fees and shipping and everything, my initial bill to get set up and cover the first month was $57.78, and thereafter it's been $16.94 a month (I use their 500 minute plan instead of the unlimited minutes, it's cheaper and I doubt I'd go over that on my home voice line).
On top of all that, I've set my T-mobile cellphone to use my Vonage voicemail service, and I've set both phones to foward to each other when out of service or unanswered (which surprisingly has caused any wierd problems with a call bouncing back and forth yet). And all my voicemails get emailed to me in.wav format. The alert emails also get forwarded to my cellphone as emails... you get the idea. It's great:)
Without the benefits of what you're calling "sapience", AI is no more useful than a very complex algorithm. I challenge you to find any AI that exists today that cannot be replicated in functionality and coverage by a human-programmed software algorithm that doesn't pretend to be "AI".
I have a Backpack laptop bag made by Taurus in black leather that has been my favorite one for years. It was probably ~6-7 years ago when I bought it though, and I don't see it on their website anywhere:( The leather makes it very comfortable, has good padding everywhere you'd want it.
I still hold firm that this is not "AI", and shouldn't be called "AI". I personally think the definitive layman-readable works on the problems of AI are Hofstatder's infamous GEB and MMT books. And (again in my personal opinion, but of course I think I'm right) I will never consider any peice of software to be "AI" until it can prove at least some rudimentary capability to overcome the challenges noted in those books. For examples of some of these human-intelligence things: Always being able to quickly prevent infinite recursion/looping, advanced ability to process truly "new" information (such as alway being able to recognize english characters regardless of the strangeness of the font), and the ability to truly (re)interpret conceptual notions in previously unknown mediums (e.g. - see the "Bach"-ness of a painting).
I wish the whole world would stop misusing the term. Just because AI researchers have failed for decades to make any significant progress towards true aritficial intelligence does not give them or the rest of the world license to water the term down and redefine the goals until it means virtually nothing.
FYI you can copy your doom3/base/savedgames folder into your linux install from your windows/wine install to pick up where you left off. It worked for me, but my last QuickSave which was halfway through a level started me back at the beginning of that level.
I think Google (or anyone) shouldn't have a problem just giving people "unlimited" email space (and then whacking abuser accounts who mount gmail-based filesystems to store terabytes of pr0n...). For legitimate users of the system:
1) It's text, compress it, save space.
2) If you have a large user base, chances are there are many duplicate emails floating around the system. Hash everyone's email body-content globally. Then when that stupid email gets forwarded to 6000 of your customers, it only gets stored once for each unique form it arrives in. Ditto for mailing list emails.
3) Make sure that your spam filter is really good, and especially that it never falses tosses legit emails, so that people trust it. Anything that's in the spam box gets autokilled in a week.
4) Limit attachments to reasonable sizes. You're trying to stop people from email-attaching a 700MB uncompressed cd rip, or whatever. Gmail currently limits the entire message, all attachments included, to 10MB in size. They do other stupid things too though, like not letting you send zipfiles... A better system that leaves more freedom for the user might be to say that all attachment types are legal, but if a message's total length exceeds 10MB, then attachments in it will be "flagged for deletion", starting with the largest attachment in the message first, until the number is under 10MB. These larger "flagged for deletion" attachments get forceably deleted from your email archives after 24 hours, or 3 days, or something of that nature. In this way you can still transport large files via email, you just can't archive them there.
Once those simple measures are in place, you can largely rely on statistics and reasonability. If a reasonably average webmail user actually received and archived over a gig of mail in a year under such a system I'd be impressed.
Your whole screen "lags", you just happen to notice in with your mouse the most. It's a common LCD problem, and it can cause motion-blurry video games too, among other things. Newer and/or more expensive LCDs minimize (or eliminate from what I've heard, but not seen myself) the problem. Feel free to buy a computer monitor online for the price - but always check out the exact brand and model at a physical store first.
One of the central real issues behind the SSO problem is that existing directory services are just directory services - they have no concept of a session originating at a certain terminal or access point. Integrating "sessioning" into directory services in a way that's secure and useful to operating systems and applications is the key to doing SSO "right", where a user should only have to authenticate once when they sit down at their terminal to work on myriad systems.
This is not biology. The severe, frequent virus outbreaks that have happened in recent times were entirely, realistically, preventable. You don't have to conduct a 6.2 million dollar study into "vectors" and whatnot.
How many more incidents does it take until some major corporations start sueing Microsoft for the damages caused by their gross negligence?
No, it just means whoever submitted the article wasn't using "direct ancestor" in the way that most of us would have. I would imagine there's no code from CTSS directly in Linux.
You can spin this data any way you want to (assuming it is valid data - I would tend to assume that the voting population in the study was hardly randomized among all the various determinant factors). I'll provide an opposed spin (it's stupid, but no more so than any of the others) that makes the data pro-Bush:
In the current geopolitical scene, one country's financial loss is another's gain. Therefore smart people in the world would try to push for a candidate in the US who would cause the US to lose in the larger global fiscal game (not in a big de-stabilizing way that would backfire, just enough that the other countries can take advantage). Therefore the fact that people outside the US overwhelmingly favor Kerry means that they are predicting (in the market sense) that Bush would lead to a stronger US fiscal victory over the rest of the world.
Slashdot Mirror
Sorry for the late reply, I do that a lot.
You're not really disagreeing with me here. I agree that they are not a part of the C Language, but they are a part of the established ISO/ANSI Standard known as "Standard C" aka "ANSI C", and therefore they are required for all implementations which conform to this standard. And stdio and stdlib are just the names of the header files which contain certain functions from the Standard C library specification. There is no requirement that they represent actual library names. Most commonly the functions specified in the stdio and stdlib header are both contain in a library which is actually called "libc".
They key problem with your statement here (and everyone else who makes these claims) is the confusion about who "I" is referring to. By stating your point in this manner, you leave a grey area that leads people to assume that the GPL somehow abridges the rights of the person who created the content (as compared to a BSD-style license).
The truth of the matter is that as compared to a BSD-style license, none of the author's rights are further abridged by going GPL - it is the end-user's rights which are further abridged.
GPL = I make code. I give code to everyone. Everyone shares my creation in the spirit that I originally created it, or they're not allowed to share in it at all.
BSD = I make code. I give code to everyone. Nice people share my creation in the spirit that I originally created it, but mean people are free to steal my ideas and their augmentations from the free community and make a killing off of it, and there's not a damn thing I can do about it.
The only tenable position from which one can argue that their rights were restricted by the GPL is the position of the mean guy above, who was trying to rip off the open source coder. In which case you can suck it.
int KerryVotes=0;
int BushVotes=0;
void ParseVote(const char* v) {
if(!strcmp(v,"Kerry")) {
KerryVotes++;
} else if(strcmp(v,"Bush")) {
BushVotes++;
}
}
That would be your easiest route. It's all C, it's a decent toolkit, it's fairly portable, etc...
If it were me, I'd explore that first - but if that didn't work out right (say you want odd shaping of how the GUI overlays the GL stuff), then I'd switch to rendering the GUI into textures and letting OpenGL put the GUI on the screen. Just about anything (GTK or what-have-you) can be made to render to a bitmap in memory which serves as the texture for an OpenGL polygon that's placed where it needs to be for the GUI to look right.
What a great idea for a fragile old man who has trouble walking - stick him standing up on a gyro-balanced thing that walks faster than we ever could and hope he doesn't manage to fall off.
Wouldn't that be "ternary", or am I mistaken?
I would hardly call the current US healthcare system an experiment in free markets. It is the non-"free market" aspects of the current healthcare system that are causing it to suck so bad. Luckily it's in the process of correcting itself as best it can in spite of government interference. When healthcare ultimately does operate as a smooth free market, Doctors will have suffered a significant loss in their pay compared to how things used to be, insurance companies won't get to do the evil things they currently do, and everyone will actually be able to afford decent healthcare. Insurance will be for traumatic events and serious illness, and will be unneccesary for routine medical treatment, which will be affordable.
stdio/stdlib aren't really libraries, they're just header files. The technical distinction you're looking for is actually between 4 things:
1) The C language (the half page of reserved keywords you mentioned - you get no header files with this (I don't think?))
2) "Standard C" or "The Standard C Library", which now comes in two major flavors - C89 and C99. This is all those headers like stdlib.h and stdio.h. This is an official standard, and barring a few isolated compilers made for specialized embedded systems that might support the core C syntax but not the Standard C environment, almost all remotely modern C compiler environments support "Standard C" (aka ISO C, aka ANSI C, whatever...).
3) POSIX, which comes in a few different levels, flavors, and revisions. POSIX builds on top of Standard C and adds a few more portable things. Most OSes support the vast majority of POSIX, and they'll usually document somewhere what parts of POSIX they're conformant with to what degree. Related to POSIX are several other standards and pseudo-standards that are more unix-centric than POSIX (POSIX is quite unixy in its nature, but it also focuses on being as OS-neutral as it can) with names like SUS (Single Unix Standard), X/OPEN, SVR4, BSD, SVID, Unix98, etc... Many of them overlap (and sometimes contradict) the areas that POSIX and Standard C cover, and many unixes support some set of those standards to some degree.
4) Other libraries... this is where you branch out into all the millions of libraries that may or may not exist on various systems and may or may not be covered by their own standards.
Actually, with the interventionist picocells discussed above for allowing emergency calls, I suspect it's only a matter of time before they twist this right to the local airwaves in their establishment into a right to intercept local cell calls and precede them with audio advertisements. Imagine a shopping mall installed one of these, allowing all calls through, but injecting a 15-second audio-ad about a sale at some store in the mall before letting you proceed with your call...
Yes, I agree that from some god's-eye view, one could make an algorithm that does everything a human brain does. However, I don't think a human (or a team of humans) can create such an algorithm by hand. The task is simply much too complex to consider.
I think there might perhaps be multiple ways of achieving true human-level AI, and the one we're most likely to end up discovering and succeeding at is one that models our own brain and how it evolved.
That being said, I doubt that many of the current "AI building blocks" that people bandy about as AI will actually end up being true building blocks of the "right" solution. They are more like early research and theory-testing that is statistically unlikely to do anything but prove how not to accomplish the goal.
If I were to go out on a limb as an interested layman, I would say that I expect that any AI effort that truly succeeds will probably have the following properties:
1) It won't be "designed" from a high-level algorithmic viewpoint. We will design the basic elements correctly (neuron-like elements), and design some general rules about how they interconnect with each other and how those interconnects are allowed to change, and that's pretty much it. Determining the right "formula" for these things is very hard, and currently unsolved.
2) Some of the design in (1) above, and nearly all layers of design beyond that (specifics of how things are interconnected in the initial state when the AI entity first boots, equivalent to human birth) will probably be "naturally" evolved through some sort of genetic evolution process (much like current effort in genetic evolution of circuitry and algorithms).
3) A certain amount of non-determinism will be crucial. This could either come from some internal true-RNG sources, or perhaps more likely it comes from the confluence of random external data streaming in from all of the external sensors. Assuming the sensory-input approach as opposed to the internal RNG approach, it might even be valid to say that true AI will be impossible without a large amount of input data from the real world in the form of sensors - that it just doesn't work in "isolation" when the only I/O is simple and fairly deterministic.
4) Virtually everything should have some chance of being able to affect virtually everything. That is to say, there should always be a small chance that the slight change in room temperature picked up by some sensor might alter the AI entity's choice of words as it translates a german novel into english by reading and speaking aloud.
I don't think that the kinds of "AI" discussed in this article, or other similar efforts, deserve the label AI, as I don't feel they really come close to the "right" final solution, and I don't feel they're even building blocks along the way - except in the sense that they're tools to help AI researchers better wrap their own brains around the problem and come up with new and different approaches.
I'm still using my commercial Vonage service as my primary home line. It has never had any any audio quality problems or service outages that I've noticed, and it's a steal price-wise. With the activation fees and shipping and everything, my initial bill to get set up and cover the first month was $57.78, and thereafter it's been $16.94 a month (I use their 500 minute plan instead of the unlimited minutes, it's cheaper and I doubt I'd go over that on my home voice line).
On top of all that, I've set my T-mobile cellphone to use my Vonage voicemail service, and I've set both phones to foward to each other when out of service or unanswered (which surprisingly has caused any wierd problems with a call bouncing back and forth yet). And all my voicemails get emailed to me in
Without the benefits of what you're calling "sapience", AI is no more useful than a very complex algorithm. I challenge you to find any AI that exists today that cannot be replicated in functionality and coverage by a human-programmed software algorithm that doesn't pretend to be "AI".
--Brandon
s/Taurus/Targus/ :)
I have a Backpack laptop bag made by Taurus in black leather that has been my favorite one for years. It was probably ~6-7 years ago when I bought it though, and I don't see it on their website anywhere :( The leather makes it very comfortable, has good padding everywhere you'd want it.
I still hold firm that this is not "AI", and shouldn't be called "AI". I personally think the definitive layman-readable works on the problems of AI are Hofstatder's infamous GEB and MMT books. And (again in my personal opinion, but of course I think I'm right) I will never consider any peice of software to be "AI" until it can prove at least some rudimentary capability to overcome the challenges noted in those books. For examples of some of these human-intelligence things: Always being able to quickly prevent infinite recursion/looping, advanced ability to process truly "new" information (such as alway being able to recognize english characters regardless of the strangeness of the font), and the ability to truly (re)interpret conceptual notions in previously unknown mediums (e.g. - see the "Bach"-ness of a painting).
I wish the whole world would stop misusing the term. Just because AI researchers have failed for decades to make any significant progress towards true aritficial intelligence does not give them or the rest of the world license to water the term down and redefine the goals until it means virtually nothing.
s/45/48/
FYI you can copy your doom3/base/savedgames folder into your linux install from your windows/wine install to pick up where you left off. It worked for me, but my last QuickSave which was halfway through a level started me back at the beginning of that level.
I think Google (or anyone) shouldn't have a problem just giving people "unlimited" email space (and then whacking abuser accounts who mount gmail-based filesystems to store terabytes of pr0n...). For legitimate users of the system:
1) It's text, compress it, save space.
2) If you have a large user base, chances are there are many duplicate emails floating around the system. Hash everyone's email body-content globally. Then when that stupid email gets forwarded to 6000 of your customers, it only gets stored once for each unique form it arrives in. Ditto for mailing list emails.
3) Make sure that your spam filter is really good, and especially that it never falses tosses legit emails, so that people trust it. Anything that's in the spam box gets autokilled in a week.
4) Limit attachments to reasonable sizes. You're trying to stop people from email-attaching a 700MB uncompressed cd rip, or whatever. Gmail currently limits the entire message, all attachments included, to 10MB in size. They do other stupid things too though, like not letting you send zipfiles... A better system that leaves more freedom for the user might be to say that all attachment types are legal, but if a message's total length exceeds 10MB, then attachments in it will be "flagged for deletion", starting with the largest attachment in the message first, until the number is under 10MB. These larger "flagged for deletion" attachments get forceably deleted from your email archives after 24 hours, or 3 days, or something of that nature. In this way you can still transport large files via email, you just can't archive them there.
Once those simple measures are in place, you can largely rely on statistics and reasonability. If a reasonably average webmail user actually received and archived over a gig of mail in a year under such a system I'd be impressed.
Your whole screen "lags", you just happen to notice in with your mouse the most. It's a common LCD problem, and it can cause motion-blurry video games too, among other things. Newer and/or more expensive LCDs minimize (or eliminate from what I've heard, but not seen myself) the problem. Feel free to buy a computer monitor online for the price - but always check out the exact brand and model at a physical store first.
One of the central real issues behind the SSO problem is that existing directory services are just directory services - they have no concept of a session originating at a certain terminal or access point. Integrating "sessioning" into directory services in a way that's secure and useful to operating systems and applications is the key to doing SSO "right", where a user should only have to authenticate once when they sit down at their terminal to work on myriad systems.
This is not biology. The severe, frequent virus outbreaks that have happened in recent times were entirely, realistically, preventable. You don't have to conduct a 6.2 million dollar study into "vectors" and whatnot.
How many more incidents does it take until some major corporations start sueing Microsoft for the damages caused by their gross negligence?
Troll? Dumbass
No, it just means whoever submitted the article wasn't using "direct ancestor" in the way that most of us would have. I would imagine there's no code from CTSS directly in Linux.
You can spin this data any way you want to (assuming it is valid data - I would tend to assume that the voting population in the study was hardly randomized among all the various determinant factors). I'll provide an opposed spin (it's stupid, but no more so than any of the others) that makes the data pro-Bush:
In the current geopolitical scene, one country's financial loss is another's gain. Therefore smart people in the world would try to push for a candidate in the US who would cause the US to lose in the larger global fiscal game (not in a big de-stabilizing way that would backfire, just enough that the other countries can take advantage). Therefore the fact that people outside the US overwhelmingly favor Kerry means that they are predicting (in the market sense) that Bush would lead to a stronger US fiscal victory over the rest of the world.