Forwarding mail for a "virtual user" to an external address in Sendmail:
add 1 line to/etc/mail/virtusertable
in Exchange 2000/3:
Go to Active Directory Users and Computers,
Create User, give them a password and disk space they will never use *clickety* *click* *click*
Create Contact with forwarding address *clickety* *click* *click*
Go back to newly created user, go to the Exchange General tab (not the Exchange Tasks tab) and modify the mail setting *clickety* *click* *click*
Don't confuse (or transpose) person, user, alias, object, contact, entity and mail identity whilst reading Microsoft's own documentation on how to do this. *curse* *swear* *curse*
Of course, neither of the above methods is intuitive either.
Well, they are kind of struggling as it is with the PBS debate, (yay, we all know what ever-greening is now... sort of) how hard is it going to be to have a low-brow discussion of software patents?
Yeah, because no-one developed software before the internet and phat pipes...
The shortsightedness of our government in purchasing overseas software instead of fostering local development was probably a much larger roadblock. Although introducing the GST was a boon to some (one?) local accounting software developer(s?).
How will consumers deal with the dual concepts of price and quality (especially when one is not really indicative of the other)? Heh, they will (generally) buy the cheapest and bitch about the quality.
I want new windows to appear on top of other windows, but I don't want them to steal focus. How do I set this in gconf/Metacity?
Why would I want this? Well, I use a multi-tasking operating system, and to be typing away in a text editor and have those keystrokes stolen because some inane dialog box has popped up from another application and stolen focus drives me insane. New windows that do not appear on top are likely however to be ignored.
Until recently this was impossible to achieve in KDE as well, but sawfish has always been happy to oblige.
Another issue (that I do know how to fix in gconf) that seems to show that nearly all "usability experts" are either talking through their hats or are unable to grasp the "whole picture" is the location of the "close window" button. There is no excuse for placing this button anywhere near other buttons like "minimize window". Show me a tv remote where the power button is located between the volume up and volume down buttons....
Yep, the search path does have nothing to do with metadata, I agree. My view however is that the files matched are data files, they just happen to be executable data files. The metadata here is their location.
No, I'm not filling out a questionnaire for every file I save. Even without user intervention there is plenty of information that applications could save automatically for me (see my "Bob email" example in my reply to warax ). I think it is reasonable to think that with the availabilty of a file system that supports additional metadata, programs will take more and more advantage of it automatically or with a minimum of user interaction. The fact that such programs don't exist right now is not really surprising or an indication of what will be available in the future.
For important files, I'm quite happy to fill in a bit of extra information. I already database my images and I find that the metadata is often revised over time anyway. The two weaknesses in my current system are: 1) The file is identified in the database by its location, so moving it around the filesystem is tricky.
2) I can easily give someone a copy of an image, but I cannot easily give them a useful copy of my metadata about that image.
There was a case in Sydney, Australia a few years ago when a young boy was run over by a Harley rider. The rider thought the boy would move out of his way, the boy however was deaf...
To me directory names and file names are just metadata, but because they are only loosly coupled to the file itself, they are very fragile metadata. If you've gone to the trouble of ordering your data this way, then you'd have gone to the trouble of entering the metadata required directly to the file...
An example of metadata that people use every day without realising it is path. Both in Windows* and *nix command are called without their full paths. The computer then searches a preselected number of directories in a preselected order for a file with a matching filename and that is "executable". As I've said before, we are already benefitting from metadata without direct user intervention.
"Virtual" folders are a by-product of good metadata. No matter how good your directory/filename system is, there is no way to provide a "directory" of all images taken at locationB and a "directory" of all images of offspringA without file duplication or fragile sym-linking. With "virtual" folders you can create the "directory" you need for the task at hand without moving anything around.
Well, my first line was a comment about automatically added metadata. Clever developers will find all sorts of ways to automatically add metadata without requiring user action. For example, suppose a mime type was stored with each file. Now when you do a search for images, there is no need to specify an extension, or for that matter even a type, anything image/*blah* will be included, be it in jpeg, gif or png format. This sort of functionality requires no user input.
Locate is great, but... it's slow. For example, I just saved a document in ~/docs/emails_from/bob/ , except I didn't. Distracted at a critical moment I 've dropped it somewhere on my filesystem. I could run updatedb, but I need the document _now_ not twenty five minutes later. I could run find, but where do I start it... in the emails_from directory, my home directory... it is still going to take a while and if I start in the wrong place I will have to restart the search again. With my metadata filesystem I should be able to do a search for documents saved from emails from bob in the last day and find it nearly instantly (all this information can be automatically added by the email program to the file when it is saved).
The fact that smart users gain extra functionality above and beyond what can be provided automatically is bonus for them, but I can see even "lazy" users getting benefits.
Hopefully the search function will support sets, and I can define bird as a set of which hawk is perhaps even a subset. After all, having a "family" set for searching would be useful too, etc.
Once the metadata is attached to the file and is consistently carried around by the filesystem, refining the searching programs is a seperate issue.
Whilst most things to tend to get over-hyped, at present no-one can take _any_ advantage of non-existing functionality (unless they are still using Be). People who don't want this added service should be free to format their partitions however they like.
Most filesystems all ready handle seamless metadata entry. A files directory, filename, permissions, ownership, ctime, mtime, etc are all metadata stored by the filesystem and few people want to argue that this metadata is unwanted and needless filesystem bloat.
Not all information is text based either. How do you store family photos in an easy to find manner? What directory/filename structure will allow you to quickly find the photo of daughterA at locationB taken sometime in yearC that doesn't contain ex-partnerD?
"Virtual folders" are the _best_ feature of the Evolution mail reader and beat the pants off a one-time search for something. This is simply because no matter how you organise your data, sometimes it just makes sense for it to stored under two places at once. For example, the directory which holds photos of daughterA and the directory which holds photos taken at locationB. It would seem to me that storing this data multiple times (or making lots of soft links) creates far more overheads then storing some extra metadata which is available to every program you run.
Also, relying on metadata created and stored by an application leaves you beholden to that application.
Whether or not people will actually make any use of a FS metadata capabilities is a seperate issue. I don't want to spend all my time re-arranging directories and shuffling my data around to make it easier to find. I bought a computer to do such menial tasks...
"He" also blocks the address anybody@microsoft.com... so I guess they are all guilty too.
P.S. I like the 403 error page on your website, but I felt the links at the bottom were a waste. It isn't exactly hard to find articles on the topic. Of course the selections you made, like those in your comment here, exudes a certian bias.
In the long run, I can see them suffering from less choice in developers too. After all, they are clearly not GNOME's target audience and many future contributors may move to something else which is less draconian about their urge to tweak.
What happens when/if the only development done on GNOME is commercially motivated and funded? A situation I don't think is as absurd as it may have once been.
Yeah, forget all that left-to-right corner eye scanning waffle. The above is the real usability issue.
Chances are when I've done something to call up a dialog box, I'll want to OK it 95+ times out of a 100. That is the option I want closest to my mouse pointer. Hell, pop that box up with the OK button two pixels away from the mouse, not in the middle of the screen, miles from my current pointer location.
Focusing on the eye issue and not the mouse issue reeks of academic short-sightedness. (Both puns intended.)
Soooo, if you think like a developer then you will expect things to work in terms of the developer mindset...... which is typically NOT user friendly.
I struggle with this commonly expressed viewpoint. Aren't developers also users or are they developing on punch cards done by hand??? If their are usability issues, surely they would have encountered them often enough to be interested in correcting them. Isn't that where a lot of these new programs/forks come from?
You state that as users become developers they will create more "user happiness", but surely as soon as they become developers they will just start creating more "developer happiness". I think that the dividing line so many people want to draw simply doesn't exist.
Which projects in the FOSS community get more developer time is a completely different issue.
They should differ in look-and-feel, but they ought to use a common "under-the-hood" framework for interoperability.
Yes, the real strength of the *nix family are all the small standalone "utilities" that can be put together through the use of pipes, etc.
Any UI (cli, Gnome, HTML, logfile, etc) should really just be a front-end to this framework. If a new utility is required, it should be designed to fit into this existing framework, not as a stand-alone monolithic program. An example of this approach is cdrecord, whilst there is a plethora of GUI cd burning apps most are back-ended by cdrecord and plenty of people also use it straight from the cli or in scripts.
Why aren't all applications built this way? Plenty of reasons, some people don't understand the strength of such an approach, despite the fact that they benefit from it already. It is also more work initially to create such a system, many developers are keen just to get their application working, never mind interoperability and seperation of function. Yes, this does result in a lot of duplication of effort, but there is nothing stopping someone from coming along later and splitting some of these FOSS monolithic applications up to make them more useful to the community as a whole.
Computers are brainless, this is why they can be cracked.
Using compilers to catch common programming errors is a good idea, but this will just see serious crackers targeting flaws not caught in current compilers.
Leading to new compilers... leading to new cracks... etc
If the only security guidance a programmer gets is from the programming language itself and it's compiler, then you have the brainless in charge of security...
Of course, there are also such things as OK warnings too, eg:
#include <stdio.h>
int main (int argc,char **argv) { int some_val;
if (argc > 1) some_val = argc; else { /* do something */ }
if (argc > 2) printf("Number of arguments passed in: %d\n",some_val);
return 0; }
compiles as such:
gcc -O2 -W -o test1 test1.c test1.c: In function `main': test1.c:5: warning: `some_val' might be used uninitialized in this function
As two is always larger then one, I feel secure in ignoring that warning.
Hmm, the ECODE tag seems to ignore leading whitespace, I bet the Python programmers are over-joyed about that. (There should be indentation on the lines following an if statement)
Yep, and as soon as you throw in disk access, CPU and memory speed become almost redundant.
One advantage of over clocking is that is allows under clocking. For those of us without air conditioning in hot climates the ability to seasonally adjust heat output of the CPU is a bonus.
"Our new OS comes with a Longhorn(TM), once an hour it anal probes the user to confirm their identity. After the intial hour long ass reaming required for installation, most users appreciate the quick prostate massage required to keep everything working perfectly."
Slashdot Mirror
Yes, but you can't send to the "internal" address from outside of the internal network, so this won't work as a general redirect.
Oh yeah, Exchange is a snap.
/etc/mail/virtusertable
Forwarding mail for a "virtual user" to an external address in Sendmail:
add 1 line to
in Exchange 2000/3:
Go to Active Directory Users and Computers,
Create User, give them a password and disk space they will never use *clickety* *click* *click*
Create Contact with forwarding address *clickety* *click* *click*
Go back to newly created user, go to the Exchange General tab (not the Exchange Tasks tab) and modify the mail setting *clickety* *click* *click*
Don't confuse (or transpose) person, user, alias, object, contact, entity and mail identity whilst reading Microsoft's own documentation on how to do this. *curse* *swear* *curse*
Of course, neither of the above methods is intuitive either.
Well, they are kind of struggling as it is with the PBS debate, (yay, we all know what ever-greening is now ... sort of) how hard is it going to be to have a low-brow discussion of software patents?
Tryone,
There's a call for you from Bolivia. Some guy with a lot of guns wants to know what to do with two hundred tonnes of cocaine.
Yeah, because no-one developed software before the internet and phat pipes ...
The shortsightedness of our government in purchasing overseas software instead of fostering local development was probably a much larger roadblock. Although introducing the GST was a boon to some (one?) local accounting software developer(s?).
Err, but the issue is that the FTA includes re-writing Australian patent laws to be more like those of the US.
Too true.
How will consumers deal with the dual concepts of price and quality (especially when one is not really indicative of the other)? Heh, they will (generally) buy the cheapest and bitch about the quality.
I want new windows to appear on top of other windows, but I don't want them to steal focus. How do I set this in gconf/Metacity?
Why would I want this? Well, I use a multi-tasking operating system, and to be typing away in a text editor and have those keystrokes stolen because some inane dialog box has popped up from another application and stolen focus drives me insane. New windows that do not appear on top are likely however to be ignored.
Until recently this was impossible to achieve in KDE as well, but sawfish has always been happy to oblige.
Another issue (that I do know how to fix in gconf) that seems to show that nearly all "usability experts" are either talking through their hats or are unable to grasp the "whole picture" is the location of the "close window" button. There is no excuse for placing this button anywhere near other buttons like "minimize window". Show me a tv remote where the power button is located between the volume up and volume down buttons....
Yep, the search path does have nothing to do with metadata, I agree. My view however is that the files matched are data files, they just happen to be executable data files. The metadata here is their location.
No, I'm not filling out a questionnaire for every file I save. Even without user intervention there is plenty of information that applications could save automatically for me (see my "Bob email" example in my reply to warax ). I think it is reasonable to think that with the availabilty of a file system that supports additional metadata, programs will take more and more advantage of it automatically or with a minimum of user interaction. The fact that such programs don't exist right now is not really surprising or an indication of what will be available in the future.
For important files, I'm quite happy to fill in a bit of extra information. I already database my images and I find that the metadata is often revised over time anyway. The two weaknesses in my current system are:
1) The file is identified in the database by its location, so moving it around the filesystem is tricky.
2) I can easily give someone a copy of an image, but I cannot easily give them a useful copy of my metadata about that image.
There was a case in Sydney, Australia a few years ago when a young boy was run over by a Harley rider. The rider thought the boy would move out of his way, the boy however was deaf...
I answered some of this in my reply to warax.
To me directory names and file names are just metadata, but because they are only loosly coupled to the file itself, they are very fragile metadata. If you've gone to the trouble of ordering your data this way, then you'd have gone to the trouble of entering the metadata required directly to the file...
An example of metadata that people use every day without realising it is path. Both in Windows* and *nix command are called without their full paths. The computer then searches a preselected number of directories in a preselected order for a file with a matching filename and that is "executable". As I've said before, we are already benefitting from metadata without direct user intervention.
"Virtual" folders are a by-product of good metadata. No matter how good your directory/filename system is, there is no way to provide a "directory" of all images taken at locationB and a "directory" of all images of offspringA without file duplication or fragile sym-linking. With "virtual" folders you can create the "directory" you need for the task at hand without moving anything around.
Well, my first line was a comment about automatically added metadata. Clever developers will find all sorts of ways to automatically add metadata without requiring user action. For example, suppose a mime type was stored with each file. Now when you do a search for images, there is no need to specify an extension, or for that matter even a type, anything image/*blah* will be included, be it in jpeg, gif or png format. This sort of functionality requires no user input.
... it's slow. For example, I just saved a document in ~/docs/emails_from/bob/ , except I didn't. Distracted at a critical moment I 've dropped it somewhere on my filesystem. I could run updatedb, but I need the document _now_ not twenty five minutes later. I could run find, but where do I start it ... in the emails_from directory, my home directory ... it is still going to take a while and if I start in the wrong place I will have to restart the search again. With my metadata filesystem I should be able to do a search for documents saved from emails from bob in the last day and find it nearly instantly (all this information can be automatically added by the email program to the file when it is saved).
Locate is great, but
The fact that smart users gain extra functionality above and beyond what can be provided automatically is bonus for them, but I can see even "lazy" users getting benefits.
Hopefully the search function will support sets, and I can define bird as a set of which hawk is perhaps even a subset. After all, having a "family" set for searching would be useful too, etc.
Once the metadata is attached to the file and is consistently carried around by the filesystem, refining the searching programs is a seperate issue.
Whilst most things to tend to get over-hyped, at present no-one can take _any_ advantage of non-existing functionality (unless they are still using Be). People who don't want this added service should be free to format their partitions however they like.
Most filesystems all ready handle seamless metadata entry. A files directory, filename, permissions, ownership, ctime, mtime, etc are all metadata stored by the filesystem and few people want to argue that this metadata is unwanted and needless filesystem bloat.
Not all information is text based either. How do you store family photos in an easy to find manner? What directory/filename structure will allow you to quickly find the photo of daughterA at locationB taken sometime in yearC that doesn't contain ex-partnerD?
"Virtual folders" are the _best_ feature of the Evolution mail reader and beat the pants off a one-time search for something. This is simply because no matter how you organise your data, sometimes it just makes sense for it to stored under two places at once. For example, the directory which holds photos of daughterA and the directory which holds photos taken at locationB. It would seem to me that storing this data multiple times (or making lots of soft links) creates far more overheads then storing some extra metadata which is available to every program you run.
Also, relying on metadata created and stored by an application leaves you beholden to that application.
Whether or not people will actually make any use of a FS metadata capabilities is a seperate issue. I don't want to spend all my time re-arranging directories and shuffling my data around to make it easier to find. I bought a computer to do such menial tasks...
That would be great except ... if libmonkey was installed chances are the configure would find it.
If it is not on the system rpm -qf isn't going to return anything useful.
Zorilla: "Debugger, libmonkey1316-3.so isn't installed on my system is it?"
Debugger: "No."
Zorilla: "Debugger, there is no monkey-dev rpm is there?"
Debugger: "No"
Zorilla: "This program I'm trying to install doesn't actually mention anything about what I should install to get libmonkey does it?"
Debugger: "No."
Zorilla: "I'm not going to find anything by searching on rpmfind.net, am I?"
Debugger: "No."
Zorilla: "If I search on google will I find anything but unanswered posts on a myriad of message boards and mailling lists?"
Debugger: "No."
Zorilla: "Is typing in swear words on the console as satisfying as screaming them loudly at the monitor?"
Debugger: "No, but other people in the room wont give you strange looks."
(PS: libmonkey is part of the gorilla-dev.rpm, but that requires libbanana and I have no idea where you get that.)
"He" also blocks the address anybody@microsoft.com ... so I guess they are all guilty too.
P.S. I like the 403 error page on your website, but I felt the links at the bottom were a waste. It isn't exactly hard to find articles on the topic. Of course the selections you made, like those in your comment here, exudes a certian bias.
In the long run, I can see them suffering from less choice in developers too. After all, they are clearly not GNOME's target audience and many future contributors may move to something else which is less draconian about their urge to tweak.
What happens when/if the only development done on GNOME is commercially motivated and funded? A situation I don't think is as absurd as it may have once been.
Yeah, forget all that left-to-right corner eye scanning waffle. The above is the real usability issue.
Chances are when I've done something to call up a dialog box, I'll want to OK it 95+ times out of a 100. That is the option I want closest to my mouse pointer. Hell, pop that box up with the OK button two pixels away from the mouse, not in the middle of the screen, miles from my current pointer location.
Focusing on the eye issue and not the mouse issue reeks of academic short-sightedness. (Both puns intended.)
I struggle with this commonly expressed viewpoint. Aren't developers also users or are they developing on punch cards done by hand??? If their are usability issues, surely they would have encountered them often enough to be interested in correcting them. Isn't that where a lot of these new programs/forks come from?
You state that as users become developers they will create more "user happiness", but surely as soon as they become developers they will just start creating more "developer happiness". I think that the dividing line so many people want to draw simply doesn't exist.
Which projects in the FOSS community get more developer time is a completely different issue.
Yes, the real strength of the *nix family are all the small standalone "utilities" that can be put together through the use of pipes, etc.
Any UI (cli, Gnome, HTML, logfile, etc) should really just be a front-end to this framework. If a new utility is required, it should be designed to fit into this existing framework, not as a stand-alone monolithic program. An example of this approach is cdrecord, whilst there is a plethora of GUI cd burning apps most are back-ended by cdrecord and plenty of people also use it straight from the cli or in scripts.
Why aren't all applications built this way? Plenty of reasons, some people don't understand the strength of such an approach, despite the fact that they benefit from it already. It is also more work initially to create such a system, many developers are keen just to get their application working, never mind interoperability and seperation of function. Yes, this does result in a lot of duplication of effort, but there is nothing stopping someone from coming along later and splitting some of these FOSS monolithic applications up to make them more useful to the community as a whole.
Computers are brainless, this is why they can be cracked.
Using compilers to catch common programming errors is a good idea, but this will just see serious crackers targeting flaws not caught in current compilers.
Leading to new compilers ... leading to new cracks ... etc
If the only security guidance a programmer gets is from the programming language itself and it's compiler, then you have the brainless in charge of security...
Of course, there are also such things as OK warnings too, eg:
compiles as such:
As two is always larger then one, I feel secure in ignoring that warning.
Hmm, the ECODE tag seems to ignore leading whitespace, I bet the Python programmers are over-joyed about that. (There should be indentation on the lines following an if statement)
alias rm='rm -i'
...
"The seat of your pants" only works if you pants
Yep, and as soon as you throw in disk access, CPU and memory speed become almost redundant.
One advantage of over clocking is that is allows under clocking. For those of us without air conditioning in hot climates the ability to seasonally adjust heat output of the CPU is a bonus.
"Our new OS comes with a Longhorn(TM), once an hour it anal probes the user to confirm their identity. After the intial hour long ass reaming required for installation, most users appreciate the quick prostate massage required to keep everything working perfectly."
Where do you want to take it today?
All true.
Also, reliance on pre-compiled libraries,etc is just asking for dependency nightmares.