This is vaguely reminiscient of the old Unix maxim, "Everything is either a file or a process," except that now KDE calls everything an URL.
Correct me if I'm wrong, but wouldn't the old way of doing this be something like/dev/extensions/audiocd/track1,/dev/extensions/sftp/,/dev/extensions/webdav, and so on? This type of a trick would have allowed these extensions to be used in any app that recognizes the file system, not only KDE type apps.
What was the reason for not implementing these as devices?
I have read dozens of angry replies where people complain that the author should have learned "man", or "google", or read documentation, or known about "apt-get", or so on. I've read very few replies that advocate taking anything the author says seriously.
If this were a usability research study, the user's behavior - no matter how unusual - would be reviewed. Even if the user flails about helplessly, the goal of the study would be to identify ways to steer the user back onto the right track.
I certainly hope someone, somewhere, is reading this user's article (I certainly can't get to it) and wondering, "How can we tune our software so that it helps to steer users towards things such as man, google, and apt-get?"
As a CPU buff, I ordered a back-issue of Microprocessor Report where they discussed the introduction of the Alpha in glowing terms. The radical chip architecture and speed-at-any-price mentality was new at the time, but quickly proved itself to be the superior chip design approach. For most of the 1990s, the Alpha was the fastest chip on the market in both integer and floating point operations.
Alpha was a Risc chip's risc chip. The IBM Power architecture has dozens of operations and permutations; the Alpha has a handful. This contributed not only to the Alpha's speed, but also to its insatiable demands for memory. DEC introduced a code-translator that allowed the Alpha to run x86-32 binaries at native speeds, but warned that memory requirements would grow substantially. The software never became cost effective.
But, towards the turn of the millennium, something strange happened: the Pentium Pro architecture (happily renamed PII and PIII) inched towards the lead in integer operations. The P4 actually surpassed the Alpha chips. Intel had, by then, hired away some of the Alpha designers and began to adopt its performance enhancing strategies. How could Intel catch up to the Alpha when Intel was burdened with an architecture as convoluted as x86?
Strangely, the x86 architecture can also be a benefit to chip design. Because x86 compresses commonly used instructions into tiny, awkward byte codes, the P4 generation of chips requires less memory and fewer cache misses - and the convoluted opcodes can be decoded quickly by the processor prior to dispatch. In the long run, Alpha's simplified instruction set proved to be less useful than machine-code x86 compatibility; and x86 chips are now little more than Alpha chips sitting behind an x86 instruction decoder. The Alpha design lives on in every CPU you buy, whether it be AMD or Intel.
Sexy as hell? Looks more like a demented Robby the Robot from the old Nintendo Entertainment System. This is one of the foulest examples of product design since... since... I'm not sure; there are so many to choose from.
As long as we're talking about nVidia, does anyone have access to a long term performance graph of old nVidia cards? Rating them from generation to generation to how much improvement there was in each era.
I tried googling for it, but the keywords are just too popular, and everyone is google spamming and bombing and such. Don't even bother trying to search on Yahoo.
I used to have a good chart that showed dollars-per-FPS, but it's totally lost now.
I was going to make a joke about how Sun is still calling it the Java Development Kit release 1.1 for Java 2.0 version 5.0, but this has been frequently noticed by others in this thread. So for those who are not interested in sorting through the bewildering list of packages available on the Java Download page, here's an ugly ascii kitty cat.
So far we have a roughly even ratio of comments: (3) comments for Dr. Evil's Laser Weapon (shark or moon based), and (3) comments for a 5 Megawatt Laser Ready By Mid-May.
And as long as you're reading this, let me compliment you on your fantastic bunny slippers.
Well, I built my system from default SuSE 9.0, which has KDE logos emblazoned everywhere on the screen. It uses Konqueror, which I imagine is either KDE-oriented or by default part of KDE itself. Please forgive me if I in my ignorance cause confusion.
Actually, SuSE 9.0. It runs with Konqueror configured as its desktop environment. I hunted through the SuSE configuration settings app, and I didn't find anything related to double-click behavior. I searched for something similar to the normal menus in Windows (Tools | Folder Options), but I didn't find much progress. After a while, I started searching through help on Konqueror, and I found a help file that said "Single-clicks activate everything - they jump to links, open files, etc," so I presumed that meant that somebody had standardized on single-click-launch.
Is it maybe Konqueror that does this rather than KDE?
Re:Apple saw this problem during the 90s
on
The Paradox of Choice
·
· Score: 5, Insightful
On the other hand, Apple's software philosophy is to have only one way to do something, and to have that work well and be obvious. Check out the Macintosh Human Interface Design documents.
Even more importantly, this philosophy extended to the Macintosh API. Even Microsoft moved in this direction. Bill Gates once said, "Why should everyone in the world have to write a File-Open dialog?" The Microsoft Common Controls API was the best thing that happened to Win16 programmers back in the early '90s.
Yet, after a few years, Microsoft started putting together OLE, DDE, ActiveX, and a bunch more stuff - there were tons of choices. Consider Microsoft's media player: there was a text-based API, a procedure call API, and an object oriented API. Microsoft programming has been getting harder, thus they introduce.NET and standardize everything again.
I'm all for choice when it works. For example, KDE offers you tons of choices; by default there's this multiple-virtual-desktop thing with all sorts of options and shortcut keys and soforth. But the one choice I want - the ability to stop files and folders on my local harddrive from acting like hyperlinks - isn't available. I suppose that, given a few months of practice, I could get used to treating my hard drive like a website, but it isn't working out for me at the moment.
I dunno if I have a real point here. But I think Extreme Programming has at least one useful idea: customer stories. Try writing down all the things a user wants to do - "Map a Network Drive", "Change double-click behavior", "Organize My Documents" - and then put together an obvious way for the user to do it, or (if it's too hard to make it obvious) at least a straightforward help page that explains the task.
As I recall, the US Army was suffering from a shortage of bugle players to play taps for the passing generation of soldiers. They developed a digital bugle that can play taps even if the bugler is incompetent, drunk, or both.
Since Toyota has now developed a vastly more complicated technology that can be used to solve the same problem as the slightly complicated one above, I look forward to future Pentagon procurement hearings.
Note to self: Sarcasm in this post often results in massive retribution.
Churchill, when declaring war on Japan in 1941 after Pearl Harbor, sent a letter to Hirohito in which he informed the Japanese emperor that a state of war existed between Britain and Japan.
He signed it, "Your humble servant", and commented, "After all, when you have to kill a man, it costs nothing to be nice." See his WW2 memoirs.
The Hubble Telescope is old. It has produced some spectacular images, and it has now exceeded its productive life. It needs significant repairs and a costly shuttle mission to stay afloat. Its mirrors, although fixed in a dramatic spacewalk, are no longer state of the art.
This seems pretty pessimistic. Remember, we manage to add new features to the Internet continually.
Think of HTML email, for example. In the beginning, very few people supported it. Back in 1995, AOL rejected messages with HTML content. Gradually HTML has become more accepted, and nowadays it's pretty commonplace.
I imagine this kind of SMTP verification could be added into the SMTP protocol without too much fuss, and spam-blocking programs such as SpamAssassin would use it as a hint - maybe assign a low, negative value to emails sent from servers without the protocol; and a high negative value to those emails that are not verified.
As this protocol extension becomes more commonplace, eventually, we would see more emails from real people be verifiable. But then again, I guess I'm an optimist.
I agree. Fixing spam is too big of a problem to solve with one masterful stroke. 'Dial-Back' would solve a smaller, but more clearly defined, problem: emails with forged headers.
When a mail server receives a message for delivery to its user, it picks up the sender's email domain and the message ID. It then sends a quick ping to the original mailserver - 'Verify '. There would be only two responses: message was sent by me, or no message found. This would prevent people from generating random email addresses and using this protocol to verify them.
Potential problems:
1) Length of time records of emails are kept by the sender's mailserver.
2) Classifying mail from old servers without the verify protocol. Mail can either be verified, not-verified (forged), or unable to be verified (old sender). Programs like SpamAssassin could use these states as relative indicators.
3) Transaction cost of the verify task on the receiving mailserver. Could these tasks be batched and sent in a group? Could the verification instead be done by the user's email client to distribute the burden?
4) Spammers will put together tiny mailservers capable of verifying any message and staying up only as long as it takes to deliver their payload.
5) Spammers using open mail relays will be able to send real, verifyable messages from innocent but poorly managed domains.
Problems #4 and #5 are never going to go away, because they are examples of correct SMTP behaviour. Fixing email header forgeries won't wipe out spam. Think of it instead as a method of more rigorously ensuring compliance with the SMTP protocol.
1) I don't have a wire from my headphone to my cellphone.
Against bluetooth:
1) I have to charge my headphone battery separately. 2) Possible interference or static in the connection between my cellphone and my headpiece, in addition to the static between my cellphone and the other party on the phone line. 3) My headset is now huge to accomodate the battery. 4) My headset has doubled or tripled in price.
I don't think I'll ever be interested in using bluetooth for headsets, keyboards, or mice.
On the other hand...
I can think of at least ten devices in my house that now use infrared links that could be improved by using something similar to bluetooth. Can my TV / VCR remotes be made more cheaply, effectively, and with some sort of standard device discovery mechanism? If so, sign me up.
When I was a young boy, our 3rd grade class was interrupted by the news of the shuttle disaster. My reaction - full of eight-year-old optimism - was, "That's wrong. The shuttle can't blow up."
I cried a few days later when someone told me the joke about Need Another Seven Astronauts.
Years later, I read Feynman's book, What Do You Care What Other People Think?, in which he explains that the shuttle tragedy was not, in fact, unexpected; it was overdue. The inescapable conclusion of this book was that the shuttle does not do what Americans expect of it.
It is with this in mind that I say, "Not Another Shuttle Accident! Please stop sending up rickety artifacts, and wait to return to space until we can demonstrate that we're actually making progress."
I didn't see any of the white LEDs available. Which products are these? The only ones available at my local store were the old school, 100 light set of red/green; and the 35-light set of sapphire blue. The sapphire blue set is the one pictured here.
The bulb casing on the red/green lights is pretty bare - it's a standard LED stuck in what appears to be a standard set of christmas light wire. The bulb casing on the blue LEDs is the new, oval sapphire style.
On the web page, the foreverbright guys suggest to return the set and get a replacement - I'll probably try that tomorrow.
Slashdot Mirror
This is vaguely reminiscient of the old Unix maxim, "Everything is either a file or a process," except that now KDE calls everything an URL.
/dev/extensions/audiocd/track1, /dev/extensions/sftp/, /dev/extensions/webdav, and so on? This type of a trick would have allowed these extensions to be used in any app that recognizes the file system, not only KDE type apps.
Correct me if I'm wrong, but wouldn't the old way of doing this be something like
What was the reason for not implementing these as devices?
I have read dozens of angry replies where people complain that the author should have learned "man", or "google", or read documentation, or known about "apt-get", or so on. I've read very few replies that advocate taking anything the author says seriously.
If this were a usability research study, the user's behavior - no matter how unusual - would be reviewed. Even if the user flails about helplessly, the goal of the study would be to identify ways to steer the user back onto the right track.
I certainly hope someone, somewhere, is reading this user's article (I certainly can't get to it) and wondering, "How can we tune our software so that it helps to steer users towards things such as man, google, and apt-get?"
This is a bullshit argument. If your code doesn't spend 99% of its time in loops, it doesn't deserve to run fast.
Angry much?
My presumptions are as follows:
All else being equal, a smaller piece of code will typically generate fewer cache misses than a larger piece of code.
For identical source code fragments, x86 byte code is typically smaller than Alpha byte code.
If either of my two assumptions are wrong, I will be happy to learn from you.
As a CPU buff, I ordered a back-issue of Microprocessor Report where they discussed the introduction of the Alpha in glowing terms. The radical chip architecture and speed-at-any-price mentality was new at the time, but quickly proved itself to be the superior chip design approach. For most of the 1990s, the Alpha was the fastest chip on the market in both integer and floating point operations.
Alpha was a Risc chip's risc chip. The IBM Power architecture has dozens of operations and permutations; the Alpha has a handful. This contributed not only to the Alpha's speed, but also to its insatiable demands for memory. DEC introduced a code-translator that allowed the Alpha to run x86-32 binaries at native speeds, but warned that memory requirements would grow substantially. The software never became cost effective.
But, towards the turn of the millennium, something strange happened: the Pentium Pro architecture (happily renamed PII and PIII) inched towards the lead in integer operations. The P4 actually surpassed the Alpha chips. Intel had, by then, hired away some of the Alpha designers and began to adopt its performance enhancing strategies. How could Intel catch up to the Alpha when Intel was burdened with an architecture as convoluted as x86?
Strangely, the x86 architecture can also be a benefit to chip design. Because x86 compresses commonly used instructions into tiny, awkward byte codes, the P4 generation of chips requires less memory and fewer cache misses - and the convoluted opcodes can be decoded quickly by the processor prior to dispatch. In the long run, Alpha's simplified instruction set proved to be less useful than machine-code x86 compatibility; and x86 chips are now little more than Alpha chips sitting behind an x86 instruction decoder. The Alpha design lives on in every CPU you buy, whether it be AMD or Intel.
For further reading, check out CPU performance numbers on http://www.spec.org and read the commentary on Microprocessor Report.
Sexy as hell? Looks more like a demented Robby the Robot from the old Nintendo Entertainment System. This is one of the foulest examples of product design since ... since ... I'm not sure; there are so many to choose from.
As long as we're talking about nVidia, does anyone have access to a long term performance graph of old nVidia cards? Rating them from generation to generation to how much improvement there was in each era.
I tried googling for it, but the keywords are just too popular, and everyone is google spamming and bombing and such. Don't even bother trying to search on Yahoo.
I used to have a good chart that showed dollars-per-FPS, but it's totally lost now.
Alright slashdotters! You just solved Katie Jones' domain name dispute. Where are you going next? To the Olympic coverage problem!!!
I was going to make a joke about how Sun is still calling it the Java Development Kit release 1.1 for Java 2.0 version 5.0, but this has been frequently noticed by others in this thread. So for those who are not interested in sorting through the bewildering list of packages available on the Java Download page, here's an ugly ascii kitty cat.
^ ^
=o.o=
~
One out of two ain't bad.
So far we have a roughly even ratio of comments: (3) comments for Dr. Evil's Laser Weapon (shark or moon based), and (3) comments for a 5 Megawatt Laser Ready By Mid-May.
And as long as you're reading this, let me compliment you on your fantastic bunny slippers.
Luke ... help me take this mask off. Just for once let me look ... on the Sicilian fires ... with my own eyes...
Well, I built my system from default SuSE 9.0, which has KDE logos emblazoned everywhere on the screen. It uses Konqueror, which I imagine is either KDE-oriented or by default part of KDE itself. Please forgive me if I in my ignorance cause confusion.
Actually, SuSE 9.0. It runs with Konqueror configured as its desktop environment. I hunted through the SuSE configuration settings app, and I didn't find anything related to double-click behavior. I searched for something similar to the normal menus in Windows (Tools | Folder Options), but I didn't find much progress. After a while, I started searching through help on Konqueror, and I found a help file that said "Single-clicks activate everything - they jump to links, open files, etc," so I presumed that meant that somebody had standardized on single-click-launch.
Is it maybe Konqueror that does this rather than KDE?
On the other hand, Apple's software philosophy is to have only one way to do something, and to have that work well and be obvious. Check out the Macintosh Human Interface Design documents.
.NET and standardize everything again.
Even more importantly, this philosophy extended to the Macintosh API. Even Microsoft moved in this direction. Bill Gates once said, "Why should everyone in the world have to write a File-Open dialog?" The Microsoft Common Controls API was the best thing that happened to Win16 programmers back in the early '90s.
Yet, after a few years, Microsoft started putting together OLE, DDE, ActiveX, and a bunch more stuff - there were tons of choices. Consider Microsoft's media player: there was a text-based API, a procedure call API, and an object oriented API. Microsoft programming has been getting harder, thus they introduce
I'm all for choice when it works. For example, KDE offers you tons of choices; by default there's this multiple-virtual-desktop thing with all sorts of options and shortcut keys and soforth. But the one choice I want - the ability to stop files and folders on my local harddrive from acting like hyperlinks - isn't available. I suppose that, given a few months of practice, I could get used to treating my hard drive like a website, but it isn't working out for me at the moment.
I dunno if I have a real point here. But I think Extreme Programming has at least one useful idea: customer stories. Try writing down all the things a user wants to do - "Map a Network Drive", "Change double-click behavior", "Organize My Documents" - and then put together an obvious way for the user to do it, or (if it's too hard to make it obvious) at least a straightforward help page that explains the task.
Am I rambling? Feel free to call me redundant.
As I recall, the US Army was suffering from a shortage of bugle players to play taps for the passing generation of soldiers. They developed a digital bugle that can play taps even if the bugler is incompetent, drunk, or both.
Since Toyota has now developed a vastly more complicated technology that can be used to solve the same problem as the slightly complicated one above, I look forward to future Pentagon procurement hearings.
Note to self: Sarcasm in this post often results in massive retribution.
The previous poster is right. It's a moral imperative.
*cue popcorn*
Churchill, when declaring war on Japan in 1941 after Pearl Harbor, sent a letter to Hirohito in which he informed the Japanese emperor that a state of war existed between Britain and Japan.
He signed it, "Your humble servant", and commented, "After all, when you have to kill a man, it costs nothing to be nice." See his WW2 memoirs.
I've found a partial copy of the letter, but it seems to have all the formalities edited out.
On the other hand, NASA has developed a new space telescope with a better mirror that is scheduled to be launched in 2011.
It is very important for NASA to do valuable science, but why not do it cost effectively? The cost of a shuttle mission, estimated at about $400m - $500m, is almost half of the whole budget for the next generation space telescope ($825m).
This seems pretty pessimistic. Remember, we manage to add new features to the Internet continually.
Think of HTML email, for example. In the beginning, very few people supported it. Back in 1995, AOL rejected messages with HTML content. Gradually HTML has become more accepted, and nowadays it's pretty commonplace.
I imagine this kind of SMTP verification could be added into the SMTP protocol without too much fuss, and spam-blocking programs such as SpamAssassin would use it as a hint - maybe assign a low, negative value to emails sent from servers without the protocol; and a high negative value to those emails that are not verified.
As this protocol extension becomes more commonplace, eventually, we would see more emails from real people be verifiable. But then again, I guess I'm an optimist.
I agree. Fixing spam is too big of a problem to solve with one masterful stroke. 'Dial-Back' would solve a smaller, but more clearly defined, problem: emails with forged headers.
When a mail server receives a message for delivery to its user, it picks up the sender's email domain and the message ID. It then sends a quick ping to the original mailserver - 'Verify '. There would be only two responses: message was sent by me, or no message found. This would prevent people from generating random email addresses and using this protocol to verify them.
Potential problems:
1) Length of time records of emails are kept by the sender's mailserver.
2) Classifying mail from old servers without the verify protocol. Mail can either be verified, not-verified (forged), or unable to be verified (old sender). Programs like SpamAssassin could use these states as relative indicators.
3) Transaction cost of the verify task on the receiving mailserver. Could these tasks be batched and sent in a group? Could the verification instead be done by the user's email client to distribute the burden?
4) Spammers will put together tiny mailservers capable of verifying any message and staying up only as long as it takes to deliver their payload.
5) Spammers using open mail relays will be able to send real, verifyable messages from innocent but poorly managed domains.
Problems #4 and #5 are never going to go away, because they are examples of correct SMTP behaviour. Fixing email header forgeries won't wipe out spam. Think of it instead as a method of more rigorously ensuring compliance with the SMTP protocol.
You, sir, are probably one of those people who keeps correcting me when I talk about connecting my desktop X client to the remote X server.
As Winston Churchill might have said, "You are a pedant up with whom I cannot put."
In favor of bluetooth:
1) I don't have a wire from my headphone to my cellphone.
Against bluetooth:
1) I have to charge my headphone battery separately.
2) Possible interference or static in the connection between my cellphone and my headpiece, in addition to the static between my cellphone and the other party on the phone line.
3) My headset is now huge to accomodate the battery.
4) My headset has doubled or tripled in price.
I don't think I'll ever be interested in using bluetooth for headsets, keyboards, or mice.
On the other hand...
I can think of at least ten devices in my house that now use infrared links that could be improved by using something similar to bluetooth. Can my TV / VCR remotes be made more cheaply, effectively, and with some sort of standard device discovery mechanism? If so, sign me up.
When I was a young boy, our 3rd grade class was interrupted by the news of the shuttle disaster. My reaction - full of eight-year-old optimism - was, "That's wrong. The shuttle can't blow up."
I cried a few days later when someone told me the joke about Need Another Seven Astronauts.
Years later, I read Feynman's book, What Do You Care What Other People Think?, in which he explains that the shuttle tragedy was not, in fact, unexpected; it was overdue. The inescapable conclusion of this book was that the shuttle does not do what Americans expect of it.
It is with this in mind that I say, "Not Another Shuttle Accident! Please stop sending up rickety artifacts, and wait to return to space until we can demonstrate that we're actually making progress."
Nice one - I wasn't aware you could smooth out AC with diodes like that. Is there any reason you can think that the manufacturers didn't do this?
The bulb casing on the red/green lights is pretty bare - it's a standard LED stuck in what appears to be a standard set of christmas light wire. The bulb casing on the blue LEDs is the new, oval sapphire style.
On the web page, the foreverbright guys suggest to return the set and get a replacement - I'll probably try that tomorrow.
Where did you find your white ones?