Perhaps you should think in more modular terms. Lets say there are a number of vehicle configurations between single person commute and long haul semi trailer. You'd need a small number of people cab's, say solo, family and bus sizes. And a small number of cargo sizes, a spectrum between suitcase, sedan trunk, trailer, and shipping container. Then you have a number of chassis that contain the AI, engine, fuel / batteries, and mounting points for the various configurations. Any cargo larger than a trailer could be lockable and quite secure if left unattended.
With 5Mbit down I can download a recently released 350MB tv show avi in about 15 minutes. Though this does depend on the shows demographics and popularity. This is easily fast enough to watch while it's downloading, you just need a client that will prioritise blocks that need to be shown soon.
I've quickly skimmed their wiki. Let me get this straight, they are planning on installing an OS level network hook that intercepts every outgoing TCP connection and sends a bunch of seemingly random data to the server on the other end... Sounds like everyone connecting to any service you write might be inadvertently stress testing it. Better hope you don't have any buffer overflow exploits.
... until you join the swarm yourself, get a list of peers from the tracker, and connect to them directly to verify that they are uploading your copyrighted content. It works for the RIAA.
This sounds like a job for FUSE. Don't store the decrypted movie on your disk anywhere, just the bunch of random data blocks you need to construct it. Of course you'll still need the URL to actually read the file.
In fact if I was writing a client I wouldn't store the URL permanently. Just have 2 processes you can use to parse a URL and queue the download of any missing random blocks and another process you can use to stream the contents to the appropriate application (eg mplayer) or mount a virtual filesystem.
There is no reason to permanently store the URL or the decrypted file.
Even if you consider the initial development of the internet as a science project, the project itself was fairly small. Do you consider research into vehicles and transportation to be a big science project just because there are millions of them on the road now?
There are still a couple of good sets, my son recently received a 3 in 1 set full of generic pieces with separate instructions for each of the 3 different models you can build.
Call me when you write a brute force number crunching algorithm that can derive the brute force number crunching algorithm that solves chess or any other problem you throw at it without running into an infinite loop.
ZFS has a lot in common with a journalled filesystem, I'd almost be tempted to call it one. But instead of using a separate journal to record and playback changes to other meta data, the journal *is* the meta data.
It does however increase the lifetime of each request. The announce handshake (TCP SYN / SYNACK, ssh handshake, http headers in both directions) just gained at least one more pair of packets in each direction.
I'm not going to say git is a poor choice, far from it. However if you ever need disconnected svn access have a look at svk. It provides a local mirror and local branches off a central repository with merge processes to update them in both directions. Though its interface probably needs a little work.
Look, we want no muffins, no toast, no teacakes, no buns, baps, baggetes or
bagels, no croissants, no crumpets, no pancakes, no potato cakes, and no hot
cross buns, and DEFINITELY... no smeggin' flapjacks.
Ahhh.... so you're a waffle man?
I just hope nobody finds a toaster with similar vulnerabilities.
Java isn't that bad. Heck Quake 2 has been ported to Java. To get that kind of performance you have to think like a low level C / Assembly programmer and pay very close attention to where Java might be doing a lot of redundant memory related things.
Yep, and I've seen the exact same problem with plain old simple FTP over a single TCP connection. I've seen FTP's of large files from an ISP mirror squeeze out all other traffic. The problem can be magnified with P2P though, since the application has a large number of TCP connections and each of those can flood a window size of packets whenever they receive an ACK. Even with the flow control built into TCP at the OS layer it is far to easy to completely flood a connection in both directions, though I believe flooding the upload bandwidth is easier and more common.
Valve offered a cheaper version in some countries. The box specifically stated that it would not work outside that area. Obviously some entrepreneurs decided to purchase and resell those keys outside their country without telling the buyer that there was a restriction.
While I agree this restriction sucks for people who leave the country they purchased the cheap version of the game in. The "normal" version doesn't have this limitation.
Sure he could. He can still get a list of peers from the tracker or from the tracker-less protocol or from other peers running the peer exchange extension. He wouldn't get any incoming connections if nobody knows he exists, but he can still connect out to other peers if he can find where they are.
http://wiki.theory.org/BitTorrentSpecification#Tracker_Request_Parameters
# ip: Optional. The true IP address of the client machine, in dotted quad format or rfc3513 defined hexed IPv6 address. Notes: In general this parameter is not necessary as the address of the client can be determined from the IP address from which the HTTP request came. The parameter is only needed in the case where the IP address that the request came in on is not the IP address of the client. This happens if the client is communicating to the tracker through a proxy (or a transparent web proxy/cache.) It also is necessary when both the client and the tracker are on the same local side of a NAT gateway. The reason for this is that otherwise the tracker would give out the internal (RFC1918) address of the client, which is not routeable. Therefore the client must explicitly state its (external, routeable) IP address to be given out to external peers. Various trackers treat this parameter differently. Some only honor it only if the IP address that the request came in on is in RFC1918 space. Others honor it unconditionally, while others ignore it completely. In case of IPv6 address (e.g.: 2001:db8:1:2::100) it indicates only that client can communicate via IPv6. Depending on the tracker, you may be able to impersonate anyone at all.
Slashdot Mirror
Perhaps you should think in more modular terms. Lets say there are a number of vehicle configurations between single person commute and long haul semi trailer. You'd need a small number of people cab's, say solo, family and bus sizes. And a small number of cargo sizes, a spectrum between suitcase, sedan trunk, trailer, and shipping container. Then you have a number of chassis that contain the AI, engine, fuel / batteries, and mounting points for the various configurations. Any cargo larger than a trailer could be lockable and quite secure if left unattended.
Cut-and-paste is a useful refactoring tool. It allows you to quickly move sections of code around. It's copy-and-paste that causes obesity problems.
With 5Mbit down I can download a recently released 350MB tv show avi in about 15 minutes. Though this does depend on the shows demographics and popularity. This is easily fast enough to watch while it's downloading, you just need a client that will prioritise blocks that need to be shown soon.
... the fewer flights needed for a Mars mission the giant Ares V would afford
Actually, a mars mission with Direct has the same number of required launches. Don't forget to count the Ares I launch required for the crew.
I've quickly skimmed their wiki. Let me get this straight, they are planning on installing an OS level network hook that intercepts every outgoing TCP connection and sends a bunch of seemingly random data to the server on the other end... Sounds like everyone connecting to any service you write might be inadvertently stress testing it. Better hope you don't have any buffer overflow exploits.
... until you join the swarm yourself, get a list of peers from the tracker, and connect to them directly to verify that they are uploading your copyrighted content. It works for the RIAA.
Kids keep getting smarter.
Pigmaei gigantum humeris impositi plusquam ipsi gigantes vident
In fact if I was writing a client I wouldn't store the URL permanently. Just have 2 processes you can use to parse a URL and queue the download of any missing random blocks and another process you can use to stream the contents to the appropriate application (eg mplayer) or mount a virtual filesystem.
There is no reason to permanently store the URL or the decrypted file.
Both!
Plus you can also use it to decrypt HD movies.
Even if you consider the initial development of the internet as a science project, the project itself was fairly small. Do you consider research into vehicles and transportation to be a big science project just because there are millions of them on the road now?
Two questions?
What happened to your second question?
There are still a couple of good sets, my son recently received a 3 in 1 set full of generic pieces with separate instructions for each of the 3 different models you can build.
Call me when you write a brute force number crunching algorithm that can derive the brute force number crunching algorithm that solves chess or any other problem you throw at it without running into an infinite loop.
ZFS has a lot in common with a journalled filesystem, I'd almost be tempted to call it one. But instead of using a separate journal to record and playback changes to other meta data, the journal *is* the meta data.
It does however increase the lifetime of each request. The announce handshake (TCP SYN / SYNACK, ssh handshake, http headers in both directions) just gained at least one more pair of packets in each direction.
I'm not going to say git is a poor choice, far from it. However if you ever need disconnected svn access have a look at svk. It provides a local mirror and local branches off a central repository with merge processes to update them in both directions. Though its interface probably needs a little work.
Ahhh.... so you're a waffle man?
I just hope nobody finds a toaster with similar vulnerabilities.Java isn't that bad. Heck Quake 2 has been ported to Java. To get that kind of performance you have to think like a low level C / Assembly programmer and pay very close attention to where Java might be doing a lot of redundant memory related things.
And then you have women like the brillant Paula.
Perl? Pfft. Real men code in INTERCAL.
Until DVD is considered dead or dieing, in the same way VHS is now considered dead, they have BOTH failed.
Yep, and I've seen the exact same problem with plain old simple FTP over a single TCP connection. I've seen FTP's of large files from an ISP mirror squeeze out all other traffic. The problem can be magnified with P2P though, since the application has a large number of TCP connections and each of those can flood a window size of packets whenever they receive an ACK. Even with the flow control built into TCP at the OS layer it is far to easy to completely flood a connection in both directions, though I believe flooding the upload bandwidth is easier and more common.
Valve offered a cheaper version in some countries. The box specifically stated that it would not work outside that area. Obviously some entrepreneurs decided to purchase and resell those keys outside their country without telling the buyer that there was a restriction.
While I agree this restriction sucks for people who leave the country they purchased the cheap version of the game in. The "normal" version doesn't have this limitation.
Sure he could. He can still get a list of peers from the tracker or from the tracker-less protocol or from other peers running the peer exchange extension. He wouldn't get any incoming connections if nobody knows he exists, but he can still connect out to other peers if he can find where they are.