I rather like the RSS. It's suitably aggressive to catch a lot of spam, and has several advantages over ORBS:
1) It doesn't list multi-level relays[*] -- I count this as an advantage, because it cuts out the "block an entire ISP because of a few rogue customer" effect.
2) They can actually produce a spam for each listing, something that ORBS cannot do in most cases.
3) [related to (2)] When explaining to a (non-)admin why you are blocking their mail, you can point them to an ACTUAL SPAM INCIDENT and say "here's why."
4) [also related to (2)] There are no "manual listings" on the RSS -- every RSS-listed host is actually an open relay. Many ORBS-listed hosts are not open relays.... perhaps even most, with the multiple/16s of AboveNet listed.
[*] I really dislike the way ORBS handles this problem. Basically, if you run a (closed) relay, you apparently need to subscribe that relay to ORBS in order to keep it off of ORBS. Oh, yeah... there is one other alternative: you can enforce a no-servers policy, or (ack!) filter all incoming port 25 traffic to customers.
They don't even require a spam incident -- they will launch this "test" against any host that is nominated REGARDLESS OF WHETHER IT HAS EVER SENT SPAM.
I suspect that this is why ORBS is still accused of scanning for open relays. Some spammer is probably "nominating" whole IP blocks so they can check the ORBS list later. Since nobody smart uses ORBS, they now have a list of open relays, which are not on any real blacklist.
Either this is the case, the ORBS kiddies actually *are* doing scans, or AboveNET and many other ISPs are lying when they claim ORBS is scanning them.
That's a "log-structured" filesystem, not a journalling filesystem. They're very slightly related (in that both of them are filesystems).
The difference is a journalling filesystem can maintain decent read performance, because journalling does not confine the layout of data on the disk, while log-structuring does. Log-structured filesystems cannot get past the file fragmentation problem, without wasting tons of disk bandwidth.
Some System V advocates had created a "benchmark" that proved that FFS (with 4k blocks and 1k fragments) was faster than their 1k-blocksize filesystem. They would create a file, and grow it by 1k blocks. This cause FFS to grow the file's last fragment (which often involves a copy) on every update. Of course, it was the optimal case for their filesystem. It was this crooked benchmark that lead to the tunefs -o (space|time) option. '-o time' will upgrade a fragment to a full 4k block, wasting a bit of space, but saving time -- it is quite useful for constantly-growing smallish files, e.g. logfiles. (and, of course, for running crooked benchmarks;-)
Also, logging filesystems and journalling filesystems are *very* different. Loggin filesystems pretty much have to leave file blocks scattered throughout the disk, or waste disk bandwidth relocating them (to the head of the log, of course). Journalling filesystems, however, can choose whatever file layout they please, so they can optimise this layout for good read performance. The FreeBSD LFS is not even alpha -- it's past that stage, nobody is working on it, and I think it might even be in the CVS attic... yep, no code there anymore. I think the LFS approach is pretty much dead -- journalling and soft updates give the same sort of reliability and write performance as LFS promised.
Also, having just read two papers on the soft updates technique, I feel the need to improve on your description of it: the behavior you describe is present on FFS/async, as well.
What soft updates does is mantain a list of updates for each in-memory metadata block. Before the block is written to disk, this list of updates is scanned, and any unsafe updates (i.e. ones that depend on other uncommitted updates) are rolled back. After the write completes, they are then rolled forward, to bring the block to its current state. In other words, the latest safe version of the metadata block is written to disk.
You have absolutely no idea what you are talking about.
There is an old, deprecated "Log-Structured FS" in the FreeBSD source tree. Nobody's interested -- log structured FS'es generally have atrocious read performance, because they cannot lay out files for faster read performance like FFS (and I assume ext2fs) can. McKusick has nothing to do with this, and is not very interested in this approach either.
The related journalling filesystems add an extra disk write for every single update operation, making them somewhat slower than the normal filesystem that the journal augments. The journalling technique is, however, conceptually quite simple. Since the extra data structure (the journal) is only used during FS recovery, at least it only wastes disk bandwith during normal operation.
OTOH, soft updates makes a different trade-off: it saves the disk bandwidth, but takes up CPU time and memory. Since CPU's and memory systems are always going to be much faster than magnetic disks (for the forseeable future, anyway), I think this is a better tradeoff.
And SU *does* leave the filesystem safe to mount after a crash. The *only* inconsistencies that can occur are: 1) unused data blocks not marked free. 2) inodes with too high of a link count. These can only result in wasted space, nothing more serious. McKusick is working on a background fsck (using NetApp-style FS snapshots) for FFS, so that fsck can basically be run at anytime during system operation (i.e. the FS doesn't have to be unmounted or r/o mounted).
Oh, well, not that it matters -- this is slashdot, and I fully expect any reply to be "Linux rulez!" The bias I see running through this thread is that "Linux has it, so it must be great" and "BSD doesn't, therefore it must be necessary," so "let's bash BSD on technical grounds -- we can almost never do that;-)"
In reality, SU and journalling are radically different approaches to solving the same problem. They both add *extra* complexity to async writes -- that is, they are not performance tweaks! They are techniquest that try to retain *part* of the performance of async, while adding crash-resistance.
The BSDs now have McKusick's implementation of "Soft Updates" which works better than journalling in many situations, and makes similar guarantees to journalling filesystems. That is, with soft updates, the filesystem is always safe to mount after a crash.
How many of you have seen "A Clockwork Orange"? Good movie, wasn't it?
Remember when they took that criminal, strapped him down, made him watch all sorts of rapes, beatings, murders, etc. They gave him drugs to make him feel sick while he was watching these. As a result, he would always feel violently ill whenever he thought about rapes, beatings, and murders, so he would not rape, beat, or murder.
Let's just try to set this up in reverse. That is, while exposing the subject to scenes of violence, we give him the company of friends/family/significant-others, the delicious smell of popcorn, a soda, or a good beer. We don't even have to strap him down, because why would he leave? What do you think the result will be here?
I'm not saying that we are all as perfectly trainable as Pavlov's dog, but I think that such associations do have the effect on our actions. But it is something to think about....
Stood for the "Union" of "Soviet" "Socialist" "Republics."
The USSR was as much socialist as it was a republic. As a matter of fact, a few years after Lenin took power, he forcibly abolished all of the socialist associations (like worker-controlled factories) that had developed during the revolution(s).
Statist socialism is a misnomer. It still retains the distinction between "non-using owners" and "non-owning users" that exists in capitalism. Under capitalism, the tribute that users pay to owners is called "rent," "interest," or "profit." Under state socialism, all of these are rolled up into "taxes." This is why I usually refer to soviet-style systems as "state-monopoly capitalism."
>>There is a difference between VOLUNTARILY sharing ideas and being FORCED to share ideas.
Strawman.
I am against intellectual property. That does not mean that I want to force others to disclose all that they know. However, when somebody has *voluntarily* shared information (be it a book, software, whatever) to me, I do not believe he has the right to restrict what I can do with that information. That is, he should not *force* me to keep the information from my friends, or *force* me not to make a copy or two.
There is force involved in property, and it is usually on the behalf of the owner, if not directly by the owner. In most cases, it is the squatters who are "defending."
He is, after all, a rather obscure(d) figure, and I've only seen him selectively (very selectively) quoted in Libertarian evangelistic literature.
I suppose the fact that he was a libertarian socialist (dirty word!) will tick off a few people on/. -- he exposes property (both physical and intellectual) as government-granted monopoly, rather than an indivudal, fundamental, undebatable right.
Being forced to take "responsibility" for what you say can, in some cases, be the same as being silenced. Whistle-blowers would have a much harder time under a no-AC situation.
Slashdot Mirror
The vast majority of NFS is done over UDP, not
TCP. TCP stack idiosyncrasies/incompatibilities
would not affect the results.
I rather like the RSS. It's suitably aggressive to catch a lot of spam, and has several advantages over ORBS:
/16s of AboveNet listed.
1) It doesn't list multi-level relays[*] -- I count this as an advantage, because it cuts out the "block an entire ISP because of a few rogue customer" effect.
2) They can actually produce a spam for each listing, something that ORBS cannot do in most cases.
3) [related to (2)] When explaining to a (non-)admin why you are blocking their mail, you can point them to an ACTUAL SPAM INCIDENT and say
"here's why."
4) [also related to (2)] There are no "manual listings" on the RSS -- every RSS-listed host is actually an open relay. Many ORBS-listed hosts are not open relays.... perhaps even most, with the multiple
[*] I really dislike the way ORBS handles this problem. Basically, if you run a (closed) relay, you apparently need to subscribe that relay to ORBS in order to keep it off of ORBS. Oh, yeah... there is one other alternative: you can enforce a no-servers policy, or (ack!) filter all incoming port 25 traffic to customers.
They don't even require a spam incident -- they will launch this "test" against any host that is nominated REGARDLESS OF WHETHER IT HAS EVER SENT SPAM.
I suspect that this is why ORBS is still accused of scanning for open relays. Some spammer is probably "nominating" whole IP blocks so they can check the ORBS list later. Since nobody smart uses ORBS, they now have a list of open relays, which are not on any real blacklist.
Either this is the case, the ORBS kiddies actually *are* doing scans, or AboveNET and many other ISPs are lying when they claim ORBS is scanning them.
That's a "log-structured" filesystem, not a journalling filesystem. They're very slightly related (in that both of them are filesystems).
The difference is a journalling filesystem can maintain decent read performance, because journalling does not confine the layout of data on the disk, while log-structuring does. Log-structured filesystems cannot get past the file fragmentation problem, without wasting tons of disk bandwidth.
Slower? by what benchmark?
;-)
Some System V advocates had created a "benchmark" that proved that FFS (with 4k blocks and 1k fragments) was faster than their 1k-blocksize filesystem. They would create a file, and grow it by 1k blocks. This cause FFS to grow the file's last fragment (which often involves a copy) on every update. Of course, it was the optimal case for their filesystem. It was this crooked benchmark that lead to the tunefs -o (space|time) option. '-o time' will upgrade a fragment to a full 4k block, wasting a bit of space, but saving time -- it is quite useful for constantly-growing smallish files, e.g. logfiles. (and, of course, for running crooked benchmarks
Also, logging filesystems and journalling filesystems are *very* different. Loggin filesystems pretty much have to leave file blocks scattered throughout the disk, or waste disk bandwidth relocating them (to the head of the log, of course). Journalling filesystems, however, can choose whatever file layout they please, so they can optimise this layout for good read performance. The FreeBSD LFS is not even alpha -- it's past that stage, nobody is working on it, and I think it might even be in the CVS attic... yep, no code there anymore. I think the LFS approach is pretty much dead -- journalling and soft updates give the same sort of reliability and write performance as LFS promised.
Also, having just read two papers on the soft updates technique, I feel the need to improve on your description of it: the behavior you describe is present on FFS/async, as well.
What soft updates does is mantain a list of updates for each in-memory metadata block. Before the block is written to disk, this list of updates is scanned, and any unsafe updates (i.e. ones that depend on other uncommitted updates) are rolled back. After the write completes, they are then rolled forward, to bring the block to its current state. In other words, the latest safe version of the metadata block is written to disk.
You have absolutely no idea what you are talking about.
;-)"
There is an old, deprecated "Log-Structured FS" in the FreeBSD source tree. Nobody's interested -- log structured FS'es generally have atrocious read performance, because they cannot lay out files for faster read performance like FFS (and I assume ext2fs) can. McKusick has nothing to do with this, and is not very interested in this approach either.
The related journalling filesystems add an extra disk write for every single update operation, making them somewhat slower than the normal filesystem that the journal augments. The journalling technique is, however, conceptually quite simple. Since the extra data structure (the journal) is only used during FS recovery, at least it only wastes disk bandwith during normal operation.
OTOH, soft updates makes a different trade-off: it saves the disk bandwidth, but takes up CPU time and memory. Since CPU's and memory systems are always going to be much faster than magnetic disks (for the forseeable future, anyway), I think this is a better tradeoff.
And SU *does* leave the filesystem safe to mount after a crash. The *only* inconsistencies that can occur are:
1) unused data blocks not marked free.
2) inodes with too high of a link count.
These can only result in wasted space, nothing more serious. McKusick is working on a background fsck (using NetApp-style FS snapshots) for FFS, so that fsck can basically be run at anytime during system operation (i.e. the FS doesn't have to be unmounted or r/o mounted).
Oh, well, not that it matters -- this is slashdot, and I fully expect any reply to be "Linux rulez!"
The bias I see running through this thread is that "Linux has it, so it must be great" and "BSD doesn't, therefore it must be necessary," so "let's bash BSD on technical grounds -- we can almost never do that
In reality, SU and journalling are radically different approaches to solving the same problem. They both add *extra* complexity to async writes -- that is, they are not performance tweaks! They are techniquest that try to retain *part* of the performance of async, while adding crash-resistance.
BS: Soft Updates is about as "not free" as the entire Linux kernel. RTFL
The BSDs now have McKusick's implementation of "Soft Updates" which works better than journalling in many situations, and makes similar guarantees to journalling filesystems. That is, with soft updates, the filesystem is always safe to mount after a crash.
What is security, but freedom from fear?
I hope this means no more license managers for that product!
How many of you have seen "A Clockwork Orange"? Good movie, wasn't it?
Remember when they took that criminal, strapped him down, made him watch all sorts of rapes, beatings, murders, etc. They gave him drugs to make him feel sick while he was watching these. As a result, he would always feel violently ill whenever he thought about rapes, beatings, and murders, so he would not rape, beat, or murder.
Let's just try to set this up in reverse. That is, while exposing the subject to scenes of violence, we give him the company of friends/family/significant-others, the delicious smell of popcorn, a soda, or a good beer. We don't even have to strap him down, because why would he leave? What do you think the result will be here?
I'm not saying that we are all as perfectly trainable as Pavlov's dog, but I think that such associations do have the effect on our actions. But it is something to think about....
>>And more, I bet I can write a Perl script that will generate similar texts which, with very little editing, would be of comparable quality.
Now *that* i'd like to see -- the "postmodern chatter generator."
I've also been contemplating a flyer for a "postmodern potluck" -- nobody brings food, but we perform a "social construction of munchies."
Why should I work my ass off to make a living when my landlord (who is too lazy to get a job) takes a far larger percentage of that?
I have no problem paying money to productive (or disabled) people, but people who sit at home and leach off the tenants are another story.
Capitalism appealed to me as a testosterone-soaked teenage boy, but I soon grew out of it.
Stood for the "Union" of "Soviet" "Socialist" "Republics."
The USSR was as much socialist as it was a republic. As a matter of fact, a few years after Lenin took power, he forcibly abolished all of the socialist associations (like worker-controlled factories) that had developed during the revolution(s).
Statist socialism is a misnomer. It still retains the distinction between "non-using owners" and "non-owning users" that exists in capitalism. Under capitalism, the tribute that users pay to owners is called "rent," "interest," or "profit." Under state socialism, all of these are rolled up into "taxes." This is why I usually refer to soviet-style systems as "state-monopoly capitalism."
>>There is a difference between VOLUNTARILY sharing ideas and being FORCED to share ideas.
Strawman.
I am against intellectual property. That does not mean that I want to force others to disclose all that they know. However, when somebody has *voluntarily* shared information (be it a book, software, whatever) to me, I do not believe he has the right to restrict what I can do with that information. That is, he should not *force* me to keep the information from my friends, or *force* me not to make a copy or two.
There is force involved in property, and it is usually on the behalf of the owner, if not directly by the owner. In most cases, it is the squatters who are "defending."
He is, after all, a rather obscure(d) figure, and
/. -- he exposes property (both physical and intellectual) as government-granted monopoly, rather than an indivudal, fundamental, undebatable right.
I've only seen him selectively (very selectively) quoted in Libertarian evangelistic literature.
I suppose the fact that he was a libertarian socialist (dirty word!) will tick off a few people on
Being forced to take "responsibility" for what you say can, in some cases, be the same as being silenced. Whistle-blowers would have a much harder time under a no-AC situation.
Not compared to some of the best of the 'net.
Try flag.blackened.net and/or www.zmag.org...
of the micrograph my mother-in-law took, showing a white blood cell with a distinctly visible smiley-face....
"Ayn Rand would never approve..."
feh.
> OTOH, you don't have to sign the agreement. Just if you want to eat.
Yep. Remember, this agreement is COMPLETELY VOLUNTARY. Any extra leverage they have over you is a lie spread by the Commies....
Yep, like gcc, lcc, and TenDRA....
;-)
But what do you compile *them* with