Go learn the difference between blocks and sectors before you comment. Then read and comprehend the ReiserFS source code. Two important facts should pop out at you:
Blocks default to 4096 bytes, because this is convenient for the page cache; nothing stops you using a different size. For example, I have ext3 filesystems at work using 512 byte blocks (so the allocation unit is 512 bytes) on a system with 4096 byte pages.
ReiserFS tail-packing uses left-over space in blocks, and space that cannot be used as blocks. It does not allocate blocks specifically for use in tail-packing; that's FFS-style fragment handling, which is different.
The reason for 4K blocks is that the cache is paged in 4K chunks on a machine with 4K pages. On something with a different page size (e.g. a MIPS or IA64 box configured with 64K pages), 4K blocks is less efficient, but still works fine (which would not be true if the OS paged the memory to disk for writes, since the block would be accompanied by 12K of garbage.
Reads and writes at the OS level can still be done on a single-sector basis; it's just inefficient, as each sector ends up filling a page in the cache, either with the other 7 sectors needed to make up one page, or with dummy data.
Almost all file systems use 4096 byte sectors so that they align with the size of the memory pages.
Not quite true. Filesystems like ReiserFS (v3 or v4) may use 4096 byte blocks for large files, but can pack several small files into single physical sectors (512 bytes). And of course, if it's in a RAID-5 array, that 4096 byte block takes up 4608 bytes on the disks (9 sectors), so that odd number at the end may matter.
More realistically, my 120GB drives have 234,441,648 sectors, which is already a multiple of 8, so those last 3 sectors don't exist. Further, worrying about what might or might not be in the last 3 sectors of over 2 million (assuming we're mostly talking about really old 1.2GB or so drives) is major paranoia time. I just like dd_rescue, so I thought I'd pimp it here:)
On plain dd, bs=4096 runs the risk of not overwriting up to 3 sectors at the end of the disc. If this worries you, but you still want the performance gain, use dd_rescue, with a command of the form dd_rescue/dev/random/dev/hdx which will use 64KB blocks until they're too big to function, then fall back down all the way to single sectors.
Windows 95 through ME (but not any Windows NT, which includes 2000 and XP) are basically GUI shells on top of a 32-bit DOS extender, with some interesting behaviour because of this, notably excitement caused by multiple device drivers for the same hardware (16-bit DOS MSCDEX versus the Windows VXD that performed the same function, for example).
Windows NT started out with graphics device drivers in the kernel, and the remainder of the GUI in user space. This was found to be unacceptably slow on the hardware of the day, so large chunks of the GUI were moved into kernel space, and hacked around until they functioned.
I've no idea if Windows XP has stabilised those kernel add-ons, or if Microsoft have reversed this decision; however, a kernel bug has the potential to damage anything running on the system, while a process bug is more limited. Thus, running the GUI in kernel space gets you speed at the expense of system stability and security.
For a single-user system, it's not so bad that a GUI crash takes out the entire system; the user probably can't do anything once the GUI's down, and on the hardware of the day, we did not have soft power buttons, so the only sane reaction to a crashed GUI was to toggle the power, making the chances of saving any work slim regardless of where the GUI ran.
With soft power buttons, it becomes possible to (e.g.) sync the discs when power is hit, which would allow programs running under a crashed GUI one last chance to save state, ready to recover when the machine restarts; with the GUI in kernel space, there's no guarantee that the disc driver is in sane enough state to let you write without trashing all drives, so this sort of reliability improvement can't be implemented.
Are you aware of how the "Jello" break for fingerprint readers works? If not, go read up on it. The basis is that a thing layer of Jello on your own finger can have someone else's fingerprint on it; because it's got your skin underneath, it reads human, and because it's got the victim fingerprint on it, it reads as someone else.
I believe that a similar trick has been demonstrated with contact lenses for iris recognition; the base problem is that it's too easy to change appearance to match someone else at a casual glance, and the machine can't risk more (in case of things like colds, new contact lenses etc).
As the devs often seem to abbreviate it to "Postgres", which I'd pronounce "Post-gres", I pronounce it as "Post-gres-Q-L".
Re:I don't get it? ; onboard ; memory ; solid stat
on
Intel and Laptop RAID?
·
· Score: 1
Sorry, I should have made it clear that I'm comparing a RAID of identical drives to a single drive. Thus, RAID 0 gets you more space than a single drive, while RAID 1 gets you a larger MTTDL.
Of course, the MTBF of any RAID is lower than the MTBF of a single drive; this implies that a RAID-0 or JBOD, which have no redundancy, are less reliable than a single drive, while a RAID-1 or above is only more reliable if you change the failed drive quickly enough.
Re:I don't get it? ; onboard ; memory ; solid stat
on
Intel and Laptop RAID?
·
· Score: 1
No, RAID-0 is interleaving. JBOD is 0-40GB disc 1, 40-80GB of disc 2. Controllers that interleave (from my experience) include the HPT-374 (software IDE RAID with BIOS), the Adaptec AAR-2400A (IDE RAID) and the LSI MegaRAID (SCSI RAID). Wikipedia has more detail.
In theory, RAID-0 gets you additional space, and access that's no slower than one drive and up to number of drives times faster (since the best case splits evenly between the drives, and the worst hits one drive only). RAID-1 gets you identical write speeds (as writes go to all drives), and up to number of drives times faster reads (since each read comes from one of the drives in the set). Of course, practically you get a slight decrease from the theoretical performance.
Not SSH, but web caches. If corporate insist that you browse via a cache setup that fails over from the New York link to the Tokyo link whenever the internal network conditions make it worthwhile, you'll merrily surf from all sorts of addresses.
Re:You can't catch it all
on
Ending Spam
·
· Score: 3, Insightful
Trouble is that a zombie has access to the user's legitimate mail system, which they can abuse.
In the end, no technical solution is really going to solve it; you're using "is this machine meant to send mail?" as a heuristic for "is this mail junk mail?". As you can't define junk mail objectively, in computer-friendly criteria, any filter is inevitably going to make mistakes. The only question is whether your filter tends towards false positives or false negatives.
Most European cities (e.g. London, Paris, Madrid) predate mass transit, so quite how we designed around it, I do not know.
On the other hand, we did build around the idea of pedestrians and horses, with the odd cart. Much smaller than cars, so when transit became an issue, we dug under our cities, we built above our cities, we designed buses to fit our cities, and generally arranged to fit mass transit in, because we couldn't physically fit a car per person into the city.
The BitTorrent FAQ for content providers suggests that a provider should run both a tracker and a seed. If you think about it, this is the only way that content can get into the system in the first place; without that initial seed, how does anyone have anything available to download?
So, a legitimate provider can just keep that initial seed running, rather than stop it after a few uploads; if they run the seed on the system that would have run the HTTP server for a HTTP download, your worst case speeds are close to HTTP, and your best case speeds are higher.
No, your IP limit is how many can you get routed to one machine. Within a test network, using 10.0.0.0/8, I've had one box bound to just under 16 million IPs. I needed to rebuild the kernel to cope, but it can be done.
When I was a student (in the UK), my ITS agreement stated that the computing facilities were provided for academic use. It further stated that a reasonable amount of non-academic use was normally tolerated, but that the ITS made no guarantee that it would not be blocked, or that they would troubleshoot any problems with non-academic use.
As dating service mail is non-academic use, the ITS would be within their contract if they blocked it; they wouldn't have been within their contract if they shut down my account for it, as that blocks my academic use.
Recording all the Freeview multiplexes isn't too hard; the QAM 16 multiplexes (4 of the 6) are 18MBit/s each, while the QAM 64 multiplexes are 24MBit/s each. Thus, you get a total of 120MBit/s (15MByte/s) to record. A single ATA disc from Western Digital (WD1200JB) can store at 30MByte/s, so all you need is enough disc space in a JBOD form. Still expensive, but so as bad as you might think, and I'm assuming you store the full multiplex in transmitted form, without dropping padding, and depacketising it.
And if this scares you, go looking at RFC 3041. In short, your machine can change its IP address as and when it feels like it, so that tracking by IP is as helpful as it is in IPv4 days.
Who gets to define warez? I've just been in an argument with a BSA employee who claimed that any software that's not been purchased (i.e. obtained without payment) is warez. By this definition, http://www.debian.org/ is a warez server.
If you're sending an unsubscribe request to a spammer in response to a spam you've received, that's not intended as a DDoS; the spammer invited you to contact them and unsubscribe, and should have taken care to limit their list to avoid accidentally DDoSing their servers. In the same vein, I see nothing wrong with browsing a site advertised to you in a spam, despite intending to merely use up bandwidth, rather than make a purchase; again, if the spammer isn't happy, they shouldn't invite you to browse their site (in other words, they shouldn't send spam if they don't want to be visited).
When you start trusting someone else to tell you who's spamming and who isn't, you invite them to abuse that power; what guarantees do you have that Blue Security will never go to a legitimate site owner, and threaten to tell SpamSlayer users that the legitimate site is spamvertised unless Blue Security receive enough money?
The complaint is that Intel uses the CPUID instruction to verify that the code is running on an Intel processor, uses reasonable (but non-optimal) code for unknown (unreleased) Intel processors, optimal code for known Intel processors, and intentionally sub-optimal code for non-Intel x86 chips.
If Intel's compiler treated AMD chips like unknown Intel processors (check for extension support like SSE or SSE2, and use if available, else use sane code for Intel-sized cache lines), the code would still be faster on Intel chips than on AMD chips, as it'd be optimal for Intel design decisions, not AMD design decisions. However, in order to give the impression that non-Intel chips are much slower than Intel chips, the Intel compiler creates code which checks for Intel trademarks in CPUID (as against feature support), and deliberately uses slow code paths if those trademarks are not present. This ensures that Intel's competitors cannot do a fair like-for-like comparison with Intel's chips, as Intel says that code not compiled with their compiler is unfairly slow.
BluRay is as open as DVD or HD-DVD; the question is whether the other 80% are going to continue pushing HD-DVD when (say) 20% of homes have BluRay thanks to the PS3, and 2% have HD-DVD.
If consumers decide to stick with DVD players until the HD disk war is over, BluRay is going to win; it'll get itself into houses via the PS3, and only BluRay content producers will see any ROI. It's only if consumers decide they want HD now that HD-DVD has a chance against BluRay.
So, where do I get an implementation of IPv8? Or even a spec? Google gives nothing, www.ipv8.org just serves adverts - I'd guess that you own the ipv8.org domain, and are trying to make a quick buck from ignorant slashdotters.
Blocklists is a bad choice of wording; these are lists of IPs that the list claims are spammy.
It's up to the mail admin to choose what they do with them. Some mail admins block based on them; others choose to apply greylisting only to IPs on one of these lists. I happen to use several lists on the firewall that the mailserver lives behind to determine how fast your mailserver can send mail to my mailserver, using a CBQ setup. Unlisted servers are top priority, and can use all available bandwidth; listings in SPEWS level 2 and other unreliable lists are the next priority down, sharing 1MBit/s. Listings in SBL and other good blacklists force you down a level, and you now have to share just 10kBit/s.
The result is that my use of blacklists doesn't drop a single mail; by throttling the rate at which blacklisted servers can send to me, I keep the load on my server under control, and there's no gain to you in having access to several servers, all on the same blacklist (as if two servers listed on the SBL send to me at once, they each get 5kBit/s, dropping to 1kBit/s whenever an unlisted server sends me something).
Bad application of blacklists is wrong, but so's bad application of (for example) guns or cars. And, as with all things that someone else maintains, you need to check up on the blacklists you use regularly.
Strictly, it's the Pentium-M which is still an i686, as the Pentium 4 is the NetBurst platform (a complete redesign for high clock speeds at the expense of all else). Pentium-M however, is an evolution of the P3, which is an evolution of the P2, which is a PPro with better 16-bit code support and MMX.
I have another countermeasure against that sort of attacker; my firewall counts connections from a given host in a rolling time period. Any host that connects too often is either throttled (if it's a public service that I want the world to access, like HTTP), or blocked outright (if it's a service like SSH that I've left open for my convenience). I then have a script that tracks how often these hosts continue to abuse the system. Those that stop are unblocked/unthrottled, while those that continue are left there.
The result is that attackers are ignored, while normal use is unhindered.
Although if you feel like extending the gunfight analogy, it can be done.
You're in the city, and someone fires at you; you fire back in the direction you think the bullet came from. If the attacker shoots at you from behind you, then runs off, there's a good chance that when you turn around and fire, you'll hit an innocent instead of the attacker.
Slashdot Mirror
The reason for 4K blocks is that the cache is paged in 4K chunks on a machine with 4K pages. On something with a different page size (e.g. a MIPS or IA64 box configured with 64K pages), 4K blocks is less efficient, but still works fine (which would not be true if the OS paged the memory to disk for writes, since the block would be accompanied by 12K of garbage.
Reads and writes at the OS level can still be done on a single-sector basis; it's just inefficient, as each sector ends up filling a page in the cache, either with the other 7 sectors needed to make up one page, or with dummy data.
Not quite true. Filesystems like ReiserFS (v3 or v4) may use 4096 byte blocks for large files, but can pack several small files into single physical sectors (512 bytes). And of course, if it's in a RAID-5 array, that 4096 byte block takes up 4608 bytes on the disks (9 sectors), so that odd number at the end may matter.
More realistically, my 120GB drives have 234,441,648 sectors, which is already a multiple of 8, so those last 3 sectors don't exist. Further, worrying about what might or might not be in the last 3 sectors of over 2 million (assuming we're mostly talking about really old 1.2GB or so drives) is major paranoia time. I just like dd_rescue, so I thought I'd pimp it here :)
On plain dd, bs=4096 runs the risk of not overwriting up to 3 sectors at the end of the disc. If this worries you, but you still want the performance gain, use dd_rescue, with a command of the form dd_rescue /dev/random /dev/hdx which will use 64KB blocks until they're too big to function, then fall back down all the way to single sectors.
Windows 95 through ME (but not any Windows NT, which includes 2000 and XP) are basically GUI shells on top of a 32-bit DOS extender, with some interesting behaviour because of this, notably excitement caused by multiple device drivers for the same hardware (16-bit DOS MSCDEX versus the Windows VXD that performed the same function, for example).
Windows NT started out with graphics device drivers in the kernel, and the remainder of the GUI in user space. This was found to be unacceptably slow on the hardware of the day, so large chunks of the GUI were moved into kernel space, and hacked around until they functioned.
I've no idea if Windows XP has stabilised those kernel add-ons, or if Microsoft have reversed this decision; however, a kernel bug has the potential to damage anything running on the system, while a process bug is more limited. Thus, running the GUI in kernel space gets you speed at the expense of system stability and security.
For a single-user system, it's not so bad that a GUI crash takes out the entire system; the user probably can't do anything once the GUI's down, and on the hardware of the day, we did not have soft power buttons, so the only sane reaction to a crashed GUI was to toggle the power, making the chances of saving any work slim regardless of where the GUI ran.
With soft power buttons, it becomes possible to (e.g.) sync the discs when power is hit, which would allow programs running under a crashed GUI one last chance to save state, ready to recover when the machine restarts; with the GUI in kernel space, there's no guarantee that the disc driver is in sane enough state to let you write without trashing all drives, so this sort of reliability improvement can't be implemented.
I believe that a similar trick has been demonstrated with contact lenses for iris recognition; the base problem is that it's too easy to change appearance to match someone else at a casual glance, and the machine can't risk more (in case of things like colds, new contact lenses etc).
As the devs often seem to abbreviate it to "Postgres", which I'd pronounce "Post-gres", I pronounce it as "Post-gres-Q-L".
Of course, the MTBF of any RAID is lower than the MTBF of a single drive; this implies that a RAID-0 or JBOD, which have no redundancy, are less reliable than a single drive, while a RAID-1 or above is only more reliable if you change the failed drive quickly enough.
In theory, RAID-0 gets you additional space, and access that's no slower than one drive and up to number of drives times faster (since the best case splits evenly between the drives, and the worst hits one drive only). RAID-1 gets you identical write speeds (as writes go to all drives), and up to number of drives times faster reads (since each read comes from one of the drives in the set). Of course, practically you get a slight decrease from the theoretical performance.
Not SSH, but web caches. If corporate insist that you browse via a cache setup that fails over from the New York link to the Tokyo link whenever the internal network conditions make it worthwhile, you'll merrily surf from all sorts of addresses.
In the end, no technical solution is really going to solve it; you're using "is this machine meant to send mail?" as a heuristic for "is this mail junk mail?". As you can't define junk mail objectively, in computer-friendly criteria, any filter is inevitably going to make mistakes. The only question is whether your filter tends towards false positives or false negatives.
On the other hand, we did build around the idea of pedestrians and horses, with the odd cart. Much smaller than cars, so when transit became an issue, we dug under our cities, we built above our cities, we designed buses to fit our cities, and generally arranged to fit mass transit in, because we couldn't physically fit a car per person into the city.
So, a legitimate provider can just keep that initial seed running, rather than stop it after a few uploads; if they run the seed on the system that would have run the HTTP server for a HTTP download, your worst case speeds are close to HTTP, and your best case speeds are higher.
No, your IP limit is how many can you get routed to one machine. Within a test network, using 10.0.0.0/8, I've had one box bound to just under 16 million IPs. I needed to rebuild the kernel to cope, but it can be done.
As dating service mail is non-academic use, the ITS would be within their contract if they blocked it; they wouldn't have been within their contract if they shut down my account for it, as that blocks my academic use.
Recording all the Freeview multiplexes isn't too hard; the QAM 16 multiplexes (4 of the 6) are 18MBit/s each, while the QAM 64 multiplexes are 24MBit/s each. Thus, you get a total of 120MBit/s (15MByte/s) to record. A single ATA disc from Western Digital (WD1200JB) can store at 30MByte/s, so all you need is enough disc space in a JBOD form. Still expensive, but so as bad as you might think, and I'm assuming you store the full multiplex in transmitted form, without dropping padding, and depacketising it.
And if this scares you, go looking at RFC 3041. In short, your machine can change its IP address as and when it feels like it, so that tracking by IP is as helpful as it is in IPv4 days.
Who gets to define warez? I've just been in an argument with a BSA employee who claimed that any software that's not been purchased (i.e. obtained without payment) is warez. By this definition, http://www.debian.org/ is a warez server.
When you start trusting someone else to tell you who's spamming and who isn't, you invite them to abuse that power; what guarantees do you have that Blue Security will never go to a legitimate site owner, and threaten to tell SpamSlayer users that the legitimate site is spamvertised unless Blue Security receive enough money?
If Intel's compiler treated AMD chips like unknown Intel processors (check for extension support like SSE or SSE2, and use if available, else use sane code for Intel-sized cache lines), the code would still be faster on Intel chips than on AMD chips, as it'd be optimal for Intel design decisions, not AMD design decisions. However, in order to give the impression that non-Intel chips are much slower than Intel chips, the Intel compiler creates code which checks for Intel trademarks in CPUID (as against feature support), and deliberately uses slow code paths if those trademarks are not present. This ensures that Intel's competitors cannot do a fair like-for-like comparison with Intel's chips, as Intel says that code not compiled with their compiler is unfairly slow.
If consumers decide to stick with DVD players until the HD disk war is over, BluRay is going to win; it'll get itself into houses via the PS3, and only BluRay content producers will see any ROI. It's only if consumers decide they want HD now that HD-DVD has a chance against BluRay.
So, where do I get an implementation of IPv8? Or even a spec? Google gives nothing, www.ipv8.org just serves adverts - I'd guess that you own the ipv8.org domain, and are trying to make a quick buck from ignorant slashdotters.
It's up to the mail admin to choose what they do with them. Some mail admins block based on them; others choose to apply greylisting only to IPs on one of these lists. I happen to use several lists on the firewall that the mailserver lives behind to determine how fast your mailserver can send mail to my mailserver, using a CBQ setup. Unlisted servers are top priority, and can use all available bandwidth; listings in SPEWS level 2 and other unreliable lists are the next priority down, sharing 1MBit/s. Listings in SBL and other good blacklists force you down a level, and you now have to share just 10kBit/s.
The result is that my use of blacklists doesn't drop a single mail; by throttling the rate at which blacklisted servers can send to me, I keep the load on my server under control, and there's no gain to you in having access to several servers, all on the same blacklist (as if two servers listed on the SBL send to me at once, they each get 5kBit/s, dropping to 1kBit/s whenever an unlisted server sends me something).
Bad application of blacklists is wrong, but so's bad application of (for example) guns or cars. And, as with all things that someone else maintains, you need to check up on the blacklists you use regularly.
Strictly, it's the Pentium-M which is still an i686, as the Pentium 4 is the NetBurst platform (a complete redesign for high clock speeds at the expense of all else). Pentium-M however, is an evolution of the P3, which is an evolution of the P2, which is a PPro with better 16-bit code support and MMX.
The result is that attackers are ignored, while normal use is unhindered.
You're in the city, and someone fires at you; you fire back in the direction you think the bullet came from. If the attacker shoots at you from behind you, then runs off, there's a good chance that when you turn around and fire, you'll hit an innocent instead of the attacker.