What we need to do is come up with a way to stop this not on our end, but by looking at as a social problem or making it non-worthwhile to the spammers. If nobody ever responded to spam, spammer wouldn't bother.
Hey, an automatic 10 years in Guantanamo for anyone convicted of replying to spam. Come to think about it, that would be a solution:-)
One approach I'd like to see discussed is as follows:
"Unsolicited bulk email messages" are allowed.
However, as a condition, all the addresses contained in such amessage (SMTP From:, Return-path:, From:, Reply-To:, SMTP server used, and all URLs in the body) must be from the same domain .
People may redirect any mail they consider non-compliant to (e.g.) abuse@their.isp. ISPs poll the results.
Any SMTP server associated with more than N complaints gets blocked.
If you don't mind closed source, paying through the nose ($145), and OS X
Ah, if we're talking Mac OS X then you might want to look at VoodooPad. Quite a bit cheaper (has a free version actually), and seems to do much of what the poster wants.
Tancredo for president in 2008...Save our industry! [tancredo.org]
Uh, oh. So this guy is, quote, "Leading Immigration Reform". His "plan would result in zero net legal immigration for five years". He "believe[s] that President Bush is tremendously capable, and [is] immensely thankful that he is our president as we prosecute the war on terror".
Sorry man, xenophobia only creates problems, it never solved any. Where does you sense of entitlement come from?
RELEASE The Linux man page maintainer proudly announces. ..
man-pages-1.65.tar.gz - man pages for Linux
POSIX This release is the first to contain the POSIX 1003.1-2003 man pages. The directories man0p, man1p, man3p contain descriptions of the headers, the utilities, and the functions documented in that standard.
Permission to distribute these POSIX man pages has just been obtained, and the pages in man0p, man1p, man3p were derived from the POSIX html pages by some silly conversion script. No doubt the result is still full of flaws, and all of this can be much improved. Corrections, scripts, etc. are welcome - aeb@<snip>.
In order to use this, put in {/usr/share/misc/}man.conf{ig} or so your favourite order of looking at these pages, for example, MANSECT 1p:1:8:0p:3p:2:3:4:5:6:7:9:tcl:n:l:p:o or set the MANSECT environment variable.
OTHER PAGES The remaining pages are most of the section 2, 3, 4, 5, 7 man pages for Linux, and in addition section 1 man pages for the fileutils-4.0 utilities, and section 5 and 8 man pages for the timezone utilities.
[The latter were taken from ftp://elsie.nci.nih.gov/pub/tzcode2001a.tar.gz.] [The section 3 man pages for the db routines have been taken from ftp://ftp.terra.net/pub/sleepycat/db.1.86.tar.gz.] [The rpc man pages were taken from the 4.4BSD-Lite CDROM.]
Section 1 = user commands (intro, and pages not maintained by FSF) Section 2 = system calls Section 3 = libc calls Section 4 = devices (e.g., hd, sd) Section 5 = file formats and protocols (e.g., wtmp,/etc/passwd, nfs) Section 6 = games (intro only) Section 7 = conventions, macro packages, etc. Section 8 = system administration (intro only)
Usually, there are no section 1, 6 and 8 man pages because these should be distributed with the binaries they are written for. Sometimes Section 9 is used for man pages describing parts of the kernel.
Note that only Section 2 is rather complete, but Section 3 contains several hundred man pages. If you want to write some man pages, please do so and mail them to aeb@<snip>.
The following people (listed in alphabetical order by first name) wrote, edited, or otherwise contributed to this project:
<snip>
Copyright information:
For the POSIX pages permission to distribute was given by IEEE and the Open Group, see POSIX-COPYRIGHT.
For the remaining pages, please note that these man pages are distributed under a variety of copyright licenses. Although these licenses permit free distribution of the nroff sources contained in this package, commercial distribution may impose other requirements (e.g., acknowledgement of copyright or inclusion of the raw nroff sources with the commercial distribution). If you distribute these man pages commercially, it is your responsibility to figure out your obligations. (For many man pages, these obligations require you to distribute nroff sources with any pre-formatted man pages that you provide.) Each file that contains nroff source for a man page also contains the author(s) name, email address, and copyright notice.
Well... here are counterarguments, I can only say that I'll read your replies with genuine interest.
Ah... no. The [icon] being clicked stands for typing the program name and hitting enter. It is the GUI equivalent of typing the program name, NOT the program path.
No! The file manager shows the icon as residing in some directory. Even though the icon and executable may be distinct files, clicking the icon is done in some directory, so it entails giving the system a full path. From there it damn well ought to be able to get at the executable.
Suppose my browser is Mozilla. If I say "mozilla" on the command line, mozilla opens.
And here you speak again of launching GUI apps from the command line. Who on earth does this? If you're gonna launch a GUI application it means you are in the GUI, where the natural way to launch something is by clicking on it.
Okay, you might still want to also be able to launch it from the command line, or some script. Well, app bundles let you do this: $ open/Applications/Omniweb.app. Yes, in current implementations this requires giving the.app's full path. But if you really wanted, nothing would be simpler than to implement a special PATH for.apps, that open would consult. The reason it's not been done, I venture, is that nobody ever felt the need.
You might bring in MANPATH (etc.). Again I would argue its utter irrelevance in the GUI, where help is done by giving each app a help menu. The GUI gives users more hooks than just a command prompt, so we use that.
This is flexible, it allows Mozilla to be stored ANYWHERE in my PATH without the launcher breaking. Suppose I want to grab a CVS build of Mozilla that I've heard has a Really Cool Feature. Excellent! All I need to do is just install it in $HOME and have the installer place a link called "mozilla" in ~/bin, and suddenly... My launcher launches the new version?! Wow! What an amazing feature. A launcher the program did not create, and has no knowledge of, can track new versions?! I'm impressed.
You must never have "installed" a Mac Mozilla build. Downloading it gives you one double-clickable object Mozilla.app, which you can drag and drop and double click anywhere AT ALL. No hard coded symlink, no "registration" with the start menu, no rpm database, no registry, no special launcher, no nothing.
The file manager (Finder) is the launcher. That way (and I don't see another...) "installs" become simple drag & drops, and GUI applictions are automatically relocatable wherever the user wants, through the GUI. Browsing to Mozilla.app is no pain because it is where you chose to put it. Two Mozilla builds can coexist just fine. How am I supposed to be impressed by a symlink that needs updating as soon as I move anything?
App directory bundles are just a (fairly ugly) hack to get around the same problem.
I could recite any number of examples: if you type "Ctrl-A Ctrl-Return" to mark all posts in a newsgroup as read, Mozilla will instead choose to open a couple of hundred windows
To change some settings in Mozilla you should of course look under "Edit" in the menu system, and not under "Tools" like in all other programs in the Windows world.
In StarOffice, the keyboard combination to insert a non-breaking space is "Ctrl-Space", rather than Word's "Ctrl-Shift-Space". Please, somebody, why?
Let's see...
Because many of those conventions (e.g. Netscape's) existed before MS chose to take a different route for no reason (other than maybe lock-in)?
Because MS often made brain-damaged choices? They essentially changed the Mac's well-researched ones. Guess why? Precisely for the sake of being different, as look & feel lawsuits were (alas) looming. Examples:
Put main menu at the bottom, not top.
Put application menus inside windows, not atop the screen (insert usual Fitt's law rant).
Add invisible (contextual) menus everywhere, forcing beginners to master two mouse buttons.
Make applications not relocatable, then "cure" the resulting C:\Program Files mess by duplicating everything in a "Start Menu".
Move all dialog's "Confirm" button to the left, not right.
Use control, not another key, as modifier key in GUI apps (so what happens in the GUI app "xterm"?)
Top quote instead of bottom quote in mail.
etc., etc.
Why, yes why duplicate this disaster of an interface? Blending Unix with a better desktop is eminently possible -- cf. NeXT or OS X, which aren't known to give switchers any problems whatsoever.
don't mix the GUI apps into the same dir with the command line ones.
Absolutely. Wherever you put double-clickable apps for GUI users, don't clobber that place with stuff that's not meant to be double-clicked. The whole "start menu" joke is just an ugly workaround to separate the weed from the chaff -- at the expense of people no longer knowing where anything actually is.
It's my opinion that you should be able to install an application virtually anywhere, and there should be a standard way to update the PATH enviroment variable
No! The $PATH mechanism is a good one on the command line, where you want the ability to launch anything from the shell prompt, independent of what working dir you are in. In the GUI that's not needed: when you launch an app by double-clicking an icon you've already found it; from there the OS should damn well be able to find the executable!
Just do it with app dirs (aka bundles), like ROX and NeXT and GNUstep and OS X. Then users can install GUI applications by drag and drop and move them around however they wish. (And, I should probably add, this in no way precludes the apps from sharing libs or frameworks; only those need be in hard-coded locations, which users need not worry about.)
The misunderstanding comes from the fact that you are reasoning in terms of electrons, which indeed are fermions. They are the appropriate objects to consider when computing energy levels in atoms or energy bands in solids, which is the traditional subject that your textbooks are talking about.
But here the relevant objects are bosons, namely, the Helium atoms in a 4He crystal -- or more precisely the gaps in this crystal, which you may formally regard as 'anti' Helium atoms. (Cf. the article: "the regular crystal lattice of atoms is full of gaps, called vacancies, that move about.")
The anti-object of a boson is again a boson, so these vacancies are bosons. Technically this means that an assembly of them doesn't obey Fermi-Dirac statistics (like electrons do), but Bose-Einstein statistics.
My point above was that it is this brand of statistics, and not at all the Heisenberg uncertainty principle, which explains that the vacancies tend to move "all together".
(From the article: in "a superfluid, the laws of quantum mechanics make all the atoms move coherently, like a regiment of soldiers. In supersolid helium, all of the vacancies in the crystal likewise start to move coherently, which means that waves can progress through the lattice. The onset of this coherent motion is called Bose-Einstein condensation.")
Hope that clears it up for you. Best of luck on the exam:)
the Heisenberg uncertainty Principle (...) accounts for the fact that even at absolute zero, there are some fluctuations of particles, called quantum fluctuations wich do never freeze out. When a superfluid appears this means that the atoms in it move all together.
Heisenberg implies that they (still) move, but has nothing to do with the fact they move all together. This latter fact is because helium atoms can all fall into the "same" lowest-energy state, because they are bosons and so do not obey the Pauli exclusion principle.
"In this special issue, I cover where Panther stands, why the Dock (still) sucks, and how you can trick out your personal Macintosh today to turn it into a high-productivity machine.
Make Your Mac a Monster Machine How to equip your Mac today with a handful of simple shareware add-ons to turn give your supercomputer the super-interface it deserves. Panther: The Good, the Bad, and the Ugly An in-depth look at Apple's OS X 10.3 release. What's working, what's not, and what Apple needs to do about it.
Top 9 Reasons Why the Dock Still Sucks The Dock is the most notorious interface element ever to appear on a Macintosh, the first one that is provably bad in almost every way. I systematically review why it is still bad and explain why Apple hangs onto it anyway."
("I wrote it because of the lawsuit" smoking-gun type statement)
Thanks. My impression is that if such a stament exists it would be quoted here, whereas we only get this:
M: What is your opinion of 386BSD?
L: Actually, I have never even checked 386BSD out; when I started on Linux it wasn't available (...), and when 386BSD finally came out, Linux was already in a state where it was so usable that I never really thought about switching. If 386BSD had been available when I started on Linux, Linux would probably never had happened.
Slashdot Mirror
Hey, an automatic 10 years in Guantanamo for anyone convicted of replying to spam. Come to think about it, that would be a solution :-)
One approach I'd like to see discussed is as follows:
I might agree with you (I think you mean "second to none") if only they'd bother to compile their drivers for PowerBooks
(or then, rewrap the already included OS X drivers).
Ah, if we're talking Mac OS X then you might want to look at VoodooPad. Quite a bit cheaper (has a free version actually), and seems to do much of what the poster wants.
The article says: "RedHat has a far greater number of sites but a slower growth rate, and actually fell this month"
Tancredo for president in 2008...Save our industry! [tancredo.org]
Uh, oh. So this guy is, quote, "Leading Immigration Reform". His "plan would result in zero net legal immigration for five years". He "believe[s] that President Bush is tremendously capable, and [is] immensely thankful that he is our president as we prosecute the war on terror".
Sorry man, xenophobia only creates problems, it never solved any. Where does you sense of entitlement come from?
Culturally challenged mod is missing the obvious.
I'm not familiar with Qt. Could anyone sketch to what extent this model is like or unlike Cocoa's "outlets" and "connections"?
(Since this is not very informative:)
Elsevier: Mr. Russell, I sue you for quoting my copyrighted database.
B. Russell: Oh, I see, you claim to be the copyright holder. Do you have proof?
Elsevier: Easy. Here is the relevant quote from the U.S. copyright registry...
B. Russell: Gotcha! You can't do that! :-)
At any rate, it has just become dead easy to tell if the dork who asks you out is Slashdot reader.
Well the pun would be Tukey's, I suppose.
(I take it you didn't mean this problem of the French with bits and bytes...)
Okay, you might still want to also be able to launch it from the command line, or some script. Well, app bundles let you do this: $ open /Applications/Omniweb.app. Yes, in current implementations this requires giving the .app's full path. But if you really wanted, nothing would be simpler than to implement a special PATH for .apps, that open would consult. The reason it's not been done, I venture, is that nobody ever felt the need.
You might bring in MANPATH (etc.). Again I would argue its utter irrelevance in the GUI, where help is done by giving each app a help menu. The GUI gives users more hooks than just a command prompt, so we use that.
You must never have "installed" a Mac Mozilla build. Downloading it gives you one double-clickable object Mozilla.app, which you can drag and drop and double click anywhere AT ALL. No hard coded symlink, no "registration" with the start menu, no rpm database, no registry, no special launcher, no nothing.The file manager (Finder) is the launcher. That way (and I don't see another...) "installs" become simple drag & drops, and GUI applictions are automatically relocatable wherever the user wants, through the GUI. Browsing to Mozilla.app is no pain because it is where you chose to put it. Two Mozilla builds can coexist just fine. How am I supposed to be impressed by a symlink that needs updating as soon as I move anything?
Ugly how? They work.To change some settings in Mozilla you should of course look under "Edit" in the menu system, and not under "Tools" like in all other programs in the Windows world.
In StarOffice, the keyboard combination to insert a non-breaking space is "Ctrl-Space", rather than Word's "Ctrl-Shift-Space". Please, somebody, why?
Let's see...
- Because many of those conventions (e.g. Netscape's) existed before MS chose to take a different route for no reason (other than maybe lock-in)?
- Because MS often made brain-damaged choices? They essentially changed the Mac's well-researched ones. Guess why? Precisely for the sake of being different, as look & feel lawsuits were (alas) looming. Examples:
- Put main menu at the bottom, not top.
- Put application menus inside windows, not atop the screen (insert usual Fitt's law rant).
- Add invisible (contextual) menus everywhere, forcing beginners to master two mouse buttons.
- Then duplicate everything in cryptic toolbars.
- Make applications not relocatable, then "cure" the resulting C:\Program Files mess by duplicating everything in a "Start Menu".
- Move all dialog's "Confirm" button to the left, not right.
- Use control, not another key, as modifier key in GUI apps (so what happens in the GUI app "xterm"?)
- Top quote instead of bottom quote in mail.
- etc., etc.
Why, yes why duplicate this disaster of an interface? Blending Unix with a better desktop is eminently possible -- cf. NeXT or OS X, which aren't known to give switchers any problems whatsoever.Just do it with app dirs (aka bundles), like ROX and NeXT and GNUstep and OS X. Then users can install GUI applications by drag and drop and move them around however they wish. (And, I should probably add, this in no way precludes the apps from sharing libs or frameworks; only those need be in hard-coded locations, which users need not worry about.)
Just ran http://www.catb.org/~esr/comparator/comparator.ht
Yes, you are correct.
No the helium crystal doesn't flow, it is solid. It's the vacancies in it that can flow or move in waves.
The misunderstanding comes from the fact that you are reasoning in terms of electrons, which indeed are fermions. They are the appropriate objects to consider when computing energy levels in atoms or energy bands in solids, which is the traditional subject that your textbooks are talking about.
But here the relevant objects are bosons, namely, the Helium atoms in a 4He crystal -- or more precisely the gaps in this crystal, which you may formally regard as 'anti' Helium atoms. (Cf. the article: "the regular crystal lattice of atoms is full of gaps, called vacancies, that move about.")
The anti-object of a boson is again a boson, so these vacancies are bosons. Technically this means that an assembly of them doesn't obey Fermi-Dirac statistics (like electrons do), but Bose-Einstein statistics. My point above was that it is this brand of statistics, and not at all the Heisenberg uncertainty principle, which explains that the vacancies tend to move "all together".
(From the article: in "a superfluid, the laws of quantum mechanics make all the atoms move coherently, like a regiment of soldiers. In supersolid helium, all of the vacancies in the crystal likewise start to move coherently, which means that waves can progress through the lattice. The onset of this coherent motion is called Bose-Einstein condensation.")
Hope that clears it up for you. Best of luck on the exam :)
Heisenberg implies that they (still) move, but has nothing to do with the fact they move all together. This latter fact is because helium atoms can all fall into the "same" lowest-energy state, because they are bosons and so do not obey the Pauli exclusion principle.
Yes.
Workaround: command-drag the object. (Works from the Dock but not from the Finder side bar, though.)
Thanks. My impression is that if such a stament exists it would be quoted here, whereas we only get this: