A technique called visual spoofing offers another method to present a "lock" to visitors on a Scam phishing site. The technique alters the user interface of the web browser, substituting images for parts of the browser interface that would normally help users detect the fraud. Javascript links launch a new browser window without scrollbars, menubars, toolbars and the status bar - which allows the scam artists to substitute a fake status bar containing the URL for a legitimate site, along with an image of a "lock" indicating a secure SSL site.
The evolving strategies of phishing crews underscore the need for continuing consumer education on detecting deceptive URLs, web sites and now, to discern authentic SSL certificates and relationships as well.
No it doesn't. It underscores the need to make browsers that aren't quite so bloody stupid, and do things like always displaying the real URL (gasp!) and not allowing Javascript to open new windows without the normal user interface security features (or a big yellow border saying 'Javascript window'). In fact, it might be a good idea to always have a grey border of a few pixels between the contents of a page and the user interface widgets surrounding it.
They may have a point on the SSL certificates, but the whole PKI thing seems a complete crock anyway... Verisign, Thawte and the like are not exactly the world's most trusted institutions. Maybe in the case of banks and other high-security sites it should be possible to pick up a free CD from your local branch or from your country's financial regulator containing the public keys. Then there would need to be a simple and foolproof way to import this key into your browser.
Yes, just typing in a filename is easiest, and for experienced users, it may be possible to type in a path like ~/work/letters/. The question is, if you do use a graphical interface to navigate to a certain directory, should it be a separate filepicker which belongs to the application, or should you use the same file manager as the rest of the desktop?
Keyboard-controlled drag and drop could be done by copying Microsofts 'cut' and 'paste' metaphor for files introduced in Win95, which is a bit awkward in some ways but well-suited for keyboard control. You could keyboard-navigate to a particular directory and press 'paste' or whatever to save the file there.
Actually, I suggest replacing one form of clicking around with the mouse with a different and more convenient form. On RISC OS the Save dialogue box let you enter a path if you chose, and then there would be no need to enter a path.
On Unix-like systems, the path could default to your home directory. The drag-and-drop to a directory window is an alternative to navigating around in the fiddly file selector dialogue.
Have a look at the ROX-desktop site: the Save dialogue box is very simple. You type a name and drag the icon to a filer window for the directory to save in. To load a file, either double-click it in the filer window or drag it onto an application. There is no separate Open dialogue box (although one could be added for convenience - but I never missed it when using RISC OS).
I agree with what you say about right-click in Konqueror. But consider how awkward it would be if instead of being able to load files from Konqueror you always had to open the specific application and do File -> Open. So this is an example showing that a single file manager is useful for _some_ things at least. It doesn't prove that having drag-and-drop saving to the file manager is better, but it does show that a separate filepicker in each app is not always convenient.
Many of the problems you've cited with SaveAs are the result of poor and inconsistent implementations of dialogs, not file-dialogs per se.
This is true, but so far (using various versions of Windows and Linux) I have not seen a filepicker dialogue box that isn't rather awkward to use. Certainly none that matches the convenience of the Filer windows in RISC OS where you would double-click (or drag) a file to open it, and drag from the application to the Filer to save. If a really good filepicker dialogue existed then I'd be happy to use it, but there isn't much sign of one at the moment. Most changes to the dialogue boxes seem to involve adding more complication like sidebars for 'My Documents'.
I do agree that things would be much better if every app could use the same file picker; perhaps the way forward for this with the free desktops is to make the file picker a separate program which is run by the app and prints a filename to use on stdout. Then it would be easy to have the same user interface between GNOME, KDE and the other free desktops, and relatively easy to retro-fit the new file picker onto older X11 apps. It would also be simple to try out new file-choosing interfaces, such as the drag-and-drop save and load we have been discussing.
With a file browser system, it would be:
Un-maximize word processor -> open browser app -> find folder -> position windows for drag & drop -> drag & drop
Well actually - open file browser, find folder, double-click. Only in the case where you wanted to open the file with one particular application (rather than the default) would you need to drag it onto that app. Clicking to open a file browser (perhaps starting with your home directory) wouldn't normally be any more difficult than the Open menu item.
There are additional problems. From my experience with Windows users:
1) They don't understand drag & drop
2) They don't understand hierarchical filesystems
Interesting. This seems to match what the 'cruft' web page says about not wanting to retrain users at any cost. It's not surprising that Windows users do not understand drag and drop, since Windows hardly uses it (and where it does use it the semantics are very odd and inconsistent - see the 'cruft' page again). Similarly, Windows goes out of its way to hide the hierarchical file system, so users haven't got much familiarity with it. I wonder whether Mac users have more idea.
In case you get the wrong idea, I am not one of those Slashdot users who rants about how users should understand how to use a computer properly and undergo some training course before being allowed to sit down at the terminal. If a concept isn't intuitive to beginning users then it shouldn't be part of the GUI. But I think that a simple file browser where you double-click a folder to open it makes it clear how the filesystem works - as one poster commented of ROX-desktop, 'you get a clear feeling that this file goes *here*, and that file goes *there*' - and on systems like the old RISC OS or the new Mac OS X where there is some sensible filesystem layout, a file browser interface to it is much less confusing than the several magic directories like 'My Documents' that Windows uses. (How to view 'My Pictures' using the Windows Explorer? I've seen users get very confused about where these different magic folders live and how to copy files between them.)
Similarly, drag and drop is very easy to pick up if used consistently. In my experience, drag and drop file loading and a simple, consistent file manager is a much more efficient way to load, save and manage files than clicking about in lots of small Open / Save dialogue boxes; and it can even be more efficient than using the command line in some cases.
And by the time Linux is popular on the desktop, everybody would already have 512+ MB RAM.
And by that time, free software developers will be requring two gigabytes to run comfortably, after all RAM is getting cheaper, and everyone will have that much in a few years...
Remember you don't always want to open an file in the default application for that file type.
Indeed, which is why RISC OS and ROX-desktop allow you to drag a file onto an application's window or icon.
To load a file, drag it from the file window to the app; to save a file, drag from the application to the filer. It's simple and intuitive, at least IMHO, and it's annoying to have to go back to the clunky Windows-style filepickers.
I'm not just speculating about what might be cool; I've used both kinds of GUI a lot - those with File->Open and filepickers, and those where you drag from a file browser window to open and drag to the window to close. Personally, I greatly prefer the style without the filepickers. You might find it different but I encourage you to give ROX-desktop a try (although the usability improvement is diluted because not every application supports drag-and-drop loading and saving).
The filepicker dialogue box could be kept for those users who still want to use it, in the same way we still have the command line as well as graphical file managers. But if there are good features in the filepicker, they could be added to the main file manager so they could be used all the time, not just for loading and saving.
When I said drag the file to a directory window to save it, I meant 'to choose where to save it' - later saves to the same location are just a single keypress or click.
The more features you bundle into a single program, the less likely it performs any of them well, simply because different features (such as useability and low learning curve) conflict with one another.
This is kind of my point - the Unix motto, do one thing and do it well. Rather than each application having a cut-down file browser you have to use with Open and Save, use a single file browser program and get applications to talk to it for loading and saving files. Of course it might be a good idea to have a menu item or key shortcut which pops up a file browser window for the location you last used.
Again - although views on what's easiest to use are subjective, I am speaking from experience. I recommend you try ROX-desktop (or at least look at the web site and screenshots).
See also my other reply about how to load files in different applications.
On the same system, with 390 megabytes of RAM. I meant you should compare them on the same system with less RAM.
I stand by what I said - with the hardware most users had available, Win95 was slower than Windows 3.1. But on today's hardware, Win95 is faster. So you can't say that program X is faster than Y *in general* based on trying it on just one machine. Your machine doesn't represent the hardware available at the low end, for PCs that might be two or three years old.
It's hardly surprising that Win95 won; strangely enough, a few months after 95 came out, copies of 3.1 were no longer available. Of course, 95 is generally a better system, and memory prices fell rapidly a year or so after it came out so a 16 meg system became affordable for most people.
Most modern games use this method to speed things up: they eat insanely amounts of memory in order to make the game itself run faster and smoother.
The target market for games is a bit different; they aim for recent and relatively high-end hardware.
On this system (Athlon 1.4 Ghz 390 MB RAM) I can definitely say GNOME 2.x is faster than 1.4.
That's the same argument Microsoft used to say that Windows 95 is faster than Windows 3.1. And on a system with plenty of memory, it is. But most people's experience with the hardware available at the time was that Win95 was much much slower, thrashing horribly with less than eight megabytes and still rather uncomfortable with less than sixteen.
Making a program twice as fast in CPU time but at the expense of using twice as much memory may not be a good trade-off. If you start running low on memory then you get a very steep performance drop from paging to disk (or not having enough RAM for disk cache, which is effectively the same thing). The most important benchmark is how it performs on a machine with, say, 64 megabytes of RAM, or whatever minimum level you want to require. Not shaving a few fractions of a second off times on recent hardware.
The best file selector is no file selector at all. Since there is already a file browser such as Evolution (or its equivalent) that should be used, and made quick and easy enough for simple file selection tasks. To open a file, just view its directory and click on it; the application loads automatically and there is no real need for the two-step 'load application then use the Open menu', which dates from a time when computers didn't have a single GUI and there was no means to just open a file directly. To save a file, why not drag it from the application to the directory window. None of that clicking about with 'parent directory' and other nonsense.
Matthew Thomas pointed out better than I could that the separate file-picker is user interface cruft left over from an earlier age. Let's just have one file browser in the desktop and make it good enough to use for everything.
I don't understand what makes an LDAP directory so great for storing user details. At a place where I once worked we stored details in a relational database (Postgres) and that seemed to work well. There are probably other database systems that could be used too. Why LDAP?
I was thinking of the various bug reports I've made to rt.perl.org, eg #23061, or #23140 (which is documented, but obscurely). Sometimes there is no documentation to say whether a behaviour is a bug or correct - the implementation defines the language and so any bug report for it is by definition invalid:-(.
I'm not particularly looking to complain about Perl - I use it more than any other language - I am just questioning the assertion that Perl is better documented than any other language. It isn't, because there are very many aspects which aren't documented rigorously anywhere and are defined by the implementation. Many other programming languages do have a complete specification.
You're right that it would not be practical for the documentation to cover every case of what happens using the + operator: that's because Perl is a big language and it has hairy syntax and semantics. A smaller language like Scheme or Forth can be documented in its entirety, but Perl can't be short of saying 'look at the implementation'. That's why I don't think it is right to say that Perl is the best-documented computer language.
perlref, perlsyn and the others are useful but there's no way they completely specify perl's behaviour. You couldn't write a compatible perl implementation using just the manual pages - it would have to be trial and error comparing against the existing implementation.
The simple answer to what that does is: it does what you expect it to.
That's all very well, but 'what I expect it to' is not documented anywhere, so you can't say that Perl has complete documentation, which is what we're discussing. I'm not arguing against the merits of Perl, just pointing out that in a formal sense it can't be said to be well documented.
Binary "+" returns the sum of two numbers.
Is that not clear enough?
No. For a start, it doesn't. What if one of the arguments is a string? Or a reference? Or undef? What if the numbers are quite large - the result will not be exactly their sum but an approximation. The same applies for very small (close to zero) numbers.
If you're worry about what a number is, you could check: perlnumber - semantics of numbers and numeric operations in Perl
Fair point. But I wasn't really considering the + operator so much as the statement $a = $b + $c;
Even if you know what + does, the semantics of the above statement are still not defined anywhere. Which of $b and $c is evaluated first, for example? (And yes, it does matter, consider tied variables.)
The fact is, Perl is defined almost entirely by its implementation - there's no way you could start with the current manual pages and write a different implementation that would be compatible with most code. There's far too much DWIM which is not clearly defined anywhere.
Slashdot Mirror
You can at least Google for 'photo-proliferate-process' - good luck with 'masturbating bear'...
No it doesn't. It underscores the need to make browsers that aren't quite so bloody stupid, and do things like always displaying the real URL (gasp!) and not allowing Javascript to open new windows without the normal user interface security features (or a big yellow border saying 'Javascript window'). In fact, it might be a good idea to always have a grey border of a few pixels between the contents of a page and the user interface widgets surrounding it.
They may have a point on the SSL certificates, but the whole PKI thing seems a complete crock anyway... Verisign, Thawte and the like are not exactly the world's most trusted institutions. Maybe in the case of banks and other high-security sites it should be possible to pick up a free CD from your local branch or from your country's financial regulator containing the public keys. Then there would need to be a simple and foolproof way to import this key into your browser.
The moderator was me - I think I meant to choose some other moderation and clicked the wrong thing. Anyway, this post should undo it.
Yes, just typing in a filename is easiest, and for experienced users, it may be possible to type in a path like ~/work/letters/. The question is, if you do use a graphical interface to navigate to a certain directory, should it be a separate filepicker which belongs to the application, or should you use the same file manager as the rest of the desktop?
Keyboard-controlled drag and drop could be done by copying Microsofts 'cut' and 'paste' metaphor for files introduced in Win95, which is a bit awkward in some ways but well-suited for keyboard control. You could keyboard-navigate to a particular directory and press 'paste' or whatever to save the file there.
Milligrams per ounce? What kind of measurement system is that?
..err I meant 'you can enter a path if you choose, and then there's no need to drag the file to a directory window'.
Actually, I suggest replacing one form of clicking around with the mouse with a different and more convenient form. On RISC OS the Save dialogue box let you enter a path if you chose, and then there would be no need to enter a path.
On Unix-like systems, the path could default to your home directory. The drag-and-drop to a directory window is an alternative to navigating around in the fiddly file selector dialogue.
Have a look at the ROX-desktop site: the Save dialogue box is very simple. You type a name and drag the icon to a filer window for the directory to save in. To load a file, either double-click it in the filer window or drag it onto an application. There is no separate Open dialogue box (although one could be added for convenience - but I never missed it when using RISC OS).
This is true, but so far (using various versions of Windows and Linux) I have not seen a filepicker dialogue box that isn't rather awkward to use. Certainly none that matches the convenience of the Filer windows in RISC OS where you would double-click (or drag) a file to open it, and drag from the application to the Filer to save. If a really good filepicker dialogue existed then I'd be happy to use it, but there isn't much sign of one at the moment. Most changes to the dialogue boxes seem to involve adding more complication like sidebars for 'My Documents'.
I do agree that things would be much better if every app could use the same file picker; perhaps the way forward for this with the free desktops is to make the file picker a separate program which is run by the app and prints a filename to use on stdout. Then it would be easy to have the same user interface between GNOME, KDE and the other free desktops, and relatively easy to retro-fit the new file picker onto older X11 apps. It would also be simple to try out new file-choosing interfaces, such as the drag-and-drop save and load we have been discussing.
Well actually - open file browser, find folder, double-click. Only in the case where you wanted to open the file with one particular application (rather than the default) would you need to drag it onto that app. Clicking to open a file browser (perhaps starting with your home directory) wouldn't normally be any more difficult than the Open menu item.
Interesting. This seems to match what the 'cruft' web page says about not wanting to retrain users at any cost. It's not surprising that Windows users do not understand drag and drop, since Windows hardly uses it (and where it does use it the semantics are very odd and inconsistent - see the 'cruft' page again). Similarly, Windows goes out of its way to hide the hierarchical file system, so users haven't got much familiarity with it. I wonder whether Mac users have more idea.
In case you get the wrong idea, I am not one of those Slashdot users who rants about how users should understand how to use a computer properly and undergo some training course before being allowed to sit down at the terminal. If a concept isn't intuitive to beginning users then it shouldn't be part of the GUI. But I think that a simple file browser where you double-click a folder to open it makes it clear how the filesystem works - as one poster commented of ROX-desktop, 'you get a clear feeling that this file goes *here*, and that file goes *there*' - and on systems like the old RISC OS or the new Mac OS X where there is some sensible filesystem layout, a file browser interface to it is much less confusing than the several magic directories like 'My Documents' that Windows uses. (How to view 'My Pictures' using the Windows Explorer? I've seen users get very confused about where these different magic folders live and how to copy files between them.)
Similarly, drag and drop is very easy to pick up if used consistently. In my experience, drag and drop file loading and a simple, consistent file manager is a much more efficient way to load, save and manage files than clicking about in lots of small Open / Save dialogue boxes; and it can even be more efficient than using the command line in some cases.
Indeed, which is why RISC OS and ROX-desktop allow you to drag a file onto an application's window or icon.
To load a file, drag it from the file window to the app; to save a file, drag from the application to the filer. It's simple and intuitive, at least IMHO, and it's annoying to have to go back to the clunky Windows-style filepickers.
The filepicker dialogue box could be kept for those users who still want to use it, in the same way we still have the command line as well as graphical file managers. But if there are good features in the filepicker, they could be added to the main file manager so they could be used all the time, not just for loading and saving.
When I said drag the file to a directory window to save it, I meant 'to choose where to save it' - later saves to the same location are just a single keypress or click.
This is kind of my point - the Unix motto, do one thing and do it well. Rather than each application having a cut-down file browser you have to use with Open and Save, use a single file browser program and get applications to talk to it for loading and saving files. Of course it might be a good idea to have a menu item or key shortcut which pops up a file browser window for the location you last used.
Again - although views on what's easiest to use are subjective, I am speaking from experience. I recommend you try ROX-desktop (or at least look at the web site and screenshots).
See also my other reply about how to load files in different applications.
On the same system, with 390 megabytes of RAM. I meant you should compare them on the same system with less RAM.
I stand by what I said - with the hardware most users had available, Win95 was slower than Windows 3.1. But on today's hardware, Win95 is faster. So you can't say that program X is faster than Y *in general* based on trying it on just one machine. Your machine doesn't represent the hardware available at the low end, for PCs that might be two or three years old.
It's hardly surprising that Win95 won; strangely enough, a few months after 95 came out, copies of 3.1 were no longer available. Of course, 95 is generally a better system, and memory prices fell rapidly a year or so after it came out so a 16 meg system became affordable for most people.
The target market for games is a bit different; they aim for recent and relatively high-end hardware.
That's the same argument Microsoft used to say that Windows 95 is faster than Windows 3.1. And on a system with plenty of memory, it is. But most people's experience with the hardware available at the time was that Win95 was much much slower, thrashing horribly with less than eight megabytes and still rather uncomfortable with less than sixteen.
Making a program twice as fast in CPU time but at the expense of using twice as much memory may not be a good trade-off. If you start running low on memory then you get a very steep performance drop from paging to disk (or not having enough RAM for disk cache, which is effectively the same thing). The most important benchmark is how it performs on a machine with, say, 64 megabytes of RAM, or whatever minimum level you want to require. Not shaving a few fractions of a second off times on recent hardware.
The best file selector is no file selector at all. Since there is already a file browser such as Evolution (or its equivalent) that should be used, and made quick and easy enough for simple file selection tasks. To open a file, just view its directory and click on it; the application loads automatically and there is no real need for the two-step 'load application then use the Open menu', which dates from a time when computers didn't have a single GUI and there was no means to just open a file directly. To save a file, why not drag it from the application to the directory window. None of that clicking about with 'parent directory' and other nonsense.
Matthew Thomas pointed out better than I could that the separate file-picker is user interface cruft left over from an earlier age. Let's just have one file browser in the desktop and make it good enough to use for everything.
'apt-get install xmltv' if you use Debian or Red Hat with Axel Thimm's RPMs...
I don't understand what makes an LDAP directory so great for storing user details. At a place where I once worked we stored details in a relational database (Postgres) and that seemed to work well. There are probably other database systems that could be used too. Why LDAP?
I was thinking of the various bug reports I've made to rt.perl.org, eg #23061, or #23140 (which is documented, but obscurely). Sometimes there is no documentation to say whether a behaviour is a bug or correct - the implementation defines the language and so any bug report for it is by definition invalid :-(.
I'm not particularly looking to complain about Perl - I use it more than any other language - I am just questioning the assertion that Perl is better documented than any other language. It isn't, because there are very many aspects which aren't documented rigorously anywhere and are defined by the implementation. Many other programming languages do have a complete specification.
You're right that it would not be practical for the documentation to cover every case of what happens using the + operator: that's because Perl is a big language and it has hairy syntax and semantics. A smaller language like Scheme or Forth can be documented in its entirety, but Perl can't be short of saying 'look at the implementation'. That's why I don't think it is right to say that Perl is the best-documented computer language.
perlref, perlsyn and the others are useful but there's no way they completely specify perl's behaviour. You couldn't write a compatible perl implementation using just the manual pages - it would have to be trial and error comparing against the existing implementation.
$a = $b + $c;
Even if you know what + does, the semantics of the above statement are still not defined anywhere. Which of $b and $c is evaluated first, for example? (And yes, it does matter, consider tied variables.)
The fact is, Perl is defined almost entirely by its implementation - there's no way you could start with the current manual pages and write a different implementation that would be compatible with most code. There's far too much DWIM which is not clearly defined anywhere.