Personally I can't understand why it's ok to negligently allow birds to hunt billions of insects and earthworms, but apparently society is fine with that.
Forget CPU and GPU already. The mining difficulty has risen so much recently that what you can mine with them today won't event offset the power costs.
ASICs are the only viable option today for at-home mining, but I'm pretty sure they'll also be rendered useless soon by hosted mining services (CEX.IO already has 25% of the whole Bitcoin network mining power) that are able to consolidate costs and run their mining farms in countries with cheap electricity.
The whole internet would fit in a 64 bit address space, there is really absolutely no need at all for more than 64 bit for addresses in CPUs, that's why x86_64 and other 64 bit archs are here to stay, and you'll probably never see "128 bit" processors at all.
On the other side, today's x86_64 CPUs are capable of 128 bit (SSE) and 256 bit (AVX) computing. The width of the compute units is also bound to increase for some time, with Intel already planning to go 1024 bit in the not-so-far future.
i686 because I don't see a reason to run x86_64 on 2GB of RAM
x86_64 IA would provide a noticeable performance improvement for some apps, even if you had 640Kb of RAM. It's not only 64-bit addressing but also 64-bit registers (and more of them), 64-bit ALUs, an so on...
The technique for Phong Shading was introduced in 1973 as an improvement to Gouraud Shading, but was too computationally intensive to be used for graphics back then. This is no longer the case.
It was too computationally intensive for *realtime* rendering in 1973, but clearly not out of reach for the kind of modeling software NASA people were using...
Also, it should be noted that realtime phong shading was already common in demos/intros running on 33 MHz 386 CPUs back in the 90s
IPv4 multi-homing can't be done without BGP, either. The requirements for Provider Independent address space in IPv6 are identical to the requirements for PI address space in IPv4.
I meant "cheap" multi-homing without a PI address block, like it's used in many small/medium offices where you have multiple ISP links and just failover by changing the SNAT mapping at the gateway when one goes down.
Doing this with ipv6 requires renumbering the whole internal network each time you switch links, or the more costly alternative of getting your own PI block, which in turn isn't IMHO sustainable for the long term because everyone doing it would make the global BGP table grow an awful lot faster that it's already.
OK, so it seems you agree (with the Founders of the Internet) that end-to-end is a good thing..... and now you say it's a bad thing. So is it a good thing or a bad thing then?
My personal opinion is that end-to-end is *generally* a good thing, but shouldn't be *enforced* because there always will be edge cases where it will conflict with privacy.
Er, what??
Do you mean to say that without NAT a firewall is not needed, or that a firewall doesn't impact reachability ?
I'm all for freedom of choice, my problem actually is that you can't use ipv6 NAT even if you want. Not with Linux anyway.
If people want anonymity within their local network, then there will be a market for devices that do IPv6 address cloaking and you can buy one and use it to hide your addresses.
Exactly, you would have to pay for something you can achieve with one iptables command line on ipv4. See my point ?
The lack of SNAT/DNAT targets in Linux ip6tables makes it quite impossible to use ipv6 for any serious enterprise networking. Ipv6 multihoming can't be done without BGP, other solutions like mobile ipv6 or shim6 are - at best - a big mess, also who wants to broadcast his internal network topology/numbering scheme to the whole internet ?
There seems to be some kind of religious taboo here, where the only - supposedly - evil use of NAT (N-to-1 mapping) being taken into consideration, but this is IMHO just plain wrong. Also the NAT haters main argument is that it doesn't preserve end to end reachability (which is not even true for N-to-N mappings), but without NAT everyone is gonna use a stateful firewall for ipv6, and guess what... the effect on reachability is almost exactly the same.
The other problem I have is with anonymity, without NAT every PC in your local network may be identified individually, there are many cases where this may not be desirable.
IMO ipv6 brings some nice new stuff to the table, the most obvious being the xxl address space, but takes away too much for me to consider using it for myself or my customers at the moment.
So AT&T says that VoIP requires "faster speeds". Even using G.711 (i.e., uncompressed toll-quality), and including the overhead of the other layers, VoIP requires only ~120kbps. The thing about VoIP is not that it requires high speed, but that it requires low latency.
g.711 requires 64kbit/s in both directions, also high latency is not really a problem with VoIP (at least anything below 300ms), but the really important thing is low jitter.
If you presume a custom processor that will only execute code signed by an election commission, that would be a first step - the system won't run anything that hasn't been specifically approved for installation on the machine.
If you had RTFPDF, you would have noticed they actually used a clever technique called return based programming, to reuse small parts of trusted code and implement their hack using them.
Nobody in their right mind is using both MD5 and SHA-1 together, and even if they do they are both standardized hash methods. Combining hash methods is dangerous at least and should not be done haphazardly. It would be much better to use SHA-2 256 instead, if only because it is a standardized hash and not some weird combination of two.
I think the author doesn't mean to combine SHA-1 and MD5 to make one hash, but instead using both hashes. This may be weaker for preimage attacks, but a lot stronger against collisions, so if it's what you're after it's one of the best ways to achieve it.
Binary executable files contain a lot of addresses (variables, jump locations,...) that are generated by the assembler at compile time.
Now consider you just add one 1-byte instruction somewhere in the middle of your program (let's say "nop"). When you compile it again, all the code that reference addresses beyond the insert point will have changed because the address has been incremented. So these 4 bytes added to your source code could mean addresses that get incremented in the compiled file in thousands of places.
What they do basically is take the binary file, disassemble it back to pseudo source code (not real asm I guess), and diff that against old version. The patch engine on the client end does the same disassembling, applies the patch, and reassembles the patched source code to an executable file.
This means diffs gets much smaller (4 bytes vs. 1000s in my extreme example), but also makes the diff/patch process much more complex, slower, and not portable.
their technique is specifically geared towards executable binary files, it doesn't make sense to use it, and also won't work at all with any other type of file.
so yes the 9x thing is quite unfair, that's like comparing bzip2 vs. lame for compressing music.
statistically, I think rsync has very few binary files to deal with, at least the way I'm using it.
also, their technique may make the diff data smaller, but it also makes the diffing/patching process a LOT slower, something many rsync users don't want because on a LAN you don't care much about bandwidth usage.
announced a new compression technique called Courgette geared towards distributing really small updates
I just RTFA, this has nothing to do with a compression technique.
What they developed is a technique to make small diffs from *executable binary files* and it doesn't look like it's portable to anything other than x86 because the patch engine has to embed an architecture specific assembler + disasembler.
Slashdot Mirror
Personally I can't understand why it's ok to negligently allow birds to hunt billions of insects and earthworms, but apparently society is fine with that.
You'd only need a super high fps device that detects on/off state of the light, which I guess would be a lot easier and cheaper than a real camera.
Forget CPU and GPU already. The mining difficulty has risen so much recently that what you can mine with them today won't event offset the power costs.
ASICs are the only viable option today for at-home mining, but I'm pretty sure they'll also be rendered useless soon by hosted mining services (CEX.IO already has 25% of the whole Bitcoin network mining power) that are able to consolidate costs and run their mining farms in countries with cheap electricity.
Fact:
97.3% of statements starting with "Fact:" are actually repeated talking points supported by absolutely no real fact.
Don't mix up addressing and computing.
The whole internet would fit in a 64 bit address space, there is really absolutely no need at all for more than 64 bit for addresses in CPUs, that's why x86_64 and other 64 bit archs are here to stay, and you'll probably never see "128 bit" processors at all.
On the other side, today's x86_64 CPUs are capable of 128 bit (SSE) and 256 bit (AVX) computing. The width of the compute units is also bound to increase for some time, with Intel already planning to go 1024 bit in the not-so-far future.
Apparently not today.
Checking for AAAA DNS record
no AAAA record
i686 because I don't see a reason to run x86_64 on 2GB of RAM
x86_64 IA would provide a noticeable performance improvement for some apps, even if you had 640Kb of RAM. It's not only 64-bit addressing but also 64-bit registers (and more of them), 64-bit ALUs, an so on ...
The vector unit must be FMA capable just like Larrabee, hence the doubling of FLOPS/cycle.
Mpath-tools is a set of programs for linux 2.6+ that aim to facilitate load balancing and failover over multiple and heterogeneous ISP connections.
4.0 was NT4 ... my guess is 95/OSR2/98 were all 3.2x
The technique for Phong Shading was introduced in 1973 as an improvement to Gouraud Shading, but was too computationally intensive to be used for graphics back then. This is no longer the case.
It was too computationally intensive for *realtime* rendering in 1973, but clearly not out of reach for the kind of modeling software NASA people were using ...
Also, it should be noted that realtime phong shading was already common in demos/intros running on 33 MHz 386 CPUs back in the 90s
IPv4 multi-homing can't be done without BGP, either. The requirements for Provider Independent address space in IPv6 are identical to the requirements for PI address space in IPv4.
I meant "cheap" multi-homing without a PI address block, like it's used in many small/medium offices where you have multiple ISP links and just failover by changing the SNAT mapping at the gateway when one goes down.
Doing this with ipv6 requires renumbering the whole internal network each time you switch links, or the more costly alternative of getting your own PI block, which in turn isn't IMHO sustainable for the long term because everyone doing it would make the global BGP table grow an awful lot faster that it's already.
OK, so it seems you agree (with the Founders of the Internet) that end-to-end is a good thing. .... and now you say it's a bad thing. So is it a good thing or a bad thing then?
My personal opinion is that end-to-end is *generally* a good thing, but shouldn't be *enforced* because there always will be edge cases where it will conflict with privacy.
Er, what??
Do you mean to say that without NAT a firewall is not needed, or that a firewall doesn't impact reachability ?
With IPv6 I can use NAT if I want.
I'm all for freedom of choice, my problem actually is that you can't use ipv6 NAT even if you want. Not with Linux anyway.
If people want anonymity within their local network, then there will be a market for devices that do IPv6 address cloaking and you can buy one and use it to hide your addresses.
Exactly, you would have to pay for something you can achieve with one iptables command line on ipv4. See my point ?
The lack of SNAT/DNAT targets in Linux ip6tables makes it quite impossible to use ipv6 for any serious enterprise networking. Ipv6 multihoming can't be done without BGP, other solutions like mobile ipv6 or shim6 are - at best - a big mess, also who wants to broadcast his internal network topology/numbering scheme to the whole internet ?
There seems to be some kind of religious taboo here, where the only - supposedly - evil use of NAT (N-to-1 mapping) being taken into consideration, but this is IMHO just plain wrong. Also the NAT haters main argument is that it doesn't preserve end to end reachability (which is not even true for N-to-N mappings), but without NAT everyone is gonna use a stateful firewall for ipv6, and guess what ... the effect on reachability is almost exactly the same.
The other problem I have is with anonymity, without NAT every PC in your local network may be identified individually, there are many cases where this may not be desirable.
IMO ipv6 brings some nice new stuff to the table, the most obvious being the xxl address space, but takes away too much for me to consider using it for myself or my customers at the moment.
Another world just stored vector graphics instead of bitmaps, takes less space, makes it much easier to animate too.
So AT&T says that VoIP requires "faster speeds". Even using G.711 (i.e., uncompressed toll-quality), and including the overhead of the other layers, VoIP requires only ~120kbps. The thing about VoIP is not that it requires high speed, but that it requires low latency.
g.711 requires 64kbit/s in both directions, also high latency is not really a problem with VoIP (at least anything below 300ms), but the really important thing is low jitter.
If you presume a custom processor that will only execute code signed by an election commission, that would be a first step - the system won't run anything that hasn't been specifically approved for installation on the machine.
If you had RTFPDF, you would have noticed they actually used a clever technique called return based programming, to reuse small parts of trusted code and implement their hack using them.
Nobody in their right mind is using both MD5 and SHA-1 together, and even if they do they are both standardized hash methods. Combining hash methods is dangerous at least and should not be done haphazardly. It would be much better to use SHA-2 256 instead, if only because it is a standardized hash and not some weird combination of two.
I think the author doesn't mean to combine SHA-1 and MD5 to make one hash, but instead using both hashes. This may be weaker for preimage attacks, but a lot stronger against collisions, so if it's what you're after it's one of the best ways to achieve it.
Once you've reverted the hash back to salt+plaintext, it's *much* easier to remove the salt (often some string concatenated with the plaintext).
Binary executable files contain a lot of addresses (variables, jump locations, ...) that are generated by the assembler at compile time.
Now consider you just add one 1-byte instruction somewhere in the middle of your program (let's say "nop"). When you compile it again, all the code that reference addresses beyond the insert point will have changed because the address has been incremented. So these 4 bytes added to your source code could mean addresses that get incremented in the compiled file in thousands of places.
What they do basically is take the binary file, disassemble it back to pseudo source code (not real asm I guess), and diff that against old version. The patch engine on the client end does the same disassembling, applies the patch, and reassembles the patched source code to an executable file.
This means diffs gets much smaller (4 bytes vs. 1000s in my extreme example), but also makes the diff/patch process much more complex, slower, and not portable.
their technique is specifically geared towards executable binary files, it doesn't make sense to use it, and also won't work at all with any other type of file.
so yes the 9x thing is quite unfair, that's like comparing bzip2 vs. lame for compressing music.
Simple answer: no
statistically, I think rsync has very few binary files to deal with, at least the way I'm using it.
also, their technique may make the diff data smaller, but it also makes the diffing/patching process a LOT slower, something many rsync users don't want because on a LAN you don't care much about bandwidth usage.
announced a new compression technique called Courgette geared towards distributing really small updates
I just RTFA, this has nothing to do with a compression technique.
What they developed is a technique to make small diffs from *executable binary files* and it doesn't look like it's portable to anything other than x86 because the patch engine has to embed an architecture specific assembler + disasembler.
various software patents owned by various entities.
theora is 100% patent free