If you're not running Web 2.1, you might as well go back to the bad old days when people actually used client software for email and instant messaging. 2.1 is the only way of doing stuff online.
There are still a few people using the UberMUD code to muck around with - it's great for hacking up simple multi-user persistent systems. And a heavily modified UberMUD server is used as the engine for The Land Of Drogon - http://www.drogon.net/tlod/
No good - it relies on being able to define each combinator as a procedure in the global namespace. This provides no support for anonymous lamba expressions.
Any sufficiently large C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. - Philip Greenspun
Anyone who wants to claim Tcl is as clean and beautiful as LISP should demonstrate a better Tcl implementation of this:
http://www.backroom.uklinux.net/lambda.tcl.txt As far as I'm concerned, Tcl is great as a basic scripting language, but it isn't on a par with Python or Ruby for anything involving complicated data manipulation.
Thanks, maggard, for suggesting the only truly sensible way of running this sort of service. I've always wondered why this sort of thing hasn't been implemented properly for web-page annotation. It seems like the Right Way to do this sort of thing.
The GPS system would have exactly the same problems as the web annotation systems: signal-to-noise ratio, how to trust authors, and how to avoid suing the wrong people for libellous comments. In fact, the two systems could be considered exactly the same: web-sites are just virtual locations; the URL is the virtual equivalent of lon/lat co-ordinates.
So all it needs is for someone to design an open protocol for annotating 'locations'. Anyone can set up a set of servers to store annotations, and users can get the annotations from whichever servers they want. Then we'd have a good chance to test and perfect the technology on web-sites before the GPS/phone technology becomes viable.
For Pete's sake! Don't read the articles if you aren't interested in them. It's not that difficult. Am I missing something here? All you need to do is NOT click on the 'Read More...' link. You just go 'Oh look, an article about 2.5.1. I won't bother reading that.' Then you move on.
I agree - disdainful comments about MP3/Ogg being lossy are quite amusing when you consider that the whole hi-fi process is lossy. There's no way a stereo recording is going to recreate the sound of an original performance. If you're serious about the listening to something with perfect quality, go to a live performance.
Other than that, anyone who claims that a high quality lossy-encoding is (by definition) inferior to the 'original' sample is just missing the point.
I'm not sure whether to endorse your comment about not using headphones, or disagree entirely.
I only heard a difference between various MP3 encoding rates when I listened thru headphones. Now that I know what to listen for, I can hear the difference through speakers.
So if I'd never listened through headphones, I wouldn't know what I was missing. On the other hand, I now need to go through and re-encode all the stuff that I did beforehand. But that's ok, cos I'm Ogging everything this time. Why? Because it sounds good enough to me and I'm a sucker for this whole freedom thing...
Re:ok, make your case objectively?
on
VIM 6.0 is Out
·
· Score: 1
> What does vi do that emacs doesn't?
That's a silly question: emacs can emulate vi fairly completely, and if your favourite vi clone does something that viper-mode doesn't, you can certainly program emacs to do it.
The only other vi can do is use all but the last row of the terminal window for editing text. Not really a significant difference.
However, vi DOES load faster, and I reckon the vi keyboard layout allows a proficient user to edit text faster. That's why I use vi for quick edits and Emacs for programming. I think a lot of other people do the same.
What used to be the first version number, which was 1,
has been discarded since it does not seem that I need three
levels of version number.
Trying to argue about whether this means that Emacs is at version 20 or version 1.20 is a bit pointless really. But then so is arguing about whether Emacs is better than vi, elvis or vim. Or vice versa. Or posting to slashdot at all, in fact...
I think you can allow Hollywood _some_ poetic license -- after all a story about a comet passing 3,000 million miles from Earth wouldn't be particularly exciting. Nor would a movie about scientists discovering a huge UFO popping into the solar system, orbiting Mars a couple of times then buggering off, nuking the surface of Uranus on the way home.
Re:Alter the applications when changing the keys!
on
Pyramid Shaped Keyboard
·
· Score: 2, Funny
Using vi is tremendous fun on a Dvorak layout - especially if you prefer using hjkl to move the cursor instead of the cursor keys. I'd deleted half of a document before I figured out what was going wrong.
Predicting the weather for more than a month in advance isn't a matter of computing power. You could build a planet-sized computer and still not be able to predict whether it's going to rain in 30 days time.
The problem is not how well you process all the data: it's a question of finding all those bloody butterflies and stopping them from flapping their wings.
Yes - all they'd need would be a portable computer running MovieOS and a satellite uplink, and they'd instantly have control over every plane in the sky.
Show a little imagination guys. It's going to happen eventually - and hopefully the people who design will be readers of comp.risks. They will think of things like authentication, single-point of failure, and provide a system where the pilot, copilot or autopilot can countermand instructions from ATC.
The thing that I was most amazed at was how much he invented before he had a chance to play with a proper computer. It almost seems as if nothing interesting has happened in the last 50 years compared with what he (and his colleagues) worked out.
He was talking about programming language compilers, artificial intelligence, computability, emulation and filing systems, mostly before the first stored-program computer was built. Makes you feel that as soon as you've got a computer to play with, you spend all your time playing with it.
At the moment, each of the demo applications allows you to pop up a dialog box that lets you control the display of the app's window: you can change its transparency and colour, rotate and scale it.
My understanding of Berlin is that the contents of the display are represented as a hierarchy; controls are children of windows, which are children of the top-level desktop. Presumably global scale settings would be achieved by having a control node sitting at the highest level, which would allow you to rotate and zoom the entire display contents.
Berlin is still in development - now is the time to make sure that it DOES provide the things that it SHOULD...
No, you've missed the point: you don't have a fixed-pixel width app on a resolution-independent display. If you have an app that is filling the 640x480 screen, you just 'zoom out' the display until you can fit four of them on the screen. Sure, the quality will be shoddy, but then why are you running in 640x480 in the first place if your computer can do 1280x1024?
With resolution-independence, changing screen resolution just leaves you with a higher-resolution display (ie. more detail), NOT a bigger desktop. If you want a larger desktop area (ie. smaller windows, smaller fonts), just scale everything down.
In the case of the paint application, one would hope that the application itself will provide a zoom facility anyway! The GUI should allow the application to find out what the current pixel-size is, if it really has to.
Thank you very much for deciding that for me. Maybe I want to free up screen real estate by switching to a higher resolution. Maybe I want all those annoying little dialog boxes to shrink so I have more room for that big image window, which I can resize and zoom in/out just fine without your help, but now you've scaled them right back up so they're in the way again.
That's just the point: you shouldn't have to switch to a higher resolution to shrink the dialog boxes. If you want the dialog boxes to be smaller, the GUI should give you an option to do this without increasing the screen resolution. Similar, you should be able to make text appear larger without dropping to 800x600.
Think of how Windows lets you choose between 'Large fonts' and 'Small fonts', then pretend that they got it right so you don't have to reboot the computer whenever you switch, and you'll get the rough idea.
How about:
Virus infects IIS machine, makes that machine download and install the linux distro. Then it installs Apache, copies all the IIS files over, and makes a copy of the distro available too. Finally, it starts sending out copies of the virus. Any newly infected machines can get a copy of the distro from their 'parent'.
If the 'good worm' worked by waiting for connections from infected machines, AND it cleared up all traces afterwards (other than a note to the sysadmin to explain what had happened), AND you launched it from a machine running W2K+unpatched IIS, then it would be very difficult for anyone to prove that YOU were the instigator. As far as anyone could tell, your machine had been infected by the 'good worm', which started sending copies of itself to other machines.
Not true. The difference between countervirus and virus is that the former closes up any loop-holes that can be used for further attacks. Sure, the cracker could reverse-engineer the countervirus and set off a new-variant virus to combat it, but by the time the new virus gets active, the size of the battle field will have decreased.
Unless the initial virus leaves behind a back-door that the writer of the counter-virus didn't see, or the virus can mutate in such a way that it isn't destroyed by the counter-virus.
Slashdot Mirror
Bah! Web 2.0 is so outmoded.
If you're not running Web 2.1, you might as well go back to the bad old days when people actually used client software for email and instant messaging. 2.1 is the only way of doing stuff online.
You can get a demo of what's on offer here: http://cheese.blartwendo.com/web21-demo.html
Meanwhile, supporters will be pleased to hear about the imminent release of the long awaited Web 2.1 offshoot, Azotaemia 2.1.
There are still a few people using the UberMUD code to muck around with - it's great for hacking up simple multi-user persistent systems. And a heavily modified UberMUD server is used as the engine for The Land Of Drogon - http://www.drogon.net/tlod/
No good - it relies on being able to define each combinator as a procedure in the global namespace. This provides no support for anonymous lamba expressions.
Any sufficiently large C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. - Philip Greenspun
Anyone who wants to claim Tcl is as clean and beautiful as LISP should demonstrate a better Tcl implementation of this:
http://www.backroom.uklinux.net/lambda.tcl.txt
As far as I'm concerned, Tcl is great as a basic scripting language, but it isn't on a par with Python or Ruby for anything involving complicated data manipulation.
Thanks, maggard, for suggesting the only truly sensible way of running this sort of service. I've always wondered why this sort of thing hasn't been implemented properly for web-page annotation. It seems like the Right Way to do this sort of thing.
The GPS system would have exactly the same problems as the web annotation systems: signal-to-noise ratio, how to trust authors, and how to avoid suing the wrong people for libellous comments. In fact, the two systems could be considered exactly the same: web-sites are just virtual locations; the URL is the virtual equivalent of lon/lat co-ordinates.
So all it needs is for someone to design an open protocol for annotating 'locations'. Anyone can set up a set of servers to store annotations, and users can get the annotations from whichever servers they want. Then we'd have a good chance to test and perfect the technology on web-sites before the GPS/phone technology becomes viable.
Hasn't anyone tried doing this yet?
Do Russians stick their license plates on top of the cars in 61cm-high lettering?
For Pete's sake! Don't read the articles if you aren't interested in them. It's not that difficult. Am I missing something here? All you need to do is NOT click on the 'Read More...' link. You just go 'Oh look, an article about 2.5.1. I won't bother reading that.' Then you move on.
That's the best bit of moderation I've seen for ages.
I agree - disdainful comments about MP3/Ogg being lossy are quite amusing when you consider that the whole hi-fi process is lossy. There's no way a stereo recording is going to recreate the sound of an original performance. If you're serious about the listening to something with perfect quality, go to a live performance.
Other than that, anyone who claims that a high quality lossy-encoding is (by definition) inferior to the 'original' sample is just missing the point.
I'm not sure whether to endorse your comment about not using headphones, or disagree entirely.
I only heard a difference between various MP3 encoding rates when I listened thru headphones. Now that I know what to listen for, I can hear the difference through speakers.
So if I'd never listened through headphones, I wouldn't know what I was missing. On the other hand, I now need to go through and re-encode all the stuff that I did beforehand. But that's ok, cos I'm Ogging everything this time. Why? Because it sounds good enough to me and I'm a sucker for this whole freedom thing...
> What does vi do that emacs doesn't?
That's a silly question: emacs can emulate vi fairly completely, and if your favourite vi clone does something that viper-mode doesn't, you can certainly program emacs to do it.
The only other vi can do is use all but the last row of the terminal window for editing text. Not really a significant difference.
However, vi DOES load faster, and I reckon the vi keyboard layout allows a proficient user to edit text faster. That's why I use vi for quick edits and Emacs for programming. I think a lot of other people do the same.
From Emacs' OOOOONEWS:
Changes in Emacs 13
* There is a new version numbering scheme.
What used to be the first version number, which was 1,
has been discarded since it does not seem that I need three
levels of version number.
Trying to argue about whether this means that Emacs is at version 20 or version 1.20 is a bit pointless really. But then so is arguing about whether Emacs is better than vi, elvis or vim. Or vice versa. Or posting to slashdot at all, in fact...
I think you can allow Hollywood _some_ poetic license -- after all a story about a comet passing 3,000 million miles from Earth wouldn't be particularly exciting. Nor would a movie about scientists discovering a huge UFO popping into the solar system, orbiting Mars a couple of times then buggering off, nuking the surface of Uranus on the way home.
Using vi is tremendous fun on a Dvorak layout - especially if you prefer using hjkl to move the cursor instead of the cursor keys. I'd deleted half of a document before I figured out what was going wrong.
Predicting the weather for more than a month in advance isn't a matter of computing power. You could build a planet-sized computer and still not be able to predict whether it's going to rain in 30 days time.
The problem is not how well you process all the data: it's a question of finding all those bloody butterflies and stopping them from flapping their wings.
Yes - all they'd need would be a portable computer running MovieOS and a satellite uplink, and they'd instantly have control over every plane in the sky.
Show a little imagination guys. It's going to happen eventually - and hopefully the people who design will be readers of comp.risks. They will think of things like authentication, single-point of failure, and provide a system where the pilot, copilot or autopilot can countermand instructions from ATC.
The thing that I was most amazed at was how much he invented before he had a chance to play with a proper computer. It almost seems as if nothing interesting has happened in the last 50 years compared with what he (and his colleagues) worked out.
He was talking about programming language compilers, artificial intelligence, computability, emulation and filing systems, mostly before the first stored-program computer was built. Makes you feel that as soon as you've got a computer to play with, you spend all your time playing with it.
At the moment, each of the demo applications allows you to pop up a dialog box that lets you control the display of the app's window: you can change its transparency and colour, rotate and scale it.
My understanding of Berlin is that the contents of the display are represented as a hierarchy; controls are children of windows, which are children of the top-level desktop. Presumably global scale settings would be achieved by having a control node sitting at the highest level, which would allow you to rotate and zoom the entire display contents.
Berlin is still in development - now is the time to make sure that it DOES provide the things that it SHOULD...
No, you've missed the point: you don't have a fixed-pixel width app on a resolution-independent display. If you have an app that is filling the 640x480 screen, you just 'zoom out' the display until you can fit four of them on the screen. Sure, the quality will be shoddy, but then why are you running in 640x480 in the first place if your computer can do 1280x1024?
With resolution-independence, changing screen resolution just leaves you with a higher-resolution display (ie. more detail), NOT a bigger desktop. If you want a larger desktop area (ie. smaller windows, smaller fonts), just scale everything down.
In the case of the paint application, one would hope that the application itself will provide a zoom facility anyway! The GUI should allow the application to find out what the current pixel-size is, if it really has to.
Yeah, Apple must have got fed up with them waiting to finish Berlin and decided to do it themselves.
That's just the point: you shouldn't have to switch to a higher resolution to shrink the dialog boxes. If you want the dialog boxes to be smaller, the GUI should give you an option to do this without increasing the screen resolution. Similar, you should be able to make text appear larger without dropping to 800x600.
Think of how Windows lets you choose between 'Large fonts' and 'Small fonts', then pretend that they got it right so you don't have to reboot the computer whenever you switch, and you'll get the rough idea.
How about: Virus infects IIS machine, makes that machine download and install the linux distro. Then it installs Apache, copies all the IIS files over, and makes a copy of the distro available too. Finally, it starts sending out copies of the virus. Any newly infected machines can get a copy of the distro from their 'parent'.
If the 'good worm' worked by waiting for connections from infected machines, AND it cleared up all traces afterwards (other than a note to the sysadmin to explain what had happened), AND you launched it from a machine running W2K+unpatched IIS, then it would be very difficult for anyone to prove that YOU were the instigator. As far as anyone could tell, your machine had been infected by the 'good worm', which started sending copies of itself to other machines.
Unless the initial virus leaves behind a back-door that the writer of the counter-virus didn't see, or the virus can mutate in such a way that it isn't destroyed by the counter-virus.