If we want to do this kind of lockdown, we'd need some way to make computers only run authorized software. We'd need a standard for digitally signing OSs, and the BIOS would need to check the signature and enforce that only signed OSs can run. Then the OSs would need to run only whitelisted software.
How hard would it be for governments to coordinate getting a lockdown feature like that into every computer? Well... they don't need to. We already have it. MS has already bludgeoned everybody into supporting Secure Boot, which is exactly this feature/misfeature, in all new computers that ship with Windows (which is most of them -- and the rest support it too because nobody's going to make a separate motherboard just for computers that ship with Windows).
Sure, you can disable Secure Boot... except for when you can't. There are machines (often, not always, laptops) out there right now which don't let you disable Secure Boot, so you're stuck running only approved OSs on them. (MS do the approving, in case you were wondering.) It wouldn't take much at all to expand that to every machine; all it'd take would be MS adding "in order to keep machines secure, don't allow disabling Secure Boot" to the Windows Hardware Certification requirements
Given that we already have systems that will only run approved OSs, it doesn't seem like such a huge leap to "you can only run the software we let you run", especially when all the technology to make that happen is already in place. And, for that matter, being used routinely on tablets and phones.
That article is talking about plugins. The GP is actually talking about extensions. They're two very different types of add-ons.
Of course, they're also dropping support for extensions (and replacing it with support for slightly-improved Greasemonkey scripts). You can't make this stuff up, folks.
In theory. In practice, the result is that the provider is strongly encouraged to under-provision their network so they can charge extreme rates for normal use, citing "high" utilization as an excuse. So you end up with a poor experience at all times, rather than just during disasters.
It'd work well if we had some kind of requirement in place that mandated capacity upgrades such that the system only approaches max capacity less than x% of the time, where x is small. But that's not going to happen.
Except getting rid of XUL doesn't mean no more XUL-based extensions, because XUL-based extensions are actually Javascript-based extensions and Javascript isn't going anywhere. (Some of these extensions do manipulate the main Firefox UI, which is written in XUL, but if it was written in HTML instead then it wouldn't make any difference to extensions -- they'd just be manipulating an HTML document instead of a XUL document.)
No, the reason that "XUL-based extensions" are going is because Mozilla just plain doesn't want them anymore, so they're removing support for them. It's not because they're dropping XUL and "XUL-based" extensions have to go as a dependency.
If I was feeling cynical, I'd suggest that the only reason Mozilla decided to call them "XUL-based extensions" in their announcement (I've never seen them use that term before) is because they wanted to give the impression their hands were tied.
No, it wouldn't. You just get an IP, you don't know which machine was using it at the time (unless you turn off privacy addresses, but then that's your fault.)
The RIAA aren't really well-known for getting the internet. They'd claim that an IP address identifies a person, but it doesn't -- with or without NAT.
Why does it matter? v4 is too small. It doesn't matter if some companies could potentially squeeze into smaller allocations; it won't change the fact that we still need something bigger than v4.
You, or your equipment, is doing something wrong, because v6 is far easier to set up and maintain than v4 is.
Also, you sounded sarcastic, but v6 does indeed improve the routing table situation. "Being really big" is all it needs to reduce fragmentation; that allows ISPs to get a single, contiguous allocation that covers all their needs, compared to v4 where they need to keep getting tiny allocations from all over the place. You can look at Comcast's announcements for an example: they have an order of magnitude fewer v6 prefixes, and the v6 prefixes are mostly empty at the moment, compared to their v4 ones that will be mostly full.
Before RIRs started running out, we were consuming over one/8 per month. What good is an extra month going to do us? Clawing back those/8s is a waste of time and effort, both of which are better spent on just deploying v6, which you'll still have to do anyway.
Last year, ARIN hit one/8 left (that's the second article you linked). Back in July of this year, ARIN had to make their first ever refusal for an allocation on the basis of not having the IP space for it (that's the first article). They still had some space remaining for small allocations. Now, as of yesterday, they have to refuse all allocations on that basis, because they ran out of space altogether. That's this article.
Apparently, the idea that reaching 0% involves going through 10% and 1% first is hard to grasp...
Specifically, RIPE's policy is that each LIR can get one/22 from the final/8, and that's it. The idea is to make sure that new LIRs can at least get some v4 space to run NAT64/CGNAT on.
ARIN didn't think that would be useful, for whatever reason.
Copy/paste them. Or use DNS, it's hardly a new technology.
And if you really can't do either, then pick your addresses better. If you pick addresses like 2001:db8:42:a57e:a92f:2c3d:30c5:7562 rather than 2001:db8:42:1::2 and refuse to use DNS for them, then you can't complain about how hard they are to remember.
With the default filterset (EasyList), it uses a 40,000 line stylesheet. It took about 3 MB per tab (or actually, worse: 3 MB per document, so every iframe used another 3 MB).
I can't imagine that matching all those rules against the page as it loads is particularly fast either...
But in this case the government did do something about it -- and I think it's quite possible that jail time like this will be a far more effective deterrent than the giant bailouts the banks got in the US.
The alternative is to introduce a stable API for extensions to code against if they want to, and make the API powerful enough that most extensions actually can be written with it. And then, for extensions that can't be done in the API, just accept that breakage might happen.
(And note that I said "might", not "will". Many extensions only touch the browser UI and not content pages, and won't be affected by e10s.)
As usual, Mozilla gets most of the way there and then fucks up right at the crucial point; in this case by declaring that if their new API doesn't do the trick, then you can just bugger off somewhere else.
Uh, no. Mozilla tries to fix it by just breaking them once and then never letting anyone fix them*. Everyone not happy, and if that's a WTF to you then I don't know what to say.
*: At least for some subset (the interesting subset) of extensions. Some extensions will be fixable, as they'll merely require a complete rewrite rather then being impossible.
Slashdot Mirror
I feel you are overly optimistic.
If we want to do this kind of lockdown, we'd need some way to make computers only run authorized software. We'd need a standard for digitally signing OSs, and the BIOS would need to check the signature and enforce that only signed OSs can run. Then the OSs would need to run only whitelisted software.
How hard would it be for governments to coordinate getting a lockdown feature like that into every computer? Well... they don't need to. We already have it. MS has already bludgeoned everybody into supporting Secure Boot, which is exactly this feature/misfeature, in all new computers that ship with Windows (which is most of them -- and the rest support it too because nobody's going to make a separate motherboard just for computers that ship with Windows).
Sure, you can disable Secure Boot... except for when you can't. There are machines (often, not always, laptops) out there right now which don't let you disable Secure Boot, so you're stuck running only approved OSs on them. (MS do the approving, in case you were wondering.) It wouldn't take much at all to expand that to every machine; all it'd take would be MS adding "in order to keep machines secure, don't allow disabling Secure Boot" to the Windows Hardware Certification requirements
Given that we already have systems that will only run approved OSs, it doesn't seem like such a huge leap to "you can only run the software we let you run", especially when all the technology to make that happen is already in place. And, for that matter, being used routinely on tablets and phones.
The coming war on general-purpose computing and The Coming Civil War over General Purpose Computing are a good idea to read. I really wish I had my tinfoil hat on here, but sadly this is looking all too realistic.
The GIMP is a very useful, highly functional, stable and reliable piece of software.
...written by developers that think it's ok to piss off a sizeable chunk of their user base.
You're right, I think there should be a word for it.
If a co-worker wants to crop baby photos gimp is the tool. If a co-worker wants to take screenshots and put them in reports gimp is the tool.
Not according to the GIMP developers it's not.
I can only assume this means they'll continue to make GIMP worse for people that just want to use it rather than live their lives with it.
That article is talking about plugins. The GP is actually talking about extensions. They're two very different types of add-ons.
Of course, they're also dropping support for extensions (and replacing it with support for slightly-improved Greasemonkey scripts). You can't make this stuff up, folks.
In theory. In practice, the result is that the provider is strongly encouraged to under-provision their network so they can charge extreme rates for normal use, citing "high" utilization as an excuse. So you end up with a poor experience at all times, rather than just during disasters.
It'd work well if we had some kind of requirement in place that mandated capacity upgrades such that the system only approaches max capacity less than x% of the time, where x is small. But that's not going to happen.
Except getting rid of XUL doesn't mean no more XUL-based extensions, because XUL-based extensions are actually Javascript-based extensions and Javascript isn't going anywhere. (Some of these extensions do manipulate the main Firefox UI, which is written in XUL, but if it was written in HTML instead then it wouldn't make any difference to extensions -- they'd just be manipulating an HTML document instead of a XUL document.)
No, the reason that "XUL-based extensions" are going is because Mozilla just plain doesn't want them anymore, so they're removing support for them. It's not because they're dropping XUL and "XUL-based" extensions have to go as a dependency.
If I was feeling cynical, I'd suggest that the only reason Mozilla decided to call them "XUL-based extensions" in their announcement (I've never seen them use that term before) is because they wanted to give the impression their hands were tied.
No, it wouldn't. You just get an IP, you don't know which machine was using it at the time (unless you turn off privacy addresses, but then that's your fault.)
But you wouldn't? Good.
The RIAA aren't really well-known for getting the internet. They'd claim that an IP address identifies a person, but it doesn't -- with or without NAT.
Same deal. NAT not required there either.
Why does it matter? v4 is too small. It doesn't matter if some companies could potentially squeeze into smaller allocations; it won't change the fact that we still need something bigger than v4.
It does matter, because it means you don't need NAT to be secure.
You, or your equipment, is doing something wrong, because v6 is far easier to set up and maintain than v4 is.
Also, you sounded sarcastic, but v6 does indeed improve the routing table situation. "Being really big" is all it needs to reduce fragmentation; that allows ISPs to get a single, contiguous allocation that covers all their needs, compared to v4 where they need to keep getting tiny allocations from all over the place. You can look at Comcast's announcements for an example: they have an order of magnitude fewer v6 prefixes, and the v6 prefixes are mostly empty at the moment, compared to their v4 ones that will be mostly full.
Too bad there's no proper way to do that.
Yes, take them back. And... then what?
Before RIRs started running out, we were consuming over one /8 per month. What good is an extra month going to do us? Clawing back those /8s is a waste of time and effort, both of which are better spent on just deploying v6, which you'll still have to do anyway.
Ah, four class Cs. That should satisfy demand for a good 2 minutes or so.
v4's problem isn't that parts of it are unused. It's that it's just too small. Returning little blocks here and there won't fix that.
That was a different announcement -- "we had to refuse one request" vs "we have to refuse all requests now".
No, not again.
Last year, ARIN hit one /8 left (that's the second article you linked). Back in July of this year, ARIN had to make their first ever refusal for an allocation on the basis of not having the IP space for it (that's the first article). They still had some space remaining for small allocations. Now, as of yesterday, they have to refuse all allocations on that basis, because they ran out of space altogether. That's this article.
Apparently, the idea that reaching 0% involves going through 10% and 1% first is hard to grasp...
Specifically, RIPE's policy is that each LIR can get one /22 from the final /8, and that's it. The idea is to make sure that new LIRs can at least get some v4 space to run NAT64/CGNAT on.
ARIN didn't think that would be useful, for whatever reason.
Copy/paste them. Or use DNS, it's hardly a new technology.
And if you really can't do either, then pick your addresses better. If you pick addresses like 2001:db8:42:a57e:a92f:2c3d:30c5:7562 rather than 2001:db8:42:1::2 and refuse to use DNS for them, then you can't complain about how hard they are to remember.
With the default filterset (EasyList), it uses a 40,000 line stylesheet. It took about 3 MB per tab (or actually, worse: 3 MB per document, so every iframe used another 3 MB).
I can't imagine that matching all those rules against the page as it loads is particularly fast either...
That's exactly what Bitcoin does: it's a way to transfer real money around. It doesn't attempt to be a proper currency itself.
Although that doesn't stop people from thinking that it is, and then going around telling everybody that it sucks for not working well as one...
But in this case the government did do something about it -- and I think it's quite possible that jail time like this will be a far more effective deterrent than the giant bailouts the banks got in the US.
Firefox did it first, of course: chrome://browser/content/browser.xul
The alternative is to introduce a stable API for extensions to code against if they want to, and make the API powerful enough that most extensions actually can be written with it. And then, for extensions that can't be done in the API, just accept that breakage might happen.
(And note that I said "might", not "will". Many extensions only touch the browser UI and not content pages, and won't be affected by e10s.)
As usual, Mozilla gets most of the way there and then fucks up right at the crucial point; in this case by declaring that if their new API doesn't do the trick, then you can just bugger off somewhere else.
Uh, no. Mozilla tries to fix it by just breaking them once and then never letting anyone fix them*. Everyone not happy, and if that's a WTF to you then I don't know what to say.
*: At least for some subset (the interesting subset) of extensions. Some extensions will be fixable, as they'll merely require a complete rewrite rather then being impossible.