Someone once pointed out that hoping a rapist gets raped in prison isn't a victory for his victim(s), because it somehow gives him what he had coming to him, but it's actually a victory for rape and violence. I wish I could remember who said that, because they are right. The score doesn't go Rapist: 1 World: 1. It goes Rape: 2.

What this man did is unspeakable, and he absolutely deserves to spend the rest of his life in prison. If he needs to be kept away from other prisoners as a safety issue, there are ways to do that without keeping him in solitary confinement, which has been shown conclusively to be profoundly cruel and harmful.

Putting him in solitary confinement, as a punitive measure, is not a victory for the good people in the world. It's a victory for inhumane treatment of human beings. This ruling is, in my opinion, very good and very strong for human rights, *precisely* because it was brought by such a despicable and horrible person. It affirms that all of us have basic human rights, even the absolute worst of us on this planet.

Sounds like this won't be resolved until Apple releases its next Xcode update (or Command Line Tools for Xcode if you aren't using the IDE). Looking at previous release dates it seems that Apple releases new versions every three months and the previous version was released 21st of March 2016.

This is precisely why I lost all interest in Oculus the instant I heard that it had been acquired by Facebook.

1. Slackware has spawned lots of distros (including SUSE)
2. Enoch spawned the Gentoo line of distros (and Gentoo is the current base of ChromeOS).
3. The Arch family started independently
4. The on-the-rise Alpine Linux was independently started

So by lineage alone I'd argue there are more than two major categories.

For police to examine a laptop by force, they would require a search warrant. But in this case they probably asked the family to hand it over voluntarily, which the family agreed to do to make the police go away and stop hassling them.

..so there's still the possibility to add a webcam that has a microphone using that (or hook up the keyboard/mouse with that and use a USB webcam) but you're going to need to power. Perhaps for such a setup a Chromebox would be better?

My experience of these changes is that you'll be forced to click through a warning in your browser even if you installed the certificate (or the root CA signing the certificate). The Microsoft page about no longer trusting SHA1 certs is confusing in this respect because it includes information about signing Windows binaries but it does say

That document also says it only applies to certs that are in the Microsoft Root Certificate Program so ones you've manually installed might not be affected.

This is slightly different to the Mozilla's SHA-1 deprecation information:

Perhaps this isn't the override you were thinking of but it doesn't sound like a total block.

The Red Hat Bugzilla link you want is Audit events in /var/log/messages.

(dnf-makecache.timer is basically a "systemd-style" cron job for periodically updating your DNF cache)

I'm tempted to say this isn't a particularly big deal in Europe - if an ISP trys to pull this kind of stunt then the content provider will announce what's happening and folks will just switch ISP. Compare to the US where this *is* a problem because the end users generally don't have a choice of ISP - if the ISP decides to hold Netflix to ransom then Netflix can't just tell their customers to switch ISP.

The password is never supposed to be sent over the air - it is used to generate a cryptographic challenge (from which the password can't be recovered). The problem with this idiotic device is that it allows anyone to telnet into it using a trivially guessable password and it will divulge the wifi password over the telnet connection. So an attacker just needs to convince the kettle to connect to their wifi network instead of the owner's network, eliminating any security the owner's firewall would usually provide.

Packet size is a tradeoff - for high throughput you want big packets, for low latency you want small packets. So fine, just tailor the packet size to your application - well no, when you're sharing a network, the packet sizes used by other applications have a significant impact.

So lets say you're doing something that requires a low latency, such as VoIP. And lets say you've got QoS set up to ensure the small VoIP packets are always inserted in front of any big packets, since that's a sensible thing to do. Look at 2 scenarios:

Scenario 1:
Transmit queue is empty, VoIP packet goes straight to the network card.

Scenario 2:
Transmit queue has a bunch of packets already in it. The VoIP packet goes straight to the head of the queue, but the ethernet card has already started transmitting another packet, so we have to let that finish before the VoIP packet can actually go out onto the network.

On a busy system, scenario 2 would be the norm, so the latency of the VoIP traffic will vary and the receiving end has to even out this latency with a jitter buffer. Lets assume an MTU of 1500 - the transmitting side has only just started transmitting a 1500 byte packet when the VoIP packet enters the queue, on a 2Mbps connection it would take 7.5ms to send this packet before the VoIP packet can start to be transmitted, so you're looking at a 7.5ms jitter on your VoIP session. If the MTU was 64K, the jitter would be a whopping 328ms, which is verging on unusable for VoIP.

Now, you may say that 2Mbps is a slow internet connection, and you'd be right, but it is also a very common speed of internet connection, so doing stuff that breaks it would be bad. Don't forget that you get latency introduced for each hop you do through though - on a 100Mbps connection with a 64K MTU you add up to 6.6ms of latency per hop, so if your traffic goes through 10 100Mbps hops, you're looking at potentially 66ms of latency.

Ideally you'd set the MTU of each interconnect independently of the rest of the network and base it on the jitter level you'd like to achieve (therefore it would be based on that link speed). And indeed this can be done - clients can do path MTU discovery to figure out the minimum MTU on the route between hosts, irrespective of the local MTU. Unfortunately, too many idiot sysadmins set up firewalls to block ICMP packets and that breaks PMTU discovery. Which means that if you're using a "nonstandard" MTU (i.e. not 1500) you _will_ have connectivity problems because your traffic will sometimes traverse firewalls that are set up by said idiots.

I think it could be possible for Chromebooks to be successful without having a significant home market share. If business with all their software online start finding them acceptable the fact they don't run all possible software locally could be seen as advantage (corporates are in a position to make things like Chrome's remote desktoping work). I could see Chromebooks working well for telesales or even places like libraries which are typical homes for existing thin clients...

Yep, my wife doesn't use an ad blocker and her facebook ads are usually showing her stuff she has already bought. This has also caused problems because apparently facebook tailors adverts to your computer, not just your login, and on a couple of occasions I have borrowed her computer and facebook has shown me what she just bought me for christmas, even though I was logged in to FB as myself.

This simply means you aren't the target audience for the advert - if you liked pork bungs then an advert might increase the chance that the next pork bungs you buy will be that particular brand, or someone who likes pork bungs might say "you know what, I feel like having one now".

Now, showing adverts to someone who isn't the target audience is a problem for both you and the advertiser - it annoys you, because your time is being wasted seeing adverts for things you're not interested in, and it costs the advertiser to show you an advert that won't increase their sales. So advertisers then start tracking users to better target their ads - better targetted ads are good for both the advertiser and the end user. Unfortunately, tracking users is a massive can of worms with its own set of problems - now users are being asked to trade privacy for better targeted ads, and that's a trade that a lot of people aren't happy to make.

I think that's a very simplistic view. Google is _both_ a technology firm and an advertising firm. They are symbiotic sides to the same company - neither side can survive without the other (or at least, a replacement for the other).

If you're going to say "Google is an advertising firm, not a technology firm" just because they derive their income from advertising, you may as well say "Lego isn't a toy company, they are a sales company" because they derive their income from sales.