Debian doesn't cross-compile, all architectures are required to build everything natively.
Some packages do allow cross-compilation, and its obviously needed for bootstrapping a new arch, but that's for things you do locally rather than what gets uploaded to the archive.
You're describing a JBOD setup then analyze its failure rate as if it was an 8-way RAID1. GP's point stands: the true failure chance is 11.3%.
Without any kind of replication, any disk failing means your system fails immediately. If, on the other hand, you had those SSDs in a RAID, a fair comparison would require a RAID on the HDD side as well.
Make a RSA keypair. Put one in the generator, have it take a sequence: x, x+1, x+2, x+3,... and encrypt it with the key. As long as initial x is good enough to not repeat during testing, this generator will pass every known randomness test with flying colors.
But let's see if some three letter agency has the other key in the pair...
The documentation explicitly says cases like this are optimized away. This also makes writing parametrized queries easier: you don't need to care about optional arguments, as the server will do this for you.
You also need to watch what address you actually reply to, some of these spammers are cunning and will set up individual emails to respond to if they are determined enough to confirm addresses.
It's easy to spot these, as they include a long opaque string that either serves as an identifier or has your info encoded in it.
/dev/random has been fixed, anything that uses get_random_int() is not. And that function could trivially be modified to mix RdRand's output rather than use it exclusively.
It's like emailing an 'unsubscribe' message to spammers, and will work as well.
Actually, it works pretty well. Obviously, you use a spamtrap account rather than your own as the sender. For best effects, make two: aaron@example.com and zzyx@example.com, to ensure your spam filter has a chance to autolearn first (most spammers sort their databases).
You have to live a pretty sheltered life to think you're going to drive through any neighborhood and get dragged out of your car and robbed.
On 4th year at the university, I got a place in a student dormitory in a bad part of the city. I lasted only ten days there, and got attacked seven times. For comparison, I've never been attacked elsewhere during my university times, and got attacked a total of three times elsewhere during my whole adult life.
I don't look out of ordinary, don't wear strange clothes, etc. I'm white and so is almost everyone around here (Poland). Now, guess what would happen if a black person walked through that neighbourhood.
It's not a matter of race, it's a case of tribalism. Race is just a convenient way to tell outsiders, if it's not a factor those oh-so-nice fellow humans will find a different reason to bash your face in.
The most important part: what this daemon does is allowing remove access to the computer, through Parallels' servers, using closed source code on both sides. Let's see, is there anything nefarious possible?
Meh, what really counts is the relative size of the fan+radiator compared to the computer. It's hard to beat mine (+ its fan). Now go find the computer in the first image... (specs).
You have still way too much faith in the government. Their primary concern is monetizing (or otherwise consummating) the power they got. Spying alone won't get them bribes^Wcampaign donations, it's merely a tool to make the donations less likely to dry out.
Or will it disable ETags across all sites and thus slow down browsing by effectively turning caching off?
ETags are only one of many methods to achieve caching. Getting rid of them shouldn't have a big effect on caching.
Other methods typically have privacy holes as well, but it's easier to deal with them, for example by rounding timestamps down to the last midnight. ETags on the other hand store an arbitrary attacker-provided string, which is an outright security vulnerability.
Except that self-driving cars are already greatly safer than those driven by humans. If such a car doesn't cooperate with government surveillance, it doesn't degrade your freedom -- and as an useful tool, actually improves it. You can do whatever you want when travelling...
Add a physical keyboard, like N900, and you instantly get a micro-laptop. Give it sane default configuration of input devices (unlike Nokia) and you hit a large niche that's currently empty.
Slashdot Mirror
That explains why there isn't a version of Debian for Mac68K
There is, just among second class architectures. It used to be dead but has been dragged back to life.
There's another option: 64 bit kernel, 32 bit userspace. And if you do multiarch or (eeew) multilib, you can have a gradual transition.
Debian doesn't cross-compile, all architectures are required to build everything natively.
Some packages do allow cross-compilation, and its obviously needed for bootstrapping a new arch, but that's for things you do locally rather than what gets uploaded to the archive.
here's another: when I switched to an SSD at work my compile times were cut by more than half
Here's a -j switch for you. Please learn how to use it. If any part of the compile is waiting for the disk, you'd better fix your tools.
If you're really a developer, you'll see your compile times cut by a factor of 5-10
Please tell me, in what circumstances sources you're building are not already in memory?
And even if they were not, just increase the -j level by one so no CPU time is lost waiting for I/O. So both builds will be CPU-bound.
Sorry, but if your compile times change noticeably, much less by a factor of 5-10 as you say, you're doing it wrong.
You're describing a JBOD setup then analyze its failure rate as if it was an 8-way RAID1. GP's point stands: the true failure chance is 11.3%.
Without any kind of replication, any disk failing means your system fails immediately. If, on the other hand, you had those SSDs in a RAID, a fair comparison would require a RAID on the HDD side as well.
The problem is, not all places in the kernel mix RDRAND output. After GKH's fixes, /dev/random does, but get_random_int() does not.
Here's a RNG of a very high quality:
Make a RSA keypair. Put one in the generator, have it take a sequence: x, x+1, x+2, x+3, ... and encrypt it with the key. As long as initial x is good enough to not repeat during testing, this generator will pass every known randomness test with flying colors.
But let's see if some three letter agency has the other key in the pair...
The documentation explicitly says cases like this are optimized away. This also makes writing parametrized queries easier: you don't need to care about optional arguments, as the server will do this for you.
I agree with you about using mysql, though.
Especially as BDB got relicensed to a non-free license.
Few people know they can do so. For the vast majority, there's no option but the default.
You also need to watch what address you actually reply to, some of these spammers are cunning and will set up individual emails to respond to if they are determined enough to confirm addresses.
It's easy to spot these, as they include a long opaque string that either serves as an identifier or has your info encoded in it.
/dev/random has been fixed, anything that uses get_random_int() is not. And that function could trivially be modified to mix RdRand's output rather than use it exclusively.
It's like emailing an 'unsubscribe' message to spammers, and will work as well.
Actually, it works pretty well. Obviously, you use a spamtrap account rather than your own as the sender. For best effects, make two: aaron@example.com and zzyx@example.com, to ensure your spam filter has a chance to autolearn first (most spammers sort their databases).
You have to live a pretty sheltered life to think you're going to drive through any neighborhood and get dragged out of your car and robbed.
On 4th year at the university, I got a place in a student dormitory in a bad part of the city. I lasted only ten days there, and got attacked seven times. For comparison, I've never been attacked elsewhere during my university times, and got attacked a total of three times elsewhere during my whole adult life.
I don't look out of ordinary, don't wear strange clothes, etc. I'm white and so is almost everyone around here (Poland). Now, guess what would happen if a black person walked through that neighbourhood.
It's not a matter of race, it's a case of tribalism. Race is just a convenient way to tell outsiders, if it's not a factor those oh-so-nice fellow humans will find a different reason to bash your face in.
The most important part: what this daemon does is allowing remove access to the computer, through Parallels' servers, using closed source code on both sides. Let's see, is there anything nefarious possible?
Meh, what really counts is the relative size of the fan+radiator compared to the computer. It's hard to beat mine (+ its fan). Now go find the computer in the first image... (specs).
they only offer a four week warranty
The cost of shipping to Korea and back, together with customs fees, makes warranty pretty moot.
I'll be more impressed when I can actually buy a sub $100 PC
Here, for $89. Helluva better CPU than these: 4*2.0 instead of 1*1.0 ($45) or 4*1.0 ($120).
Sadly, it has no eSATA (just some extra-fast eMMC), and 100Mb ethernet instead of 470Mb you get in the $95 and $120 CuBox models.
Other competition seems to be several times as expensive and have terrible specs.
You have still way too much faith in the government. Their primary concern is monetizing (or otherwise consummating) the power they got. Spying alone won't get them bribes^Wcampaign donations, it's merely a tool to make the donations less likely to dry out.
No, this means the amount of laws needs to be cut by a factor of 100 if not 1000.
Or will it disable ETags across all sites and thus slow down browsing by effectively turning caching off?
ETags are only one of many methods to achieve caching. Getting rid of them shouldn't have a big effect on caching.
Other methods typically have privacy holes as well, but it's easier to deal with them, for example by rounding timestamps down to the last midnight. ETags on the other hand store an arbitrary attacker-provided string, which is an outright security vulnerability.
I don't know, his review looks a bit obsessed or trolling, the way he repeats "BED BUGS" and all that.
Like, say, he was upset because of getting ravaged by the little buggers in the middle of the night?
Except that self-driving cars are already greatly safer than those driven by humans. If such a car doesn't cooperate with government surveillance, it doesn't degrade your freedom -- and as an useful tool, actually improves it. You can do whatever you want when travelling...
Add a physical keyboard, like N900, and you instantly get a micro-laptop. Give it sane default configuration of input devices (unlike Nokia) and you hit a large niche that's currently empty.