I would like to offer a radically different experience. I use a git repository for synching *all* my work-related files (binary or not) across four machines, one of them located abroad. Two of those repository copies are on a VirtualBox filesystem, accessed from a virtualized PC, and for one of these the.vdi file resides on a SATA HDD drive mounted over USB2, so rather low-end performance. The repository is currently at 74 GB (yes, GB), and I am entirely satisfied with git's performance when it comes to adding, merging, checking out, and so on. Only the initial git add/commit/push cycle that sent the first 50 GB abroad was a bit cumbersome (took overnight). Admittedly, this is only a huge master branch and a temporary 'scratch' branch that I switch to when pushing files between the repos, but still, I expect to hit 100 GB in a year or two and no complaints.
I hate when people say that something is "3 times slower," as if that means anything. I know what they are trying to say, but the correct way to express it is "one-third the speed," or "one-third as fast."
Just imagine "slowness", measured in s/m, is the reciprocal of "speed". Three times slower means its slowness is three times bigger compared to the reference, thus it's 1/3 of its speed. Worth making a fuss of?
It seems like the "vulnerability" that the article is talking about only happens when a recipient of the dropbox file link copies that link address into a google search query. If the user just clicks the link like a normal person, there is no problem.
No, that's only half the problem. The other half is that if your shared document contains a link to, say, cnn.com and someone clicks this link straight from within the document, cnn.com can look at the referrer field and get the "secret" link to your document.
But you don't need a network exploit to worry. Secunia PSI routinely pointed out buffer overflows in how.mid files were handled in Winamp, prompting for an update. Now, I don't play.mid files, but if someone discovers an exploit like that in, say, how Winamp handles m4a or ogg files, with no dev to fix the security hole, how can you be sure your existing installation is not used to pwn your machine the next time you play a media file from teh internetz? Winamp hasn't changed much over the last few years, but at least they were patching security holes.
Voltage loss over such a cable is very real. At 0.14 mm^2 (AWG 26) you get 0.14 mOhm/m. For a 2m cable, 2 wires you end up with 0.56 Ohm. At 1.5 A that's a voltage drop of 0.84V.
A factor of 1000 snuck out on you here. You went from milliohms to ohms in a second.
Make has flags to enable and disable printing of output. If you want to debug your shit, just enable the output printing.
"Just enable" works when the 'make' you execute is the only one. In a maze of scripts and Makefiles and scripts generating Makefiles and scripts generating scripts that call make, euphemistically called "a custom buildsystem", hunting down the right 'make' to change into 'make -d' can take a while.
Seconded. I use a 65GB git repo across four machines (two of them virtual) to sync my entire work history on a daily basis. Occasional 200MB files in there, but mostly smaller stuff (source, binaries, PDFs, word documents, datafiles). Never had a problem so far. Admittedly, no branching, just keeping a few hundred thousand files in sync across four machines so that I don't have to worry where my files are when I go somewhere with my laptop only.
However, they have no way of passing this knowledge to their offspring, because we do not select them for human scrutiny. Unless you agree with Lamarck.
Yes, "well-known algorithms" is my use case -- massive LAPACK generalized diagonalizations that take forever on a single CPU, almost forever when threaded with openMP-capable BLAS to, say 8 cores, and do not scale at all to distributed-memory clusters (ScaLAPACK with MPI) because the comms becomes a bottleneck.
Thus I'm hoping for a solution where the vendor themselves wrangles those intrinsics in their BLAS or LAPACK implementation in MKL with me oblivious to all that mess. Assuming the computation time scales O(N^3) and the memory transfer over the bus scales O(N^2), with the prefactors in my favour, I should be able to squeeze out a significant performance boost.
Does Intel's MKL support the Phis out of the box? It would be very convenient if, instead of having to re-write code for them, we could just use phi-capable BLAS and LAPACK.
The eye doesn't see, the brain does. The eye simply collects light and other signals (like the aforementioned focus thing) and transmits them to the brain, where the image is actually formed -- the image landing on the retina, for instance, is upside down and backwards. But you see things right side up and not backwards; the brain does that.
I agree with the gist of your argument; however, I think you've got the specifics wrong. Fun fact: human retina is actually considered part of the brain.
Subscripts (CO2), superscripts (cd/m2), funny symbols (tensorial multiplication, degree, aleph,...), equations (including those with funny symbols in superscripts -- e.g. dagger), arrows (chemical reactions) -- to name a few off the top of my head.
Fair point. But with a finite upper bound for all computation that can be performed before the entropic death of the universe, if you can make these ticks exponentially longer, you will eventually find out.
Now how could one of my simulated subjects prove or disprove that they weren't living in my intelligently designed simulated universe, with me as their god, and that the simulation hadn't only started 6 seconds ago? I can't see a way.
Easily. They would only have to start observing so many individual events at once that you'd run of out computing power trying to simulate them all in all their detail.
What is the use for them? for "personal" use, floats are all you will ever need. Many physics computation stays in single precision to avoid doubling the memory usage. I guess fluid mecanic computation use double, but is there really a use for quad. Who needs that kind of precisions?
Not all uses are personal and the fact that some physics calculations trade precision for memory doesn't mean that all of them do.
One example could be matrix inversions with somewhat ill-conditioned matrices. When you know you're going to lose 14 digits of precision inverting the matrix, you'd better have a lot of headroom. Cue quad floats.
The car analogy that comes to mind is people often do sound mixing with 32-bit audio even though you 16-bit audio is perfectly fine for listening to the product.
Slashdot Mirror
I would like to offer a radically different experience. I use a git repository for synching *all* my work-related files (binary or not) across four machines, one of them located abroad. Two of those repository copies are on a VirtualBox filesystem, accessed from a virtualized PC, and for one of these the .vdi file resides on a SATA HDD drive mounted over USB2, so rather low-end performance. The repository is currently at 74 GB (yes, GB), and I am entirely satisfied with git's performance when it comes to adding, merging, checking out, and so on. Only the initial git add/commit/push cycle that sent the first 50 GB abroad was a bit cumbersome (took overnight). Admittedly, this is only a huge master branch and a temporary 'scratch' branch that I switch to when pushing files between the repos, but still, I expect to hit 100 GB in a year or two and no complaints.
I hate when people say that something is "3 times slower," as if that means anything. I know what they are trying to say, but the correct way to express it is "one-third the speed," or "one-third as fast."
Just imagine "slowness", measured in s/m, is the reciprocal of "speed". Three times slower means its slowness is three times bigger compared to the reference, thus it's 1/3 of its speed. Worth making a fuss of?
Worse yet: if you're alone in your car, your car might actually choose to kill you.
Now that would promote carpooling.
It seems like the "vulnerability" that the article is talking about only happens when a recipient of the dropbox file link copies that link address into a google search query. If the user just clicks the link like a normal person, there is no problem.
No, that's only half the problem. The other half is that if your shared document contains a link to, say, cnn.com and someone clicks this link straight from within the document, cnn.com can look at the referrer field and get the "secret" link to your document.
write the partition table.
and also we wouldn't have batteries with capacities like 2000 milliamp-hours - it would be simplified to 2 amp-hours
Surely, you mean 7.2 kamp-seconds, or just 7.2 kC?
Precedence is a bitch, the US set the precedent and now they are winging about what is happening in Crimea !!
Precedence only matters in law, in places that use common law. In other legal systems, precedence doesn't matter at all.
It matters diplomatically and in propaganda.
Being DOS the only solution was to hit the hard reset button.
Meh, you just map the int 00 vector onto int 05 and you're ready to go. Press "Print Screen" anytime to divide by zero and terminate current process.
So what is the default solution for free (or paid) AV software these days?
Microsoft security essentials for the free one.
But you don't need a network exploit to worry. Secunia PSI routinely pointed out buffer overflows in how .mid files were handled in Winamp, prompting for an update. Now, I don't play .mid files, but if someone discovers an exploit like that in, say, how Winamp handles m4a or ogg files, with no dev to fix the security hole, how can you be sure your existing installation is not used to pwn your machine the next time you play a media file from teh internetz? Winamp hasn't changed much over the last few years, but at least they were patching security holes.
Voltage loss over such a cable is very real. At 0.14 mm^2 (AWG 26) you get 0.14 mOhm/m. For a 2m cable, 2 wires you end up with 0.56 Ohm. At 1.5 A that's a voltage drop of 0.84V.
A factor of 1000 snuck out on you here. You went from milliohms to ohms in a second.
Make has flags to enable and disable printing of output. If you want to debug your shit, just enable the output printing.
"Just enable" works when the 'make' you execute is the only one. In a maze of scripts and Makefiles and scripts generating Makefiles and scripts generating scripts that call make, euphemistically called "a custom buildsystem", hunting down the right 'make' to change into 'make -d' can take a while.
Seconded. I use a 65GB git repo across four machines (two of them virtual) to sync my entire work history on a daily basis. Occasional 200MB files in there, but mostly smaller stuff (source, binaries, PDFs, word documents, datafiles). Never had a problem so far. Admittedly, no branching, just keeping a few hundred thousand files in sync across four machines so that I don't have to worry where my files are when I go somewhere with my laptop only.
Hitler ate sugar!
However, they have no way of passing this knowledge to their offspring, because we do not select them for human scrutiny. Unless you agree with Lamarck.
Yes, "well-known algorithms" is my use case -- massive LAPACK generalized diagonalizations that take forever on a single CPU, almost forever when threaded with openMP-capable BLAS to, say 8 cores, and do not scale at all to distributed-memory clusters (ScaLAPACK with MPI) because the comms becomes a bottleneck.
Thus I'm hoping for a solution where the vendor themselves wrangles those intrinsics in their BLAS or LAPACK implementation in MKL with me oblivious to all that mess. Assuming the computation time scales O(N^3) and the memory transfer over the bus scales O(N^2), with the prefactors in my favour, I should be able to squeeze out a significant performance boost.
Excellent. Thank you.
Does Intel's MKL support the Phis out of the box? It would be very convenient if, instead of having to re-write code for them, we could just use phi-capable BLAS and LAPACK.
Yeah, but how is the dog supposed to pass that knowledge onto its successor?
Through the Baldwin effect, presumably.
The eye doesn't see, the brain does. The eye simply collects light and other signals (like the aforementioned focus thing) and transmits them to the brain, where the image is actually formed -- the image landing on the retina, for instance, is upside down and backwards. But you see things right side up and not backwards; the brain does that.
I agree with the gist of your argument; however, I think you've got the specifics wrong. Fun fact: human retina is actually considered part of the brain.
Subscripts (CO2), superscripts (cd/m2), funny symbols (tensorial multiplication, degree, aleph, ...), equations (including those with funny symbols in superscripts -- e.g. dagger), arrows (chemical reactions) -- to name a few off the top of my head.
Fair point. But with a finite upper bound for all computation that can be performed before the entropic death of the universe, if you can make these ticks exponentially longer, you will eventually find out.
Now how could one of my simulated subjects prove or disprove that they weren't living in my intelligently designed simulated universe, with me as their god, and that the simulation hadn't only started 6 seconds ago? I can't see a way.
Easily. They would only have to start observing so many individual events at once that you'd run of out computing power trying to simulate them all in all their detail.
And from those he created the Word. And there were two Bytes in the Word
Was the Word big-endian or little-endian?
What is the use for them? for "personal" use, floats are all you will ever need. Many physics computation stays in single precision to avoid doubling the memory usage. I guess fluid mecanic computation use double, but is there really a use for quad. Who needs that kind of precisions?
Not all uses are personal and the fact that some physics calculations trade precision for memory doesn't mean that all of them do.
One example could be matrix inversions with somewhat ill-conditioned matrices. When you know you're going to lose 14 digits of precision inverting the matrix, you'd better have a lot of headroom. Cue quad floats.
The car analogy that comes to mind is people often do sound mixing with 32-bit audio even though you 16-bit audio is perfectly fine for listening to the product.