Debian is a great installation but has one of the more complicated, unfriendly installers out there.
That may be correct if you're not familiar with Linux, but if that is the case, one will find that reading the installation manual helps. It's a very detailed document that covers just about everything and every possibility; compare that to the quality of documentation that other distributions provide.
This first puts off people changing to Debian from other dists. and secondly stops linux newbies trying out Debian.
It's been said many times: Debian isn't for newbies. However, I recommend Debian to newbies if they want to learn Linux and not be hand-held through the installation and configuration processes. There's not much to learn when your idea of filesystem allocation is a bar graph, and you're not even presented with the names of the kernel modules you can choose.
Hopefully this installer turns out to be as easy to use as installing Redhat, but hopefully will stay non bloated and run on low spec machines.
It's not just about running on low spec machines. Keeping the installation simple (in terms of internal design, not UI) eliminates many problems and allows you to do many flexible things. Things break less. Hardware auto-detection and other forms of hand-holding is probably why my last Mandrake installation froze indefinitely (8.2, in VMware); I've had a similar experience with a recent Redhat version (on a non-emulated machine).
In short, I don't understand why the existing installer gets so much flak. I'll admit dselect stinks for too many reasons to list here, and I find tasksel to be over-generalized. Therefore, I recommend that people search for packages they want, and install them with apt-get after the installation procedure.
The only remaining challenge with installing Debian is that you understand concepts like partitions, filesystems, kernel modules, etc. If you do, the installation is a breeze (although I've been through it many times). If you don't, the installation manual covers all of this.
If your mail goes through a shell account somewhere along the way, I would definitely recommend trying it out.
It would be better to say "if your mail can go through a shell account...". Remember that you can run fetchmail on nearly any arbitrary Unix system, having it download your POP messages, messaging it in whatever ways you want. It can then be configured to forward the resulting mail onto somewhere else, or the mail could be retrieved from that system via POP or IMAP, if the host is configured to run such a daemon. If you're feeling particularly fancy, you could also use FTP, rsync, scp, or any of the other billion ways to transfer files over the net.
I've been meaning to do this and some other stuff with my domain, thoughtcrime.us. Not full shell access, but enough for an end-user to configure their choice of SpamAssassin, Bogofilter, TMDA, or any combination of the above, through a web interface. "Real soon now." Really.
Is this really necessary? I mean, come on, how hard is it to find spam for research? Most people get more spam than their Hotmail inbox can handle just for signing up for the account. All a researcher has to do is start clicking the "Remove Me" link in those emails and he or she will have more spam than he or she knows what to do with!
Wrong. I've been setting up bogus e-mail accounts on a domain created exlusively for spam research/testing. I've gone through at least a dozen "unsubscribe" links and never received one spam out of it to those test accounts. Perhaps the spammers only highlight records for people who "unsubscribe" when those people were in their database in the first place.
(The most spam I've received so far in one of these test accounts was from signing up to freefootfetishezine.com.)
This site also creates a problem in that only the spam posted to that site might be used for research. There might be millions of spam emails overlooked because they don't make it onto that site. Think of those poor spammers that won't get filtered:)
That doesn't make sense; they might not get a good sample of the spam if they don't solicit samples, just as much as they might not get a good sample if they do. It makes more sense that they would get more spam--and more diverse spam--from soliciting examples. Consider that submitted samples would come from all over the world, from a variety of sources, and in a variety of languages.
Wouldnt it be great if the submit email address was forwarded to someone's ex girlfriend? Thats the ultimate form of revenge...
Or... you could just send your own personal collection of 100-1000 spam messages over and over to the target, randomizing headers to avoid filtration.
If your scenario was correct, the spamarchive.org's mail servers would still be used to originate mail. Even if someone else sent it, it's SA.O's IP address that is making connections to the target's MX(s). And it also would consume SA.O's own bandwidth. Just like if you sent it yourself. (In fact, more of their bandwidth would be used for forwarding than originating, since you have to receive the message as well as send it.) That, uh, puts you in a bit of a bad situation with your ISP.
For those of us in the audience that didn't notice:
Särelind said the next generation of keyboards would use a new technology which would choose randomly between 256 available channels, and promised to send both Evjeberg and Helle a copy.
The "256 channels" isn't for their existing wireless keyboards, it's for their "next generation" models.
A bit shy of cryptographically secure, I'd say. Credit card numbers and personal information aren't all that's at stake; think about your passwords, PGP passphrases, etc.
I appreciate OpenBSD a lot; I use it on one system at home, and plan to do two more OpenBSD installations. There are some really cool things, like systrace, that aren't available for Linux yet.
That said, how can I trust that my copy of the "world's most secure operating system" hasn't been tampered with? OpenBSD does not sign their files with PGP, GnuPG, or OpenSSL (yes, the latter has been suggested on lists). OpenSSH does. Why can't OpenBSD?
The ports tree, the kernel source, and the rest of the base source (ports.tar.gz, srcsys.tar.gz, and src.tar.gz) don't even have published MD5 hashes (but the archetecture-specific binaries do). The source matters, because (aside from using potentially unstable snapshots binaries) you need the source to apply security patches as security issues are discovered.
For an OS with such a focus on cryptography "because we can", I don't see it being used where it counts. (I've written to the misc list, and only received one response. I've filed a bug report and have received none.)
Too bad the lameness filter (or whatever the piece is called) royally munged up any chance of validating that GPG signature. (For instance, I'd imagine there should be line breaks in that post.)
For those that aren't aware, it's pretty common to see long strings, like URLs, broken up by spaces by Slashdot's comment engine. Not to mention there is no <pre> facility; one has to use <code> and <br> elements. This makes pasting literal or fragile text, like GPG-signed text, very hard to do.
If you're real lucky, the lameness filter tells you something silly, like "your lines aren't long enough", or "you need more non-strange characters". Even in legitimate comments. (Isn't that what moderation is for?) Grumble.
Download that floppy image. Use Debian's bf2.4 floppy installation set (important). After you've booted and you're in the installer's menu system, go to a shell (Alt+F2), insert this floppy, and run 'extdisk'. I don't clearly recall what happens next, but it's pretty straightforward; you'll find modules for RAID and LVM, and configuration utilities. (I've only used this once.)
Of course, it'd be nice if this were part of the official installation system. Perhaps next release?
I've found some funny error messages running strings on different Linux kernels. One of the funniest I've seen has been:
Unable to start swapping: out of memory:-)
Because Slashdot employs a fascist check on comments, I couldn't insert a larger list of funny messages. (I tried, for about 20 minutes, and constantly got "you don't meet the minimum line length" or some similar message. Isn't moderation supposed to be the system to weed out genuinely annoying messages?) As I've been forced to do before, I'm putting the rest of the comment on my site (the last time, it was an e-mail that had too many "strange characters" in it).
This is an e-mail I've sent to the person with the 24-drive file server.
--
Hi,
I'm sure you're getting a lot of mail from Slashdot readers. I'm sure a large majority of it is Linux evangelism.
Please bear with me. I'd like to share some facts about running a file server like yours on Linux that you may find interesting.
First, I'll start with a few big reasons you may be interested:
LVM-the Logical Volume Manager. With LVM, you could combine all of these individual, small hard disks into what appears to be--and acts like--one large continuous file system. You can add more hard disks later to increase the size of the file system.
No drive letters.
That means you can have more than 24 hard disks. Linux drives are usually mapped onto the global filesystem (unless you use LVM to combine several hard disks).
For example, if you didn't use LVM to combine your drives, you could choose one disk for/home (personal settings and documents), one disk for/usr (most software), one disk for/var (miscellaneous program data files), a bunch of disks--one per directory (like "drive01", "drive02")--under a network file-serving directory, and one more disk for everything else not covered (the root directory).
Whether or not you use LVM, you can have much more than 24 hard disks. If you want to get really sophisticated, you can also spread your disks over a few computers, and combine them from
one central Linux server. This is called Network Block Devices.
The rest of this comment is available at this link. Appearantly my comment wasn't good enough for the lameness filter. "Reason: Please use fewer 'junk' characters." View the original comment as it was entered in the form here and tell me if there seems to be too many junk characters. (I tried changing '--' to '&emdash;', hoping that would help get past the lameness filter. '&emdash;' doesn't work anyway, apparently.)
Recently, I've been playing with LTSP, a project that makes setting up diskless X terminals with older (eg. Pentium 133) computers easy and practical with Linux. I've used it at work, and the performance of running everything over X with a relatively slow Pentium terminal is surprisingly good.
I've been thinking about getting an older Power Mac and upgrading to an 800MHz G4, and installing OS X on it. There's a couple things that are holding me back, but the most important thing I'd like to know is, is there any support for adding thin-client terminals to a Mac OS X system, like what LTSP provides for Linux?
I don't want to have to pay for expensive software to set up something like this. I'd like to be able to use old Pentium systems, rather than buy more Macs for thin-clients. LTSP uses {xdm,gdm,kdm,wdm}, so there is a different desktop session viewable on each terminal. With whatever is possible with Mac OS X, I don't want one shared desktop session between all the terminals (like VNC).
As a last resort to the OS X idea, I've thought about installing GNOME, Sawfish, GDM, and other desktop-ish programs I would usually use on my Linux box, and setting up something similar to LTSP on the future Mac OS X box. Essentially, I would have what looks like a Linux desktop on the X terminals, but powered by OS X. I'd really prefer OS X's native GUI to X/GNOME/Sawfish, though.
I've done some Googling, but the closest I could find to "thin-clients" with OS X was netbooting OS X on older iMacs, which is far from what I want. Does anyone have any suggestions for software or projects I could look into?
GnuPG is intended to replace the PGP encryption program, not the entire PGP product line.
Indeed. I am glad GnuPG doesn't attempt to be an all-in-one mega-security-solution. Many small programs/projects that fill their niche is an important software philosophy that seems to be ignored in the Windows world.
On a related note, wouldn't it seem to you that the fax machine software gurus know about your "Mobeus Fax"? [emphesis added]
A Moebius strip/loop is one which can be constructed with a strip of paper, arranging it in a loop, and twisting one of the ends before attaching it to the other end. In this formation, tracing your finger around one side of the loop, you will eventually find your finger on the other side of the loop.
The described (and classic) black paper loop trick is not a Moebius loop (you could make it be one, but that would be unnecessary effort).
Your point about the use of PCs with faxmodems is a good one, though. This (admittedly offtopic) post was just meant to point out your misconception.
Why don't you learn exactly what this hardware is and what it does before you make silly statements like the above?
Is this hardware so powerful and awe-inspiring that no self-respecting programmer lay a finger on writing a device driver (or set of, if that's the case)?
Why don't you explain why it's impossible or infeasible for a group of people to get together to write complete Linux support for it? Why don't you explain how powerful or different it is, or whatever sets it apart, that makes it so different and such an undertaking to write support for?
While we're at it, do you think anyone is ever going to write a good Linux office app? How about a useful desktop environment? A modern web browser?
Will there ever be support for any hardware other than the most low-level components in Linux? USB? Firewire? Various 3D-accelerated video cards?
Will we ever see a free Unix operating system? Even if we get a kernel, you'll need to write tons of userland utilities, etc etc.
Do you think pigs may start flying this season?
(Hint: I'm pointing out all this stuff because hackers have gone out of their way to work together and contribute for everyone by writing software. Useful software. Real software. Free software. If everyone had your attitude, we'd be nowhere.)
sig2dot, the GPG signature relationship grapher
on
RPM Dependency Graph
·
· Score: 2, Interesting
sig2dot generates plotting data from the signatures in your GPG keyring; this data can be rendered by springgraph or graphvis. Many pretty sample plots on the page.
Just create some garbage filesystem entries on an unused hard drive. A 430mb hard drive should be plenty.:D
Who says they have to be actual hard drives?
You could write a program to simulate an NFS server and program it to act like it a has a big filesystem full of MP3s. It'd be completely in user-land software (with the exception of mounting the NFS filesytem) and require no kernel modifications or spare physical device.
That's how CFS works (by being an NFS server to serve data, not by serving bogus data).
They're common enough that you can get them at Office Depot. They go for $200 there; I'm sure you could get them significantly cheaper elsewhere (eBay?).
The unit my company bought had an RS-232 interface for computer control, and allowed you to program your own graphics characters. Unfortunately, our LCD sign project has been sitting on our back-burner for some number of months now.
Since I don't have anything better to contribute... =)
Here's the oldest copy of Slashdot that seemed to work on the Wayback Machine: Nov. 11, 1998. It doesn't look that much different design-wise, but the atmosphere of the comments seems to be significantly different.
I'll probably take a karma hit for this one, but...
"the GNU Project starts developing an operating system, and years later Linus Torvalds adds one important piece. The GNU Project says, 'Please give our project equal mention,' but Linus says, 'Don't give them a share of the credit; call the whole thing after my name alone!' [emphasis added]
I don't recall reading about Linus Torvalds saying anything like this. The closest thing that comes to mind is him saying something along the lines of "RMS can call Linux whatever he wants to call it".
I consider this to be somewhat defamatory, and a quick Google search didn't turn up much to validate RMS's pseudo-quote. Can anyone clarify?
To reduce the harshness of the LEDs, you could probably remove them from the case and use something like a green scouring pad (or the back of most kitchen sponges) to dull out the LED's surfaces and help diffuse the light.
If the plastic is too hard, or if that's not good enough, put a resistor in the LED circuits. (However, I don't know crap about electronics and could probably get something as trivial as that wrong, so if I am wrong, please correct me.)
PATRIOTISM, n. Combustible rubbish read to the torch of any one
ambitious to illuminate his name.
In Dr. Johnson's famous dictionary patriotism is defined as the
last resort of a scoundrel. With all due respect to an enlightened
but inferior lexicographer I beg to submit that it is the first.
If you start a process on a node and that process opens a socket, opens a file, or uses shared memory, then that process is stuck on that node.
From what I gathered from the OpenMosix Internals paper (which is very informative, BTW), when a process that has been migrated to another machine wants to perform network or file I/O, it communicates over the network to the UHN (Unique Home-Node), where the actual I/O operation will occur. The same goes for machine-specific system calls (gettimeofday() was used as an example).
"One drawback of the deputy approach is the extra overhead in the execution of system calls. Additional overhead is incurred on file and network access operations. For example, all network links (sockets) are created in the UHN, thus imposing communication overhead if the processes migrate away from the UHN." There's probably a more specific quote in the paper.
You seem to be right about processes using shared memory: "For applications using shared memory, such as Web servers or database servers, there will not be any benefit from OpenMosix because all processes accessing said shared memory must resided on the same node."
That may be correct if you're not familiar with Linux, but if that is the case, one will find that reading the installation manual helps. It's a very detailed document that covers just about everything and every possibility; compare that to the quality of documentation that other distributions provide.
It's been said many times: Debian isn't for newbies. However, I recommend Debian to newbies if they want to learn Linux and not be hand-held through the installation and configuration processes. There's not much to learn when your idea of filesystem allocation is a bar graph, and you're not even presented with the names of the kernel modules you can choose.
It's not just about running on low spec machines. Keeping the installation simple (in terms of internal design, not UI) eliminates many problems and allows you to do many flexible things. Things break less. Hardware auto-detection and other forms of hand-holding is probably why my last Mandrake installation froze indefinitely (8.2, in VMware); I've had a similar experience with a recent Redhat version (on a non-emulated machine).
In short, I don't understand why the existing installer gets so much flak. I'll admit dselect stinks for too many reasons to list here, and I find tasksel to be over-generalized. Therefore, I recommend that people search for packages they want, and install them with apt-get after the installation procedure.
The only remaining challenge with installing Debian is that you understand concepts like partitions, filesystems, kernel modules, etc. If you do, the installation is a breeze (although I've been through it many times). If you don't, the installation manual covers all of this.
Anything I'm overlooking?
It would be better to say "if your mail can go through a shell account...". Remember that you can run fetchmail on nearly any arbitrary Unix system, having it download your POP messages, messaging it in whatever ways you want. It can then be configured to forward the resulting mail onto somewhere else, or the mail could be retrieved from that system via POP or IMAP, if the host is configured to run such a daemon. If you're feeling particularly fancy, you could also use FTP, rsync, scp, or any of the other billion ways to transfer files over the net.
I've been meaning to do this and some other stuff with my domain, thoughtcrime.us. Not full shell access, but enough for an end-user to configure their choice of SpamAssassin, Bogofilter, TMDA, or any combination of the above, through a web interface. "Real soon now." Really.
Wrong. I've been setting up bogus e-mail accounts on a domain created exlusively for spam research/testing. I've gone through at least a dozen "unsubscribe" links and never received one spam out of it to those test accounts. Perhaps the spammers only highlight records for people who "unsubscribe" when those people were in their database in the first place.
(The most spam I've received so far in one of these test accounts was from signing up to freefootfetishezine.com.)
That doesn't make sense; they might not get a good sample of the spam if they don't solicit samples, just as much as they might not get a good sample if they do. It makes more sense that they would get more spam--and more diverse spam--from soliciting examples. Consider that submitted samples would come from all over the world, from a variety of sources, and in a variety of languages.
Or... you could just send your own personal collection of 100-1000 spam messages over and over to the target, randomizing headers to avoid filtration.
If your scenario was correct, the spamarchive.org's mail servers would still be used to originate mail. Even if someone else sent it, it's SA.O's IP address that is making connections to the target's MX(s). And it also would consume SA.O's own bandwidth. Just like if you sent it yourself. (In fact, more of their bandwidth would be used for forwarding than originating, since you have to receive the message as well as send it.) That, uh, puts you in a bit of a bad situation with your ISP.
Pretty silly idea.
The "256 channels" isn't for their existing wireless keyboards, it's for their "next generation" models.
A bit shy of cryptographically secure, I'd say. Credit card numbers and personal information aren't all that's at stake; think about your passwords, PGP passphrases, etc.
That said, how can I trust that my copy of the "world's most secure operating system" hasn't been tampered with? OpenBSD does not sign their files with PGP, GnuPG, or OpenSSL (yes, the latter has been suggested on lists). OpenSSH does. Why can't OpenBSD?
The ports tree, the kernel source, and the rest of the base source (ports.tar.gz, srcsys.tar.gz, and src.tar.gz) don't even have published MD5 hashes (but the archetecture-specific binaries do). The source matters, because (aside from using potentially unstable snapshots binaries) you need the source to apply security patches as security issues are discovered.
For an OS with such a focus on cryptography "because we can", I don't see it being used where it counts. (I've written to the misc list, and only received one response. I've filed a bug report and have received none.)
For those that aren't aware, it's pretty common to see long strings, like URLs, broken up by spaces by Slashdot's comment engine. Not to mention there is no <pre> facility; one has to use <code> and <br> elements. This makes pasting literal or fragile text, like GPG-signed text, very hard to do.
If you're real lucky, the lameness filter tells you something silly, like "your lines aren't long enough", or "you need more non-strange characters". Even in legitimate comments. (Isn't that what moderation is for?) Grumble.
Thanks, Slashdot!
</rant>
Download that floppy image. Use Debian's bf2.4 floppy installation set (important). After you've booted and you're in the installer's menu system, go to a shell (Alt+F2), insert this floppy, and run 'extdisk'. I don't clearly recall what happens next, but it's pretty straightforward; you'll find modules for RAID and LVM, and configuration utilities. (I've only used this once.)
Of course, it'd be nice if this were part of the official installation system. Perhaps next release?
Because Slashdot employs a fascist check on comments, I couldn't insert a larger list of funny messages. (I tried, for about 20 minutes, and constantly got "you don't meet the minimum line length" or some similar message. Isn't moderation supposed to be the system to weed out genuinely annoying messages?) As I've been forced to do before, I'm putting the rest of the comment on my site (the last time, it was an e-mail that had too many "strange characters" in it).
--
Hi,
I'm sure you're getting a lot of mail from Slashdot readers. I'm sure a large majority of it is Linux evangelism.
Please bear with me. I'd like to share some facts about running a file server like yours on Linux that you may find interesting.
First, I'll start with a few big reasons you may be interested:
That means you can have more than 24 hard disks. Linux drives are usually mapped onto the global filesystem (unless you use LVM to combine several hard disks).
For example, if you didn't use LVM to combine your drives, you could choose one disk for /home (personal settings and documents), one disk for /usr (most software), one disk for /var (miscellaneous program data files), a bunch of disks--one per directory (like "drive01", "drive02")--under a network file-serving directory, and one more disk for everything else not covered (the root directory).
The rest of this comment is available at this link. Appearantly my comment wasn't good enough for the lameness filter. "Reason: Please use fewer 'junk' characters." View the original comment as it was entered in the form here and tell me if there seems to be too many junk characters. (I tried changing '--' to '&emdash;', hoping that would help get past the lameness filter. '&emdash;' doesn't work anyway, apparently.)
And?
I've been thinking about getting an older Power Mac and upgrading to an 800MHz G4, and installing OS X on it. There's a couple things that are holding me back, but the most important thing I'd like to know is, is there any support for adding thin-client terminals to a Mac OS X system, like what LTSP provides for Linux?
I don't want to have to pay for expensive software to set up something like this. I'd like to be able to use old Pentium systems, rather than buy more Macs for thin-clients. LTSP uses {xdm,gdm,kdm,wdm}, so there is a different desktop session viewable on each terminal. With whatever is possible with Mac OS X, I don't want one shared desktop session between all the terminals (like VNC).
As a last resort to the OS X idea, I've thought about installing GNOME, Sawfish, GDM, and other desktop-ish programs I would usually use on my Linux box, and setting up something similar to LTSP on the future Mac OS X box. Essentially, I would have what looks like a Linux desktop on the X terminals, but powered by OS X. I'd really prefer OS X's native GUI to X/GNOME/Sawfish, though.
I've done some Googling, but the closest I could find to "thin-clients" with OS X was netbooting OS X on older iMacs, which is far from what I want. Does anyone have any suggestions for software or projects I could look into?
Indeed. I am glad GnuPG doesn't attempt to be an all-in-one mega-security-solution. Many small programs/projects that fill their niche is an important software philosophy that seems to be ignored in the Windows world.
A Moebius strip/loop is one which can be constructed with a strip of paper, arranging it in a loop, and twisting one of the ends before attaching it to the other end. In this formation, tracing your finger around one side of the loop, you will eventually find your finger on the other side of the loop.
The described (and classic) black paper loop trick is not a Moebius loop (you could make it be one, but that would be unnecessary effort).
Your point about the use of PCs with faxmodems is a good one, though. This (admittedly offtopic) post was just meant to point out your misconception.
Is this hardware so powerful and awe-inspiring that no self-respecting programmer lay a finger on writing a device driver (or set of, if that's the case)?
Why don't you explain why it's impossible or infeasible for a group of people to get together to write complete Linux support for it? Why don't you explain how powerful or different it is, or whatever sets it apart, that makes it so different and such an undertaking to write support for?
Will there ever be support for any hardware other than the most low-level components in Linux? USB? Firewire? Various 3D-accelerated video cards?
Will we ever see a free Unix operating system? Even if we get a kernel, you'll need to write tons of userland utilities, etc etc.
Do you think pigs may start flying this season?
(Hint: I'm pointing out all this stuff because hackers have gone out of their way to work together and contribute for everyone by writing software. Useful software. Real software. Free software. If everyone had your attitude, we'd be nowhere.)
Ever wondered what a plot of a portion of the PGP web of trust would look like? Here it is.
sig2dot generates plotting data from the signatures in your GPG keyring; this data can be rendered by springgraph or graphvis. Many pretty sample plots on the page.
Who says they have to be actual hard drives?
You could write a program to simulate an NFS server and program it to act like it a has a big filesystem full of MP3s. It'd be completely in user-land software (with the exception of mounting the NFS filesytem) and require no kernel modifications or spare physical device.
That's how CFS works (by being an NFS server to serve data, not by serving bogus data).
The unit my company bought had an RS-232 interface for computer control, and allowed you to program your own graphics characters. Unfortunately, our LCD sign project has been sitting on our back-burner for some number of months now.
Here's the oldest copy of Slashdot that seemed to work on the Wayback Machine: Nov. 11, 1998. It doesn't look that much different design-wise, but the atmosphere of the comments seems to be significantly different.
The whole list.
Same story for all the MX records for vatican.va.
I don't recall reading about Linus Torvalds saying anything like this. The closest thing that comes to mind is him saying something along the lines of "RMS can call Linux whatever he wants to call it".
I consider this to be somewhat defamatory, and a quick Google search didn't turn up much to validate RMS's pseudo-quote. Can anyone clarify?
If the plastic is too hard, or if that's not good enough, put a resistor in the LED circuits. (However, I don't know crap about electronics and could probably get something as trivial as that wrong, so if I am wrong, please correct me.)
From what I gathered from the OpenMosix Internals paper (which is very informative, BTW), when a process that has been migrated to another machine wants to perform network or file I/O, it communicates over the network to the UHN (Unique Home-Node), where the actual I/O operation will occur. The same goes for machine-specific system calls (gettimeofday() was used as an example).
"One drawback of the deputy approach is the extra overhead in the execution of system calls. Additional overhead is incurred on file and network access operations. For example, all network links (sockets) are created in the UHN, thus imposing communication overhead if the processes migrate away from the UHN." There's probably a more specific quote in the paper.
You seem to be right about processes using shared memory: "For applications using shared memory, such as Web servers or database servers, there will not be any benefit from OpenMosix because all processes accessing said shared memory must resided on the same node."