Then your brother doesn't know when to resign. FFS there are only 169 points on a 13/13 board, so to lose by 180 means he was wiped out and played 11 more stones back into your territory which you subsequently captured.
Last I checked, you could legitimately get media on which the CSS-section was writable; but it was about £80 per disc, instead of the £4/disc I paid for regular media or the £15/disc you'd pay to actually buy the films.
Re:Now what do we use?
on
SHA-1 Broken
·
· Score: 1
the function crypt() was and is pretty good. The program/usr/bin/crypt was the crap one.
I was required to apply for a munitions export license from the US State Department when I wanted to buy some cryptographic hardware from the US in 2001 (I live in the UK).
They seemed to process it automatically -- I doubt they did a background check in the time it took, but the process was still there then at any rate.
The CSS title-key is in a fixed place on the disc. Commercial (re)writable DVDs have this section of the disc set to all 0s, and it cannot be altered.
So you can't just do a bitwise copy, unless the source DVD isn't encrypted, you need to break the CSS encryption and write the unencrypted data to your destination disc.
> There's no way to derive the original work or anything close to it from the checksum.
I said the checksum was a derivative work because it had been produced from the original file. It does not matter that there are many other ways to get that sequence of digits, nor does it matter that the original cannot be reconstituted from the checksum -- the process of creating a derivative work is and has always been one-way.
As to your proposed service, I'd say you would be infringing copyright. No-one would sue you over it because of the bad PR, but that doesn't make it legal.
Anime films/series are cartoons in the same sense that 8 mile was a kind of musical.
Just because it was a different style of music didn't make it a different thing, and just because an anime is (sometimes) animated with more care or in a different style doesn't mean it isn't a cartoon.
To send a network packet in C: construct it in your program; call write(), which is a system call.
To send a network packet in Java: construct it in your program; call YadaYada.write(), which copies it across the JNI to a C module; C module calls write() which is a system call.
No matter how fast the JNI is, CROSSING IT WILL ALWAYS BE SLOWER THAN NOT CROSSING IT.
This is not a difficult concept. The JNI tax applies whenever you need to do anything which must be accomplished with a native call. File I/O, drawing GUIs, Network I/O, accessing user input -- all these things and more require that the native way of doing things be converted to/from the Java way of doing things. Admittedly, the VM does some of these internally without the full-price JVM getting involved.
Java has a runtime cost, and the JNI is a large part of that (because a sufficiently good JIT helps with everything else). It's up to you to determine if the development-time benefits (if any) are large enough to warrant the run-time cost for your projects.
I had to use Registered DDR RAM in my last PC (a Tyan Tiger MP), because I had all four slots filled. It's more expensive, and has 1-memory-bus-cycle higher latency than unbuffered RAM. On modern systems, if your processor has to load from memory you've already lost a lot of time, and making it 1-cycle worse doesn't make a lot of difference. It won't affect prefetching code either, unless it's been specifically tuned for unbuffered RAM (and unless it's a custom app, this won't have happened). I don't think ECC hurts performance as the circuitry for that is quite small and built in to your memory bus controller already.
Don't buy registered unless you need it (your mobo manual will tell you) because it's expensive. Don't buy ECC unless you want the reliability and you're sure your system supports it as it's also more expensive.
The performance considerations shouldn't sway your decision, as on all modern systems they're essentially irrelevant.
Portable Java is slow, because you have to use the abstract types sun give you rather than exploit your platform's capabilities.
The JVM initialisation time is waaay longer than the C runtime initialisation time on every platform I've tested, which makes short-running processes feel awful in Java.
Finally, whenever it becomes necessary to actually _do_ anything, the JNI must be crossed, and that's slow.
With/usr/bin/time -- it's an average over the entire program's runtime. I was trying to write the fastest matrix multiplier I could, not to try and set a usage record. With plain C, optimised by gcc of the time, my n-a-side matrix, n-vector product took just under 2 minutes. With hand-rolled assembler, it took 50 seconds. I forget what n was, but 8*n*(n+1) bytes fit into main memory.
Interestingly, the ratio of times and the ratio of processor usage didn't seem very strongly correllated, so I guess the gcc-generated code was doing executing a lot of unnecessary instructions (that or a stalled load counts as usage).
My personal record for CPU usage on x86 is 112%. This was on a Pentium IV with a hand-tuned assembler matrix-vector product program. TO get > 100% you need to keep 1 execution unit fully busy while occasionally using others. In my case, the FPU was maxed out, the memory-unit doing prefetchnta's accounted for most of the rest, and the final few % were the integer unit updating loop counters.
It's pretty hard to do this, and I doubt it's possible for many programs. Feel free to try tho...
Slashdot Mirror
Real players don't play with the super-ko rule.
Then your brother doesn't know when to resign. FFS there are only 169 points on a 13/13 board, so to lose by 180 means he was wiped out and played 11 more stones back into your territory which you subsequently captured.
He was talking about the accelerator, not QEMU in its entirety.
Last I checked, you could legitimately get media on which the CSS-section was writable; but it was about £80 per disc, instead of the £4/disc I paid for regular media or the £15/disc you'd pay to actually buy the films.
the function crypt() was and is pretty good. The program /usr/bin/crypt was the crap one.
I was required to apply for a munitions export license from the US State Department when I wanted to buy some cryptographic hardware from the US in 2001 (I live in the UK).
They seemed to process it automatically -- I doubt they did a background check in the time it took, but the process was still there then at any rate.
Cheers,
Phil
The CSS title-key is in a fixed place on the disc. Commercial (re)writable DVDs have this section of the disc set to all 0s, and it cannot be altered.
So you can't just do a bitwise copy, unless the source DVD isn't encrypted, you need to break the CSS encryption and write the unencrypted data to your destination disc.
Phil
If you're going to put the "é" on the end, you should also put the ï in the middle:
naïveté - n, the state in which a slashdot user credulously believes he can add an accent to a word and not get flamed.
And, since I can't listen to this at work, would someone like to summarise why mono needs to be defended from anything (and what).
Phil
If anything blogging is a "legacy" of open-source. Article author clearly has no concept of how long open-source software has existed.
l
The GNU project was announced on 27 September 1983:
http://www.gnu.org/gnu/initial-announcement.htm
Whereas the HTTP protocol became an RFC in May 1996:
http://www.rfc-editor.org/rfc/rfc1945.txt
Although it was in use as early as 1990.
Regardless, open-source software clearly predates blogging, as blogging could not have existed before there was a web on which to log.
Rant over.
Phil
> There's no way to derive the original work or anything close to it from the checksum.
I said the checksum was a derivative work because it had been produced from the original file. It does not matter that there are many other ways to get that sequence of digits, nor does it matter that the original cannot be reconstituted from the checksum -- the process of creating a derivative work is and has always been one-way.
As to your proposed service, I'd say you would be infringing copyright. No-one would sue you over it because of the bad PR, but that doesn't make it legal.
Phil
Legally, it doesn't matter if you _could_ have got those numbers some other way. What matters is how you actually _did_ get them.
Phil
The piece checksums in the .torrent file are derived from the content of the file(s) being shared.
.torrent file contains a derivative of an unauthorised derivative of a coyrighted work, and is therefore fair game.
The files being shared are in this case unauthorised derivative works of copyrighted material.
So the
Or at least, that's how I would read the law. I'm not a lawyer.
Phil
Wongronongg.
Anime films/series are cartoons in the same sense that 8 mile was a kind of musical.
Just because it was a different style of music didn't make it a different thing, and just because an anime is (sometimes) animated with more care or in a different style doesn't mean it isn't a cartoon.
Phil
Not quite. The fremen stillsuit recycles liquid output into potable water, whereas this is talking about recycling water and CO2 into O2.
Read this very carefully.
To send a network packet in C: construct it in your program; call write(), which is a system call.
To send a network packet in Java: construct it in your program; call YadaYada.write(), which copies it across the JNI to a C module; C module calls write() which is a system call.
No matter how fast the JNI is, CROSSING IT WILL ALWAYS BE SLOWER THAN NOT CROSSING IT.
This is not a difficult concept. The JNI tax applies whenever you need to do anything which must be accomplished with a native call. File I/O, drawing GUIs, Network I/O, accessing user input -- all these things and more require that the native way of doing things be converted to/from the Java way of doing things. Admittedly, the VM does some of these internally without the full-price JVM getting involved.
Java has a runtime cost, and the JNI is a large part of that (because a sufficiently good JIT helps with everything else). It's up to you to determine if the development-time benefits (if any) are large enough to warrant the run-time cost for your projects.
Phil
I had to use Registered DDR RAM in my last PC (a Tyan Tiger MP), because I had all four slots filled. It's more expensive, and has 1-memory-bus-cycle higher latency than unbuffered RAM. On modern systems, if your processor has to load from memory you've already lost a lot of time, and making it 1-cycle worse doesn't make a lot of difference. It won't affect prefetching code either, unless it's been specifically tuned for unbuffered RAM (and unless it's a custom app, this won't have happened). I don't think ECC hurts performance as the circuitry for that is quite small and built in to your memory bus controller already.
Don't buy registered unless you need it (your mobo manual will tell you) because it's expensive. Don't buy ECC unless you want the reliability and you're sure your system supports it as it's also more expensive.
The performance considerations shouldn't sway your decision, as on all modern systems they're essentially irrelevant.
Phil
Still probably cheaper to buy your extra RAM from crucial...
Portable Java is slow, because you have to use the abstract types sun give you rather than exploit your platform's capabilities.
The JVM initialisation time is waaay longer than the C runtime initialisation time on every platform I've tested, which makes short-running processes feel awful in Java.
Finally, whenever it becomes necessary to actually _do_ anything, the JNI must be crossed, and that's slow.
Phil
With /usr/bin/time -- it's an average over the entire program's runtime. I was trying to write the fastest matrix multiplier I could, not to try and set a usage record. With plain C, optimised by gcc of the time, my n-a-side matrix, n-vector product took just under 2 minutes. With hand-rolled assembler, it took 50 seconds. I forget what n was, but 8*n*(n+1) bytes fit into main memory.
Interestingly, the ratio of times and the ratio of processor usage didn't seem very strongly correllated, so I guess the gcc-generated code was doing executing a lot of unnecessary instructions (that or a stalled load counts as usage).
Phil
Nope:
dun writ
-or-
dun writted
would however have been acceptable.
My personal record for CPU usage on x86 is 112%. This was on a Pentium IV with a hand-tuned assembler matrix-vector product program. TO get > 100% you need to keep 1 execution unit fully busy while occasionally using others. In my case, the FPU was maxed out, the memory-unit doing prefetchnta's accounted for most of the rest, and the final few % were the integer unit updating loop counters.
It's pretty hard to do this, and I doubt it's possible for many programs. Feel free to try tho...
Phil
Shouldn't it read: Microsoft hopes to win their main appeal that they (Microsoft) had *not* abused their software dominance.
Either that or: Microsoft hopes to win their main appeal against the ruling that they (Microsoft) had abused their software dominance.
Probably realised the lawyers would cost more than the fines.