I spent a while playing with Jabberwocky and the illusion of intelligence is sometimes spooky, so it's interesting to know that it uses interactive emergence. Thanks for writing it!
While I was studying natural language processing I read an interesting book in which Horst Hendriks-Jansen describes how, during a child's development, intelligent behaviour is built on a "scaffolding" of instinctive behaviour. For example, adults treat babies as intelligent, purposeful beings who are aware of their surroundings - we've all seen new parents interpreting baby's every burp and grimace as an attempt at conversation. In reality, most of a baby's actions are instinctive, and often unrelated to the people it's "interacting" with, but adults nevertheless feel a strong urge to respond and comment, keeping the false interaction going.
Hendriks-Jansen argues that this misunderstanding allows the child to "bootstrap" itself into genuine interactions, by learning from the intelligent responses to its semi-random behaviour. Fast forward two years and there's undoubtedly interaction, but most of the meaning is still interpreted by the adult rather than supplied by the child - "Go park" "Do you want to go to the park today?" "Ey say mf aw sheep" "Do you think we'll see sheep at the park? What noise do sheep make?"
What relevance does all this have for AI? If the "interactive emergence" theory is correct, computers will only become intelligent by learning to interact - bootstrapping themselves from semi-random actions, interpreted as meaningful, to genuinely meaningful interactions. This will only be possible if people have the patience to play with bots and teach them to interact, and since the urge doesn't seem to be as strong with bots as it is with babies, and the interaction starts with text rather than gurgles and winces, it will help if the bots have enough "instinctive" (ie hardcoded) conversational skills to encourage people to keep playing.
I'd personally be more than willing to get "stunned" by any available electrical "paralysis" garbage on the market, and I'd be willing to bet that I could close in on the stunner and clinch them while they stun me.
I advise you to get someone to look over the "Hobbies and Interests" section of your resume before you apply for any more jobs.;-)
We're consumers, the objects of our consumption need an origin, and corporations are that origin.
No, the actual producers are human beings. Corporations are just abstractions for organizing production and connecting producers to consumers - they can't actually create anything themselves, all they can do is own and manage. What are the sources of value? Labour, skill and raw materials. The first and second come from humans, the third comes from nature.
The Witty worm has shown that users of minority operating systems need to be concerned about "flash worms" - internet worms that spread faster than humans can respond, making it impossible to protect yourself simply by patching your system. Many Unix users have become complacent, believing that worm epidemics can be blamed on the poor quality of Microsoft's software, its dominant market position, or sloppy system administration. Witty has shown that these assumptions are false, and we are all at risk.
The threat to servers is fairly well understood, and network services generally run with reduced permissions and/or in chroot sandboxes to reduce the damage they can cause if infected. However, ordinary users also run network-exposed software which is vulnerable to worms. The following is a proposal for protecting personal data against worms.
Imagine that each user of a Unix system has two accounts: a "real" account and a "shadow" account. The shadow account is used for running network-exposed software. It has its own home directory for configuration files and so on, and it cannot access the user's "real" home directory. The real user has a setuid script for launching programs as the shadow user. Logins are not permitted on the shadow account.
The problem is that we want to have full access to our files even from our most exposed applications: web browsers, email clients and instant messaging programs. To make this possible we need to recognise the difference between "personal files" and "program files". This terminology may stick in the throats of Unix veterans, but the distinction is a real and important one: personal files have inherent value to the user. Program files may be vital to the operation of some program, but they can be replaced.
The value of personal files is of course invisible to the computer, but it can be seen in the way a user interacts with those files. Personal files are manually selected in the file manager or file selection dialog, while program files are opened by applications using hardcoded names or settings in some configuration file. For a large class of programs, interaction with personal files is manual while interaction with program files is automatic.
This distinction makes it possible to give sandboxed applications limited access to personal files: a sandboxed program can keep its program files inside the sandbox, and be granted access to personal files outside the sandbox when the user selects them manually. This is achieved by using a separate "open" program that runs as the real user, presents a file selection dialog to the user, and dumps the contents of the selected file to its standard output. A similar "save" program saves the contents of its standard input to a location selected by the user. These setuid programs can be called by sandboxed applications to allow "consensual" access to personal files, without allowing automatic access that might be exploited by a worm.
Example: a Unix system has one user, Andy, with two accounts: andy and andy-shadow. In andy's home directory is a setuid script belonging to andy-shadow, which simply changes to andy-shadow's home directory and executes the program named on the command line. This allows Andy to run any program in a sandbox, including a shell or file manager if the sandbox needs cleaning. In andy-shadow's home directory are two setuid programs, open and save, which are owned by andy and executable (but not writable) by andy-shadow. Sandboxed applications can call these programs to open and save files with Andy's help, but they cannot directly access his home directory. If they need to save any settings etc, they use andy-shadow's home directory.
Shadow accounts (and the corresponding setuid programs) can be created automatically for all users. T
IIRC, wm-spec-list is on gnome.org because its original focus was on getting Gnome window managers to co-operate with taskbars and pagers, handle multiple desktops in a standard way etc. KDE had a standard window manager so it wasn't an issue. Now Gnome has a standard window manager too, so the whole thing was kind of unnecessary. But i suppose the window type hints are useful to someone.:-)
last time I checked, 99.9999% of car drivers out there only know how to fill their gas and windshield cleaner tanks. But they all still own and use their cars.
...and when the car breaks down or they want to upgrade it, they go to a mechanic. The few that try to do it themselves either know what they're doing or break something pretty quickly.
Computers can and should be easy for non-experts to use, but maybe they'll never be easy for non-experts to maintain. We should stop pretending that PC maintenance can be done through a pretty point-and-click interface that requires no knowledge of computers, because that's nonsense. When things break you have to understand how they work to get them working again.
Hopefully users will get used to the idea that when they want to change something on their PC they should take it to an expert (even if that's their nearest/. reading friend or relative). To support this, desktop systems should ship with separate "user" and "maintenance" accounts. User accounts can't install software or hardware or change settings that affect other users. Maintenance accounts can change settings, but don't have access to other accounts' personal data (which makes them different from the current administrator/root accounts). As well as the main maintenance account it should be possible to generate "one-shot" accounts with more limited capabilities, so a user can feel comfortable allowing an expert to login remotely.
Of course some people will maintain their own PCs, but those who don't intend to do so shouldn't have the capabilities enabled - it leads to problems like spyware and trojans which actually make life more difficult for non-experts.
The language isn't the problem, it's the class libraries. There are no obstacles to writing a free C# or Java compiler (as long as you don't mind chasing a moving target without the source), but a language without libraries is just a toy. If all we needed was a managed language, the free software world has dozens to choose from. We also need (at least) the following libraries:
A modern GUI toolkit
File and network I/O
Decent string handling
Common data structures and algorithms, so we don't have to write 1,000 hash tables and 1,000 quicksorts
An interface to existing C libraries
The language also needs to be able to attract a large number of developers (which rules out Lisp, Scheme, OCaml etc) and needs to be suitable for large collaborative projects (which arguably rules out Perl, Python and Ruby).
Java/GTK/gcj seems to be the only thing that meets the requirements and works now.
Speaking as someone who tried to write a small window manager for Gnome and failed, I think Havoc's done an excellent job with Metacity. If you think it's too bloated you can always try hacking Gnome support into wm2. It ain't as easy as it sounds.
As well as installing the MS fonts you need to make them available to the X server and set up your applications to use them. I use the xfstt font server which listens on Unix port 7101 - I had to add the line "xset fp+ unix/:7101" to my ~/.xsession file to get the X server to use xfstt. If you can't see ttf fonts in the font selection dropdowns in Mozilla, something's wrong with your font server setup.
The key here is that, as other people have pointed out, having and MDI means the program with the MDI has to reimplement it's own window handling (I always hated that about MDI apps in windows - their window hanling inside the MDI sucked), which is stupid when you have window managers to handle that sort of thing - what ought to be happening (instead of forcing applications to write their own MDI) is for window managers to be taking on enough functionality to make MDI like behaviour trivial for a user to arrange.
AFAIK it's possible for the window manager to manage windows that aren't children of the root window, it's just never been done. Normally the window manager sets the substructure redirect mask on the root window, telling the X server to send certain events pertaining to children of the root window via the window manager instead of straight to the client. The window manager monitors these events to find out when clients attempt to map new windows, raise or lower existing windows, etc. If a client sets the redirect override hint on a window, the X server won't redirect the window's events to the window manager and the window won't be managed.
It might be possible for the window manager to set the substructure redirect mask on the MDI "big grey background" window in order to manage its children (the MDI document and toolbox windows). The toolkit would have to check for a compatible window manager and be prepared to fall back on its own decorations. If a compatible window manager was found, the toolkit would set a hint on the MDI background window to indicate that its children should be managed by the window manager.
I thought the same thing about Linux font rendering until I installed Microsoft's core fonts and a TrueType font server on my Linux box (apt-get install msttcorefonts xfsttright now if you're running Debian). The font rendering in Linux is absolutely fine, it's just the shortage of good manually-hinted fonts that makes things look awful. Anti-aliasing is not the solution - GTK+1.2 looks better than GTK+2 with decent fonts installed, because the fonts have nice sharp outlines.
Re:As soon as I figure what this things does....
on
GTK 2.4.0 Released
·
· Score: 2, Informative
Even better, run debfoster occasionally. Debfoster asks you what packages you want to keep and then removes all packages (including libs) that are not required by the programs you've decided to keep.
I thought games were written to train us for a future war against aliens, demons, Nazis, Russians, terrorists, counter-terrorists and multi-coloured falling blocks?
I guess the Digital Revolution In Music we've been hearing about for so long is finally starting to arrive. What would kids who saw the birth of rock'n'roll make of it? In the 50s you had to physically travel to the record shop, listen to the latest releases in a booth, and buy them on little 7" plastic discs if you wanted to take them home. How things have changed! Nowadays you can just go down to Starbuck's, listen to the latest releases on your headphones, and buy them on little 5" plastic discs if you want to take them home. And for 3 quid you can buy a cup of coffee as well! Somebody grab my arm, the pace of social change is making me dizzy.
linux is a kernel, not a distro. the linux kernel is what "linux is supposed to look like" to linus.
Damn right. Real hackers don't need a GUI, a shell, file utilities or even a C library. Real hackers just need a system call interface. malloc() is for end users - real hackers use brk().
Of course if it wasn't for all those pesky users cluttering up our systems we could write directly to the hardware. Damn protected memory nanny state.
At speeds of 4 GHz, 32-bit CPUs are approaching the theoretical limit of their performance. A 32-bit register can only store values up to 4,294,967,296, so if a 5 GHz CPU ever realizes how fast it's running, it'll overflow and crash. The only solution is to keep the CPU so busy with other tasks that it never has time to think about how fast it's doing them. But with a 5 GHz CPU that's no easy task. One solution would be to replace the system idle process with some job that computers have historically found difficult, such as finding hash collisions or factoring large prime numbers.
Of course, this applies only to integer speeds. Floating point calculations can get a lot faster - up to 3,400,000,000,000,000,000,000,000,000,000 GHz for single-precision floats, and much higher for doubles. Perhaps future 32-bit processors will be forced to emulate integer arithmetic using floating-point registers?
Your question is answered in the Parrot FAQ. Sun's JVM isn't free software, there's no other JVM out there that compiles on as many platforms as Perl 5, and all JVMs as well as the CLR use a stack architecture, whereas Parrot uses a register architecture which appears to be much more suitable for Perl (ie faster).
OK it's just an expensive toy, but if somebody doesn't buy this robot they'll never build a better one. Remember cellular phones in the early 90s? Absurdly bulky, expensive and almost useless - who on earth bought them? Luckily for us there's an early adopter born every minute, so now we have tiny, cheap phones with batteries that last all week. Hopefully the same will be true of humanoid robots in ten years (except for the 'tiny' part - they'll have to be at least child-size to be able to cope with doors and stairs).
Slashdot Mirror
I spent a while playing with Jabberwocky and the illusion of intelligence is sometimes spooky, so it's interesting to know that it uses interactive emergence. Thanks for writing it!
Hendriks-Jansen argues that this misunderstanding allows the child to "bootstrap" itself into genuine interactions, by learning from the intelligent responses to its semi-random behaviour. Fast forward two years and there's undoubtedly interaction, but most of the meaning is still interpreted by the adult rather than supplied by the child - "Go park" "Do you want to go to the park today?" "Ey say mf aw sheep" "Do you think we'll see sheep at the park? What noise do sheep make?"
What relevance does all this have for AI? If the "interactive emergence" theory is correct, computers will only become intelligent by learning to interact - bootstrapping themselves from semi-random actions, interpreted as meaningful, to genuinely meaningful interactions. This will only be possible if people have the patience to play with bots and teach them to interact, and since the urge doesn't seem to be as strong with bots as it is with babies, and the interaction starts with text rather than gurgles and winces, it will help if the bots have enough "instinctive" (ie hardcoded) conversational skills to encourage people to keep playing.
Funny, I have the same bindings in my .twmrc. ;-)
I advise you to get someone to look over the "Hobbies and Interests" section of your resume before you apply for any more jobs. ;-)
No, the actual producers are human beings. Corporations are just abstractions for organizing production and connecting producers to consumers - they can't actually create anything themselves, all they can do is own and manage. What are the sources of value? Labour, skill and raw materials. The first and second come from humans, the third comes from nature.
I use vi you insensitive clod!
The Witty worm has shown that users of minority operating systems need to be concerned about "flash worms" - internet worms that spread faster than humans can respond, making it impossible to protect yourself simply by patching your system. Many Unix users have become complacent, believing that worm epidemics can be blamed on the poor quality of Microsoft's software, its dominant market position, or sloppy system administration. Witty has shown that these assumptions are false, and we are all at risk.
The threat to servers is fairly well understood, and network services generally run with reduced permissions and/or in chroot sandboxes to reduce the damage they can cause if infected. However, ordinary users also run network-exposed software which is vulnerable to worms. The following is a proposal for protecting personal data against worms.
Imagine that each user of a Unix system has two accounts: a "real" account and a "shadow" account. The shadow account is used for running network-exposed software. It has its own home directory for configuration files and so on, and it cannot access the user's "real" home directory. The real user has a setuid script for launching programs as the shadow user. Logins are not permitted on the shadow account.
The problem is that we want to have full access to our files even from our most exposed applications: web browsers, email clients and instant messaging programs. To make this possible we need to recognise the difference between "personal files" and "program files". This terminology may stick in the throats of Unix veterans, but the distinction is a real and important one: personal files have inherent value to the user. Program files may be vital to the operation of some program, but they can be replaced.
The value of personal files is of course invisible to the computer, but it can be seen in the way a user interacts with those files. Personal files are manually selected in the file manager or file selection dialog, while program files are opened by applications using hardcoded names or settings in some configuration file. For a large class of programs, interaction with personal files is manual while interaction with program files is automatic.
This distinction makes it possible to give sandboxed applications limited access to personal files: a sandboxed program can keep its program files inside the sandbox, and be granted access to personal files outside the sandbox when the user selects them manually. This is achieved by using a separate "open" program that runs as the real user, presents a file selection dialog to the user, and dumps the contents of the selected file to its standard output. A similar "save" program saves the contents of its standard input to a location selected by the user. These setuid programs can be called by sandboxed applications to allow "consensual" access to personal files, without allowing automatic access that might be exploited by a worm.
Example: a Unix system has one user, Andy, with two accounts: andy and andy-shadow. In andy's home directory is a setuid script belonging to andy-shadow, which simply changes to andy-shadow's home directory and executes the program named on the command line. This allows Andy to run any program in a sandbox, including a shell or file manager if the sandbox needs cleaning. In andy-shadow's home directory are two setuid programs, open and save, which are owned by andy and executable (but not writable) by andy-shadow. Sandboxed applications can call these programs to open and save files with Andy's help, but they cannot directly access his home directory. If they need to save any settings etc, they use andy-shadow's home directory.
Shadow accounts (and the corresponding setuid programs) can be created automatically for all users. T
I think they'll be surprised how many Slashdot readers live in zip code 10101 and are 101 years old.
IIRC, wm-spec-list is on gnome.org because its original focus was on getting Gnome window managers to co-operate with taskbars and pagers, handle multiple desktops in a standard way etc. KDE had a standard window manager so it wasn't an issue. Now Gnome has a standard window manager too, so the whole thing was kind of unnecessary. But i suppose the window type hints are useful to someone. :-)
Computers can and should be easy for non-experts to use, but maybe they'll never be easy for non-experts to maintain. We should stop pretending that PC maintenance can be done through a pretty point-and-click interface that requires no knowledge of computers, because that's nonsense. When things break you have to understand how they work to get them working again.
Hopefully users will get used to the idea that when they want to change something on their PC they should take it to an expert (even if that's their nearest /. reading friend or relative). To support this, desktop systems should ship with separate "user" and "maintenance" accounts. User accounts can't install software or hardware or change settings that affect other users. Maintenance accounts can change settings, but don't have access to other accounts' personal data (which makes them different from the current administrator/root accounts). As well as the main maintenance account it should be possible to generate "one-shot" accounts with more limited capabilities, so a user can feel comfortable allowing an expert to login remotely.
Of course some people will maintain their own PCs, but those who don't intend to do so shouldn't have the capabilities enabled - it leads to problems like spyware and trojans which actually make life more difficult for non-experts.
- A modern GUI toolkit
- File and network I/O
- Decent string handling
- Common data structures and algorithms, so we don't have to write 1,000 hash tables and 1,000 quicksorts
- An interface to existing C libraries
The language also needs to be able to attract a large number of developers (which rules out Lisp, Scheme, OCaml etc) and needs to be suitable for large collaborative projects (which arguably rules out Perl, Python and Ruby).Java/GTK/gcj seems to be the only thing that meets the requirements and works now.
Speaking as someone who tried to write a small window manager for Gnome and failed, I think Havoc's done an excellent job with Metacity. If you think it's too bloated you can always try hacking Gnome support into wm2. It ain't as easy as it sounds.
As well as installing the MS fonts you need to make them available to the X server and set up your applications to use them. I use the xfstt font server which listens on Unix port 7101 - I had to add the line "xset fp+ unix/:7101" to my ~/.xsession file to get the X server to use xfstt. If you can't see ttf fonts in the font selection dropdowns in Mozilla, something's wrong with your font server setup.
:-/
My Mozilla fonts are set up as follows:
font.FreeType2.autohinted: false
font.FreeType2.enable: true
font.name.monospace.x-western: ttf-courier new-iso8859-1
font.name.sans-serif.x-western: ttf-arial-iso8859-1
font.name.serif.x-western: ttf-times new roman-iso8859-1
Everything looks just like it does in Windows. I agree about sub-pixel rendering though.
AFAIK it's possible for the window manager to manage windows that aren't children of the root window, it's just never been done. Normally the window manager sets the substructure redirect mask on the root window, telling the X server to send certain events pertaining to children of the root window via the window manager instead of straight to the client. The window manager monitors these events to find out when clients attempt to map new windows, raise or lower existing windows, etc. If a client sets the redirect override hint on a window, the X server won't redirect the window's events to the window manager and the window won't be managed.
It might be possible for the window manager to set the substructure redirect mask on the MDI "big grey background" window in order to manage its children (the MDI document and toolbox windows). The toolkit would have to check for a compatible window manager and be prepared to fall back on its own decorations. If a compatible window manager was found, the toolkit would set a hint on the MDI background window to indicate that its children should be managed by the window manager.
I thought the same thing about Linux font rendering until I installed Microsoft's core fonts and a TrueType font server on my Linux box (apt-get install msttcorefonts xfstt right now if you're running Debian). The font rendering in Linux is absolutely fine, it's just the shortage of good manually-hinted fonts that makes things look awful. Anti-aliasing is not the solution - GTK+1.2 looks better than GTK+2 with decent fonts installed, because the fonts have nice sharp outlines.
Even better, run debfoster occasionally. Debfoster asks you what packages you want to keep and then removes all packages (including libs) that are not required by the programs you've decided to keep.
I thought games were written to train us for a future war against aliens, demons, Nazis, Russians, terrorists, counter-terrorists and multi-coloured falling blocks?
I guess the Digital Revolution In Music we've been hearing about for so long is finally starting to arrive. What would kids who saw the birth of rock'n'roll make of it? In the 50s you had to physically travel to the record shop, listen to the latest releases in a booth, and buy them on little 7" plastic discs if you wanted to take them home. How things have changed! Nowadays you can just go down to Starbuck's, listen to the latest releases on your headphones, and buy them on little 5" plastic discs if you want to take them home. And for 3 quid you can buy a cup of coffee as well! Somebody grab my arm, the pace of social change is making me dizzy.
Damn right. Real hackers don't need a GUI, a shell, file utilities or even a C library. Real hackers just need a system call interface. malloc() is for end users - real hackers use brk().
Of course if it wasn't for all those pesky users cluttering up our systems we could write directly to the hardware. Damn protected memory nanny state.
Of course, this applies only to integer speeds. Floating point calculations can get a lot faster - up to 3,400,000,000,000,000,000,000,000,000,000 GHz for single-precision floats, and much higher for doubles. Perhaps future 32-bit processors will be forced to emulate integer arithmetic using floating-point registers?
Your question is answered in the Parrot FAQ. Sun's JVM isn't free software, there's no other JVM out there that compiles on as many platforms as Perl 5, and all JVMs as well as the CLR use a stack architecture, whereas Parrot uses a register architecture which appears to be much more suitable for Perl (ie faster).
OK it's just an expensive toy, but if somebody doesn't buy this robot they'll never build a better one. Remember cellular phones in the early 90s? Absurdly bulky, expensive and almost useless - who on earth bought them? Luckily for us there's an early adopter born every minute, so now we have tiny, cheap phones with batteries that last all week. Hopefully the same will be true of humanoid robots in ten years (except for the 'tiny' part - they'll have to be at least child-size to be able to cope with doors and stairs).
It's been a while since I watched any anime but I believe it's "ROBOTO! RAITO CUROSSO!". HTH.
Maybe the grandparent meant "approaching" in the sense that it's below 70 and rising. ;-)
Will it still work if I don't believe in it? What about if I half-heartedly believe in it for want of a better explanation? ;-)