I tried to sell land on the moon and mars myself but got laughed at every occasion I tried. I don't see why, same rules should apply to me as they do to some smart ass company who thinks they own the whole universe.
without having to connect to a tracker (which you may not hae access to).
What does this mean? How can you not have access to your own machine?
Anyway, YOU STILL HAVE TO RUN A TRACKER. It's just built in to the client instead of being the program right next to it. It does have minor advantages in traffic generated at the original tracker (which is pretty insignificant anyway), and in being able to resume a download after the original tracker dies. However, you can't start a new download after the tracker dies (which is what we really wanted trackerless torrents for) unless someone posts an updated version of the torrent file with peers that are still active.
LocalTalk has nothing to do with it (it's used to implement a network interface on a modem/printer port). AppleTalk is its own protocol, and if your router can't understand it, it can't be routed. Older routers could handle this just fine (within a LAN anyway), but as more people moved to IP-only routers, Apple simply added an IP layer to compensate (but had to drop some of the cooler features of appletalk, like what they're only now trying to emulate in rendezvous). The IP layer is of course incompatible with pure AppleTalk devices.
Well if you know the size of the buffer, you could always write $buffsize zeros to disk.
Except that the drive is likely to finish writing those before it gets to everything that was already in the buffer, slowing down the synchronization process. The disk buffer is not a strict queue, because the write order is optimized for locality on the disk surface.
fsync() is pretty clearly documented to cause a flush of the kernel buffers, not the disk buffers. This shouldn't come as a surprise to anyone.
From Mac OS X --
DESCRIPTION Fsync() causes all modified data and attributes of fd to be moved to a permanent storage device. This normally results in all in-core modified copies of buffers for the associated file to be written to a disk.
Note that while fsync() will flush all data from the host to the drive (i.e. the "permanent storage device"), the drive itself may not physi- cally write the data to the platters for quite some time and it may be written in an out-of-order sequence.
Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written. The disk drive may also re-order the data so that later writes may be present while earlier writes are not.
This is not a theoretical edge case. This scenario is easily reproduced with real world workloads and drive power failures.
For applications that require tighter guarantess about the integrity of their data, MacOS X provides the F_FULLFSYNC fcntl. The F_FULLFSYNC fcntl asks the drive to flush all buffered data to permanent storage. Applications such as databases that require a strict ordering of writes should use F_FULLFSYNC to ensure their data is written in the order they expect. Please see fcntl(2) for more detail.
From Linux --
NOTES In case the hard disk has write cache enabled, the data may not really be on permanent storage when fsync/fdatasync return.
From FreeBSD's tuning(7) --
IDE WRITE CACHING FreeBSD 4.3 flirted with turning off IDE write caching. This reduced write bandwidth to IDE disks but was considered necessary due to serious data consistency issues introduced by hard drive vendors. Basically the problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives will not only write data to disk out of order, they will sometimes delay some of the blocks indefinitely under heavy disk load. A crash or power failure can result in serious file system corruption. So our default was changed to be safe. Unfortu- nately, the result was such a huge loss in performance that we caved in and changed the default back to on after the release. You should check the default on your system by observing the hw.ata.wc sysctl variable. If IDE write caching is turned off, you can turn it back on by setting the hw.ata.wc loader tunable to 1. More information on tuning the ATA driver system may be found in the ata(4) man page.
There is a new experimental feature for IDE hard drives called hw.ata.tags (you also set this in the boot loader) which allows write caching to be safely turned on. This brings SCSI tagging features to IDE drives. As of this writing only IBM DPTA and DTLA drives support the feature. Warning! These drives apparently have quality control problems and I do not recommend purchasing them at this time. If you need perfor- mance, go with SCSI.
How the heck would they find that out? Flash a 1 frame picture of a penis during a Disney movie (ala Fight Club) and count how many people seem disturbed?
Mr. Bangoura said, "I have total confidence in our system of justice." So do I.
How can you have total confidence in something you just watched fail? Or is that "total confidence that one might be able to undo some of the damage, if he has enough money"?
Slashdot Mirror
It's ok, I laughed at them too.
What does this mean? How can you not have access to your own machine?
Anyway, YOU STILL HAVE TO RUN A TRACKER. It's just built in to the client instead of being the program right next to it. It does have minor advantages in traffic generated at the original tracker (which is pretty insignificant anyway), and in being able to resume a download after the original tracker dies. However, you can't start a new download after the tracker dies (which is what we really wanted trackerless torrents for) unless someone posts an updated version of the torrent file with peers that are still active.
LocalTalk has nothing to do with it (it's used to implement a network interface on a modem/printer port). AppleTalk is its own protocol, and if your router can't understand it, it can't be routed. Older routers could handle this just fine (within a LAN anyway), but as more people moved to IP-only routers, Apple simply added an IP layer to compensate (but had to drop some of the cooler features of appletalk, like what they're only now trying to emulate in rendezvous). The IP layer is of course incompatible with pure AppleTalk devices.
Pardon me, but have you ever heard of drugs?
How can a relationship be "accurate"?
Except that the drive is likely to finish writing those before it gets to everything that was already in the buffer, slowing down the synchronization process. The disk buffer is not a strict queue, because the write order is optimized for locality on the disk surface.
From Mac OS X --
From Linux --
From FreeBSD's tuning(7) --
Because some players can use H.264, converting H.264 to MPEG-2 takes no time? I'm not quite following your logic.
Nice.
I'm pretty sure Dewey dropped from that partnership years ago.
No, it just means somewhere else is worse.
No one born before 1970 can use a computer?
A single fullscreen button, dimmed out.
Steeling it should be easy, just watch out for coppers.
Fighting against freedom = fighting for freedom? Whatever.
Hypocrisy much?
gifts: once/month: ~50
clothing: once/month ~100
Flowers: twice/month: 10
Misc.: 75
Jesus, that's a hell of a subscription cost. And people complain about WoW...
I think I'll just buy enough drugs so I don't need sex.
Actually he typed "runing". You know, covering the nation with magical symbols to enchant it against evil [political] powers.
Not if you're talking about one's complement.
So would the internet.
Your methods look a bit error-prone.
Yeah...that and bad products.
He always has been good at killing kings.
She makes songs?
How can you have total confidence in something you just watched fail? Or is that "total confidence that one might be able to undo some of the damage, if he has enough money"?