If you use bittorrent on a directory of files, and the files are not modified, but a new file is inserted in the middle. At worst a piece of the start and end of a couple files will be redownloaded (as the piece will overlap 2 files). The rest of the existing files should have the same contents even though the piece boundaries have moved. And even though the hash values would changed, the client should be able to confirm their contents.
One of my pet peeves is analysts who think they know how to write software. Or who think they know the exact steps the software should perform. If you are producing a spec for someone to implement, tell the developer "why" not "how". Don't waste your time mocking up a screen shot unless it helps to explain "why". Don't get bogged down explaining each little step you think needs to be done. Your most important job is to give the developer a concise description of the requirements in one place.
I've seen the result of analysts trying to explain how the software should function, given to green developers who try to do exactly what was requested, come back time and again because the big picture didn't hang together or it wasn't what the customer needed.
And developers, put the "why" into comments in the source code. Make sure you leave enough crumbs around for the next maintainer to understand the motivation of the code. My personal belief is that most specs and documentation should all be produced from the source code. Ideally the entire process from requirements gathering to finished product should be focused towards building the source code and comments that document it.
I've had an idea floating in the back of my head for a while for something closer to SvnTorrent. Where checkin conflict resolution is still handled centrally, but all data and meta-data is transferred directly between peers.
The main thing that caused the Great Depression and the same thing that is causing our current financial crisis is wild asset speculation funded by easy credit. Borrowing money to outbid each other on existing assets only adds to the interest burden of society without increasing our gross production capacity.
Encouraging people to borrow more and spend more in an attempt to stimulate the economy is grossly negligent. Yet this is exactly the strategy economist have used to get out of the last three recessions.
What we should be doing to prevent this happening again is linking asset valuations directly to the income that asset could be reasonably expected to earn (houses to rent, shares to dividends,...).
Half-Life Source is the original half life maps, textures, models etc running on the new graphics engine. It looks and feels pretty much exactly the same as the old game. Black Mesa... is something else. Every level of the original Half-Life has been rebuilt from the ground up based on the graphical style and engine of Half-Life 2.
The major problem I see is that UDP doesn't play as nicely as TCP. Not by a longshot.
The main reason for swapping to UDP is that 600 TCP connections over a single congested link don't play very nice together anyway. If you let uTorrent flood your upload bandwidth with outgoing TCP connections you already have the exact problem your talking about. Only it gets amplified by all the automatic retransmits. Swapping to UDP doesn't magically sweep away all the potential problems of having such a bandwidth greedy application, but it gives the application more control in how the bandwidth of all its connections should be throttled.
Another advantage UDP has over TCP; there is no maximum half open limit on windows XP. So having a bittorrent client running in the background should not have any impact (other than the available bandwidth obviously) on every other application that is trying to open a TCP connection.
I think the point the OP was trying to make was; in 2D sprite or vector animation you have to draw the character moving from every perspective. But if you animate the character in 3D, you can still render the character on a flat plane at run time, but you don't have to duplicate the animation effort.
I've held the view that belief in the existence of God is an axiom. It's not something you can derive from other axioms. You may be able to derive some interesting theories from that belief. But as Godel will tell you, you can't use those theories to prove that God exists.
Modernising law would require a strict compilable language and virtual machine to apply it. The interpretation of law is pretty strict already, just formalise it and build a model that can evaluate how it applies. You'd need a CM system of some kind, test cases to see clearly how the law would be applied. The court system can submit patches to clarify interpretation, establish which parts of law apply with which precedence where this hasn't been specified, and add exception handling. Congress can submit patches to change the functionality, mark sections as deprecated.
However it will probably never happen. The work involved is bigger than the effort being made to formalise and verify mathematical proofs, and it would be far more complicated.
Yep, you have to show up, have your name checked off, and put a piece of paper into a box. But you don't have to fill it in correctly if you don't want to. Though I don't think many people throw their vote away deliberately.
Easily disputed. From the video card section it looks like most gamers don't have the latest graphics cards so are likely to be running games at a reduced resolution to improve performance.
Yes, and no. Some of those "traps" that the BDVM code can call are cryptography methods. However the encryption keys used will either be generated by the BDVM code, or are already known from the AACS system.
True, but why bother burning when right now buying a hard disk and filling it with pirated movies is cheaper per GB than buying those movies on BD Disks.
That disc key is stored on the disc, but AES encrypted, using millions of "player keys"
Just to be a little more pedantic. The disc key is only encrypted a very small number of times on each disc using different keys.
There are (I think) 512 master device keys stored in a vault somewhere that we don't know. Each device key can be used to generate 2 more device keys and one decryption key. This process can be applied recursively to generate a tree that contains 2^32 unique decryption keys.
Each hardware or software device is given a list of keys within this tree so that they can generate some fraction of these the unique keys. With the way the tree is divided between players, there is at least one key that every device can generate, one key that half the devices can generate,.... one key that only two devices can generate, one key that only one device can generate.
To revoke a device, all they need to do is pick the smallest number of keys that the supported players can all generate, but the compromised players cannot.
Initially all disc keys were encrypted with a single decryption key, you know the one that started with 09 F9. That key was revoked to be replaced by a key starting with 45 5F. Which has in turn been replaced by a key starting with 7A 5F.
While nothing will ever be completely impossible. It is possible to make an encryption scheme so hard to brute force that you'd need to boil the oceans or even harness all the power of all the visible stars in the universe to perform the calculations.
Slashdot Mirror
I wouldn't say that.
If you use bittorrent on a directory of files, and the files are not modified, but a new file is inserted in the middle. At worst a piece of the start and end of a couple files will be redownloaded (as the piece will overlap 2 files). The rest of the existing files should have the same contents even though the piece boundaries have moved. And even though the hash values would changed, the client should be able to confirm their contents.
One of my pet peeves is analysts who think they know how to write software. Or who think they know the exact steps the software should perform. If you are producing a spec for someone to implement, tell the developer "why" not "how". Don't waste your time mocking up a screen shot unless it helps to explain "why". Don't get bogged down explaining each little step you think needs to be done. Your most important job is to give the developer a concise description of the requirements in one place.
I've seen the result of analysts trying to explain how the software should function, given to green developers who try to do exactly what was requested, come back time and again because the big picture didn't hang together or it wasn't what the customer needed.
And developers, put the "why" into comments in the source code. Make sure you leave enough crumbs around for the next maintainer to understand the motivation of the code. My personal belief is that most specs and documentation should all be produced from the source code. Ideally the entire process from requirements gathering to finished product should be focused towards building the source code and comments that document it.
But just like its name sake, the legislation will have so many exceptions for politicians and non-profits that it ends up with no teeth.
They've already renamed it MirrorSync and redesigned the entire concept to fit better into the way git repositories already talk to each other.
Bugger, they beat me to it....
I've had an idea floating in the back of my head for a while for something closer to SvnTorrent. Where checkin conflict resolution is still handled centrally, but all data and meta-data is transferred directly between peers.
The main thing that caused the Great Depression and the same thing that is causing our current financial crisis is wild asset speculation funded by easy credit. Borrowing money to outbid each other on existing assets only adds to the interest burden of society without increasing our gross production capacity.
Encouraging people to borrow more and spend more in an attempt to stimulate the economy is grossly negligent. Yet this is exactly the strategy economist have used to get out of the last three recessions.
What we should be doing to prevent this happening again is linking asset valuations directly to the income that asset could be reasonably expected to earn (houses to rent, shares to dividends, ...).
Half-Life Source is the original half life maps, textures, models etc running on the new graphics engine. It looks and feels pretty much exactly the same as the old game. Black Mesa... is something else. Every level of the original Half-Life has been rebuilt from the ground up based on the graphical style and engine of Half-Life 2.
I have no doubt we *could* do it right. I also have no doubt we could do it very very badly.
The major problem I see is that UDP doesn't play as nicely as TCP. Not by a longshot.
The main reason for swapping to UDP is that 600 TCP connections over a single congested link don't play very nice together anyway. If you let uTorrent flood your upload bandwidth with outgoing TCP connections you already have the exact problem your talking about. Only it gets amplified by all the automatic retransmits. Swapping to UDP doesn't magically sweep away all the potential problems of having such a bandwidth greedy application, but it gives the application more control in how the bandwidth of all its connections should be throttled.
Another advantage UDP has over TCP; there is no maximum half open limit on windows XP. So having a bittorrent client running in the background should not have any impact (other than the available bandwidth obviously) on every other application that is trying to open a TCP connection.
I think the point the OP was trying to make was; in 2D sprite or vector animation you have to draw the character moving from every perspective. But if you animate the character in 3D, you can still render the character on a flat plane at run time, but you don't have to duplicate the animation effort.
I've held the view that belief in the existence of God is an axiom. It's not something you can derive from other axioms. You may be able to derive some interesting theories from that belief. But as Godel will tell you, you can't use those theories to prove that God exists.
Mythbusters looked at the toothbrush / fecal bacteria thing and found bacteria on a toothbrush kept in the kitchen. That stuff gets everywhere.
And the jpeg encoder will be identifiable as well. (Can't think of the name of the software right now...)
Modernising law would require a strict compilable language and virtual machine to apply it. The interpretation of law is pretty strict already, just formalise it and build a model that can evaluate how it applies. You'd need a CM system of some kind, test cases to see clearly how the law would be applied. The court system can submit patches to clarify interpretation, establish which parts of law apply with which precedence where this hasn't been specified, and add exception handling. Congress can submit patches to change the functionality, mark sections as deprecated.
However it will probably never happen. The work involved is bigger than the effort being made to formalise and verify mathematical proofs, and it would be far more complicated.
Accidentally? No. But if the summary asked us to deliberately DDOS the site, I think we could still do it.
Yep, you have to show up, have your name checked off, and put a piece of paper into a box. But you don't have to fill it in correctly if you don't want to. Though I don't think many people throw their vote away deliberately.
Easily disputed. From the video card section it looks like most gamers don't have the latest graphics cards so are likely to be running games at a reduced resolution to improve performance.
Yes, and no. Some of those "traps" that the BDVM code can call are cryptography methods. However the encryption keys used will either be generated by the BDVM code, or are already known from the AACS system.
True, but why bother burning when right now buying a hard disk and filling it with pirated movies is cheaper per GB than buying those movies on BD Disks.
I think the existing checks are already pretty strict. They provided the doom9 guys with a heap of unit tests to stress test their VM.
That disc key is stored on the disc, but AES encrypted, using millions of "player keys"
Just to be a little more pedantic. The disc key is only encrypted a very small number of times on each disc using different keys.
There are (I think) 512 master device keys stored in a vault somewhere that we don't know. Each device key can be used to generate 2 more device keys and one decryption key. This process can be applied recursively to generate a tree that contains 2^32 unique decryption keys.
Each hardware or software device is given a list of keys within this tree so that they can generate some fraction of these the unique keys. With the way the tree is divided between players, there is at least one key that every device can generate, one key that half the devices can generate, .... one key that only two devices can generate, one key that only one device can generate.
To revoke a device, all they need to do is pick the smallest number of keys that the supported players can all generate, but the compromised players cannot.
Initially all disc keys were encrypted with a single decryption key, you know the one that started with 09 F9. That key was revoked to be replaced by a key starting with 45 5F. Which has in turn been replaced by a key starting with 7A 5F.
While nothing will ever be completely impossible. It is possible to make an encryption scheme so hard to brute force that you'd need to boil the oceans or even harness all the power of all the visible stars in the universe to perform the calculations.
So... it can display a second image that is completely invisible unless I hold a piece of paper in front of it.
Is it just me or does that sound kind of silly?
I blatantly stole it from Bruce Schneier.