One terrorist/hijacker alive though wounded
on
Our New Pearl Harbor
·
· Score: 1
A report through personal contacts is that
one hijacker is alive although wounded.
Unfortunately no further information was
available (not nationality, which flight, etc).
Based on the source, I'd give the report about
an 80% chance of being genuine.
A quick hack
(from Z)
that helps get the 4000 FLX running:
[it] works wonderfully, iff you power-up the spaceball during the ~5 second timeout of the jsattach program. Try the following to make this easier:
( while ! jsattach --sball4/dev/ttyS0 ; do : ; done ; ) &
Note that/dev/js0 was the device being used to communicate with the driver - jsattach effectively binds/dev/js0 to/dev/ttyS0.
jscal was useful, although even that didn't allow me to scale the Spaceball output to the insane levels Descent/Linux seems to expect. If Descent allowed higher sensitivity to be chosen, or the driver was a little more mature, it might work better.
In 1994/5 I was creating simple 3D objects and environments trivially in the SGI software of the time (on an SGI Onyx/RE - not too dissimilar in graphics oomph to what we have on PCs today), and viewing them at an impressive frame rate, for the time. Arguments about VRML being slow at the time are irrelevant to the long term, given that even then we knew the PC graphics market was going to be wild. Arguments that VRML was difficult have less bearing considering that SGI already had the tools to make creating early VRML scenes trivial. Even direct editing of the VRML files wasn't too mind bending, although not ideal. I was, to say the least, enthusiastic about what was to come...
Propagating a new software paradigm means that you have to spread it to as many as possible, as quickly as possible, before the initial glitz factor wears off and you have just a few early adopters looking around and thinking "oops, no one -else- is using this...".
Then VRML shifted to a standard that was much, much harder to implement. Initially involved, VRML was now unlikely to see widespread adoption within significant help being given to multiplatform projects to visualize worlds in the new standard. SGI sponsered the Cosmo project - on the surface an attempt to bring cross-architecture support for the new VRML to the market.
Cosmo, however, developed for Windows first despite the IRIX sponser, leaving SGI-based VRML enthusiasts feeling outcast (and downlevel). This disenfranchising the original userbase, now a lost source of positive proselytizing on behalf of VRML, was followed by the general failure to support -any- Unix platforms, a whole market where the VRML concept would have stood out as the only way to go, unlike the Windows market where VRML was only one of several choices.
In the end, by offering no sample implementation, and by providing no way for the hoped-for userbase to contribute back into the source tree, the future of VRML was left focused to a detrimental degree on the Cosmo project itself, limited by Cosmo's failures, and stillborn as a result.
In the beginning, there was Douglas Engelbart, and from him came the mouse, the windowed graphic user interface, hyperlinks, email, and videoconferencing -- in the 1950s and '60s, years before the Apple Lisa, Sun workstations, and other projects incited by visits to XEROX PARC in the 1970s. What most people don't know is that much considered to have happened at PARC was actually brought there by researchers from Engelbart's labs at the Stanford Research Institute (SRI).
Diehards can repeat Engelbart's opening line from memory:
"If in your office, you as an intellectual worker were supplied with a computer display backed up by a computer that was alive for you all day and was instantly responsive, how much value could you derive from that?"
Then, on a gigantic movie screen, he brought this new world alive. TV cameras switched from shots of Engelbart's hands working new contraptions called a mouse and a chord keyset, in conjunction with a standard keyboard, to shots of the computer screen where Engelbart was effortlessly adding, deleting and reorganizing a grocery shopping list. Like magic, the cursor moved words and thoughts.
The world premiere of video conferencing was a show-stopper: Talking into a director's-style headset, Engelbart punched up his colleague at SRI, 30 miles away. "Hi, Bill," said Engelbart as Bill's head filled the left corner of the screen, surrounded by text. "Now we're connected . . . let's do some collaborating." The two proceeded to work jointly on a piece of text, passing the cursor and computer controls back and forth. Engelbart and his team had invented what's now called "groupware"; 30 years later it's hard to find software that allows you to do what they did in the demo - share control of a computer screen for sophisticated collaboration.
If you can move to a 3d environment and still run all your old X and tty-based stuff, then there's no good reason -not- to adopt the new technology.
Which is precisely why X has xterm.
And why a 3D environment -must- support X. Fortunately, that's not that hard - just map it to the side of something and you're there, either through GGI, or rewriting Xnest.
I've been playing with a 3d UI for a little while; apparently a lot of us have. I'd like a lot more than just a 3d interface though. Something that brings people into the same environment, something where object have permissions so sharing doesn't have to be total, something where I can work on my house design while watching the netrek freaks blowing each other away overhead...
Here's a screenshot of a tty running in my current software, with sheep wandering below. From here I can run commands from the shell level that produce output back here in my space, like a life simulation I wrote in Perl that communicates over TCP with my Z program to produce a life grid floating a little ways back into the trees.
I got into this idea at Origin games when I ended up with a $350k SGI reality engine on my desk. Now if I just had more time...
We need a shared, networked, distributed, permission-equipped environment -- all I've seen is internal-object-only, unnetworked, undistributed, one-user, no-permission environments. Even XEROX PARC can't seem to get two applications running in one space, according the little posted on their website, at least. Don't you want the tension of trying to read your email, or do some work inside of Quake 4?...
Many neophyte web designers will download the current webpage via http, modify it in FrontPage (which produces microshaft's typical, horrible HTML anyway) and then plaster it over the original via Samba, drag-and-drop FTP, or some other mechanism.
All server-side includes, variable, macros, conditional text directives, and just about anything else interesting in the original, before-processing, dynamic HTML file is OBLITERATED. The budding webdesigner doesn't even realize anything is being lost as the original dynamic page is replaced with a static one.
I've seen this happen in several places, different users, etc. It's critical to either:
1) Make sure they're editing the original file with all the tags, includes, etc., visible, or
2) Hide everything behind a cgi-based editing/submission system so they -can't- mangle special parts, or
3) Only let them edit.html files, not.shtml files (and certainly don't let them save HTML over a CGI, but that would never happen, right?). Even then, use of microshaft tools will cause quite surprising page bloat, especially when tables are involved.
Another common problem is when symlinks are replaced with normal files in the update process (the enduser usually doesn't even know what symlinks are, and Samba doesn't show them as being different from files and directories either) This can confuse the people who knew what the symlinks were for, and worse, break scripts that depended on them.
If there really exist studies that one mouse button is less stressful than three, I'd like to see them, because in real life I've seen the reverse, especially due to the especially-streasful double-clicking required in the average, ill-thought-out, one mouse button GUI.
It's requiring multiclick that's bad, not spreading the stress out over several sets of tendons rather than one. Would you want a one-finger keyboard, too? Didn't think so.
Slashdot Mirror
A report through personal contacts is that
one hijacker is alive although wounded.
Unfortunately no further information was
available (not nationality, which flight, etc).
Based on the source, I'd give the report about
an 80% chance of being genuine.
It seems like Bush, as the head of the
administrative branch, is in no position to
give -any- orders to the judicial branch.
A quick hack (from Z) that helps get the 4000 FLX running:
Note that /dev/js0 was the device being used to communicate with the driver - jsattach effectively binds /dev/js0 to /dev/ttyS0.
jscal was useful, although even that didn't allow me to scale the Spaceball output to the insane levels Descent/Linux seems to expect. If Descent allowed higher sensitivity to be chosen, or the driver was a little more mature, it might work better.
In 1994/5 I was creating simple 3D objects and environments trivially in the SGI software of the time (on an SGI Onyx/RE - not too dissimilar in graphics oomph to what we have on PCs today), and viewing them at an impressive frame rate, for the time. Arguments about VRML being slow at the time are irrelevant to the long term, given that even then we knew the PC graphics market was going to be wild. Arguments that VRML was difficult have less bearing considering that SGI already had the tools to make creating early VRML scenes trivial. Even direct editing of the VRML files wasn't too mind bending, although not ideal. I was, to say the least, enthusiastic about what was to come...
Propagating a new software paradigm means that you have to spread it to as many as possible, as quickly as possible, before the initial glitz factor wears off and you have just a few early adopters looking around and thinking "oops, no one -else- is using this...".
Then VRML shifted to a standard that was much, much harder to implement. Initially involved, VRML was now unlikely to see widespread adoption within significant help being given to multiplatform projects to visualize worlds in the new standard. SGI sponsered the Cosmo project - on the surface an attempt to bring cross-architecture support for the new VRML to the market.
Cosmo, however, developed for Windows first despite the IRIX sponser, leaving SGI-based VRML enthusiasts feeling outcast (and downlevel). This disenfranchising the original userbase, now a lost source of positive proselytizing on behalf of VRML, was followed by the general failure to support -any- Unix platforms, a whole market where the VRML concept would have stood out as the only way to go, unlike the Windows market where VRML was only one of several choices.
In the end, by offering no sample implementation, and by providing no way for the hoped-for userbase to contribute back into the source tree, the future of VRML was left focused to a detrimental degree on the Cosmo project itself, limited by Cosmo's failures, and stillborn as a result.
But I still want VRML...
In the beginning, there was Douglas Engelbart, and from him came the mouse, the windowed graphic user interface, hyperlinks, email, and videoconferencing -- in the 1950s and '60s, years before the Apple Lisa, Sun workstations, and other projects incited by visits to XEROX PARC in the 1970s. What most people don't know is that much considered to have happened at PARC was actually brought there by researchers from Engelbart's labs at the Stanford Research Institute (SRI).
Diehards can repeat Engelbart's opening line from memory:
"If in your office, you as an intellectual worker were supplied with a computer display backed up by a computer that was alive for you all day and was instantly responsive, how much value could you derive from that?"
Then, on a gigantic movie screen, he brought this new world alive. TV cameras switched from shots of Engelbart's hands working new contraptions called a mouse and a chord keyset, in conjunction with a standard keyboard, to shots of the computer screen where Engelbart was effortlessly adding, deleting and reorganizing a grocery shopping list. Like magic, the cursor moved words and thoughts.
The world premiere of video conferencing was a show-stopper: Talking into a director's-style headset, Engelbart punched up his colleague at SRI, 30 miles away. "Hi, Bill," said Engelbart as Bill's head filled the left corner of the screen, surrounded by text. "Now we're connected . . . let's do some collaborating." The two proceeded to work jointly on a piece of text, passing the cursor and computer controls back and forth. Engelbart and his team had invented what's now called "groupware"; 30 years later it's hard to find software that allows you to do what they did in the demo - share control of a computer screen for sophisticated collaboration.
Read the full article .
If you can move to a 3d environment and still run all your old X and tty-based stuff, then there's no good reason -not- to adopt the new technology.
Which is precisely why X has xterm.
And why a 3D environment -must- support X. Fortunately, that's not that hard - just map it to the side of something and you're there, either through GGI, or rewriting Xnest.
-Alex.
I've been playing with a 3d UI for a little while; apparently a lot of us have. I'd like a lot more than just a 3d interface though. Something that brings people into the same environment, something where object have permissions so sharing doesn't have to be total, something where I can work on my house design while watching the netrek freaks blowing each other away overhead...
Here's a screenshot of a tty running in my current software, with sheep wandering below. From here I can run commands from the shell level that produce output back here in my space, like a life simulation I wrote in Perl that communicates over TCP with my Z program to produce a life grid floating a little ways back into the trees.
Oh yes, the sheep bleat when you click on them.
I got into this idea at Origin games when I ended up with a $350k SGI reality engine on my desk. Now if I just had more time...
We need a shared, networked, distributed, permission-equipped environment -- all I've seen is internal-object-only, unnetworked, undistributed, one-user, no-permission environments. Even XEROX PARC can't seem to get two applications running in one space, according the little posted on their website , at least. Don't you want the tension of trying to read your email, or do some work inside of Quake 4?...
-Alex
Many neophyte web designers will download the current webpage via http, modify it in FrontPage (which produces microshaft's typical, horrible HTML anyway) and then plaster it over the original via Samba, drag-and-drop FTP, or some other mechanism.
.html files, not .shtml files (and certainly don't let them save HTML over a CGI, but that would never happen, right?). Even then, use of microshaft tools will cause quite surprising page bloat, especially when tables are involved.
All server-side includes, variable, macros, conditional text directives, and just about anything else interesting in the original, before-processing, dynamic HTML file is OBLITERATED. The budding webdesigner doesn't even realize anything is being lost as the original dynamic page is replaced with a static one.
I've seen this happen in several places, different users, etc. It's critical to either:
1) Make sure they're editing the original file with all the tags, includes, etc., visible, or
2) Hide everything behind a cgi-based editing/submission system so they -can't- mangle special parts, or
3) Only let them edit
Another common problem is when symlinks are replaced with normal files in the update process (the enduser usually doesn't even know what symlinks are, and Samba doesn't show them as being different from files and directories either) This can confuse the people who knew what the symlinks were for, and worse, break scripts that depended on them.
Have fun....
If there really exist studies that one mouse button is less stressful than three, I'd like to see them, because in real life I've seen the reverse, especially due to the especially-streasful double-clicking required in the average, ill-thought-out, one mouse button GUI.
It's requiring multiclick that's bad, not spreading the stress out over several sets of tendons rather than one. Would you want a one-finger keyboard, too? Didn't think so.