Just remember time discounting and the generally shoddy statistical intuitions of humans: While I don't doubt that your assessment is correct (I don't have the data, you do, and in any case I'm willing to agree for sake of argument), you have the sex first, sometimes even without consequence(I forget the exact stats; but some combination of failure to fertilize and early-stage spontaneous abortion keep even unprotected sex during fertile periods from leading to recognizable pregnancy 100% of the time, and the odds fall further in lower fertility periods) and then have to deal with kiddo later.
Given that humans tend to markedly discount future costs, and do basically every horrible thing imaginable to statistical judgements, it may well be simultaneously true that your assessment of overall cost over time is correct and laziness(in combination with poor assessment of risk-discounted future costs, and/or short term lapses in judgement caused by the relative attractiveness of futzing with a condom or hot animalistic fucking) leads people to keep having kids where a less-lazy approach would more rigorously apply preventative measures.
Those certainly are plausible (and unfortunately common) issues. That's why I was thinking of the "you want to make sure that you aren't suddenly being fed a different certificate than people in other parts of the world, or on different ISPs" consideration. Annoyingly, that's the one that would require some sort of distributed observation system that you could talk to, rather than being comparatively trivial to do in software on your own system (as of right now, browsers don't usually provide a handy 'remember this domain's certificate and freak out?' button; but that's extension-level stuff to add). The thinking being that, short of the MiTM either compromising the observation system, or controlling so much of the network that their certificate looks like the trustworthy one, it would be impossible for a given attacker to present a false certificate to a numerous people in different parts of the world and connected to different parts of the internet.
Of course, the details of how to actually implement such a system, along with actually doing so, are a great deal trickier than just checking key continuity on the client...
Thankfully, the American Mall, once a backbone of the consumer experience, has apparently hit hard times, thus freeing up a substantial (probably depressing) amount of parking lot. If Millstone Station has developed advanced parking-lot-storage technology, we should be set for centuries to come!
If somebody were planning a bold replacement, it'd be neat to see something that actually took even slight advantage of the advances in what constitutes an acceptable database. With flat files, you can do some neat stuff by bringing a revision control system into the picture: see who made changes and when? No problem. Roll back a change? No problem. Diff what we are doing now with what we were doing six months ago? No problem. Spinning up a new machine? Just check out the configuration files and you are set. (I'm mostly a dabbler, so this never became my problem; but I imagine that a fully-robust implementation of this would be markedly more difficult, in that you'd need to know what was/wasn't critical to getting a network connection up and running, whether specific files were routinely churned so often as to be overwhelming, etc.; but for a hobby-scale handling of handpicked cases it's very convenient.)
If you went the database route, it'd be nice to see something designed with making querying, setting, and otherwise manipulating configurations (across any tractable number of systems that share enough authentication goo for it to work) something you get 'automatically' because of the fact that the config is in a database, rather than something you get, in bits and pieces, through specific utilities and hacks.
I think that that (aside from the relatively shallow learning curve, at least for applications whose config files aren't utter garbage) is what makes people so fond of text config files. You can modify them by hand; but because it's just text, basically anything that can spit strings and do useful things to them automatically serves as a potentially viable, even powerful, configuration editor. With binary configuration storage, you have a much more impoverished set of tools, in most cases (though a properly chosen binary format would be better off than ghastly legacy junk).
(The other factor, not strictly a consequence of registry vs. config files; but one that still seems to break down substantially, though not exclusively, along those lines, is what software vendors, especially 3rd party ones, choose to store: Even if you are totally satisfied with your registry editor tools, the unpleasant fact is that a lot of common software was clearly designed with absolutely no consideration of its configuration being edited except through the (usually GUI) interface it provides. Is it in the registry? Sure, the first run of the program created 50-odd dword values, each one more cryptic than the last. If you change a setting in the program and look again, sometimes you can see which one(s) changed. Obviously, absolutely nothing prevents an application with a text config file from doing the same, or worse, by just dumping a bunch of cryptic-fuck-you-hex values into its config; but some mixture of historical tradition and the implicit 'It's a text file, a human might read it...' pressure seems to keep that more restrained, whether it be in the assorted.ini files that hang on in dark corners of Windows, or in the Unixlikes.)
Inconveniently, it would be hard to argue that we've made an improvement with any of our succeeding choices, especially if you like your exercises of power to be sparing and judicious.
While many colleges offer (arguably unecessarily) cushy gym facilities, they also tend to price anything they can describe as a PE 'class' more or less the same as anything else with credit-hours attached, though obviously only some majors accept many or any such credit hours for anything being fulfilling distribution requirements, at schools where those exist.
Now, I'm actually not sure if gym/coach staff are lower-paid than adjunct professors anymore; but you can pay some pretty silly prices on campus if you want some fairly minimal coaching or oversight, rather than just making things up in the gym; but that gets classed as a class. The base charges for whatever facilities are there, though, tend to either be low or Mandatory, so if self-directed is your thing, it's less of an issue.
He didn't say that 'power-seeking' was depraved, he said that two specific people were both depraved and power-seekers. Slight difference.
Though, since you ask, exercising power over others is something of a necessary evil, so while I don't rule out the possibility of perfectly decent people who also hold positions of authority, I do tend to default to skepticism about the character of anybody who appears too fond of it (and if they treat it as theirs by right? Very. Bad. Sign.)
Seeking to perfect power over the ever-troublesome natural world and self are, certainly, noble endeavors; but with power of the political flavor, the only honor is in exercising it as sparingly and judiciously as you can.
It's weird. You go and found a country that forbids noble titles and state religions and you get the US. You head across the pond to the UK, and you've got a monarchy less influential than some congressional committee positions and a state religion that can't even get people out of bed and into church one day a week(and the remaining subscribers are greying out pretty dangerously).
As best I can tell, the closest things to 'IT unions' are employer cartels (like the one that settled as fast as possible relatively recently, lest the discovery get really interesting). Despite any empirical evidence to the contrary, the employees have substantially bought the line that they are just too special and above average to be dragged down by obstructionist union thugs who worship only seniority.
I'd be inclined to suspect that the stagnation of the W3C and IETF is more a symptom than a cause: they might be 'central planners' in the sense that they get a bunch of technocrats together and try to hammer out the Glorious 3rd Five Year Plan; but they lack essentially all power that a real central planner would have(either to expropriate anyone who sneaks a patent into an IETF standard, or to crush somebody who just wanders off and does his own thing).
Trouble is, if you just wander off and do your own thing, you swiftly learn that the internet of today, unlike the early internet, is huge, heavily populated by people and companies who see it as a necessary evil rather than having any active desire to deal with it, and a certain amount of perverse cat-and-mouse caused by 'security'(why does so much stuff use, or look like, HTTP over port 80, even if it probably isn't the best solution? Because anything that doesn't won't be visible to cube drones slacking off or people on really shit ISPs...)
Given that it takes time for hardware and software to age out and be replaced, it's obviously a bad thing that the people who should be working on future standards, to guide the implementation of what replaces the stuff aging out, have absorbed the inertia of the larger internet (Even if it won't actually be in the field until everybody's old shit drops dead, it'll never reach production if it isn't hammered out and ready to be baked in to the replacements when that does happen); but I'd be very, very, surprised if the standards bodies actually manage to impose stagnation, rather than drawing their membership heavily(but somewhat unavoidably) from entities in the grips of stagnation themselves.
It's probably not for nothing that it was Google, rather than somebody smaller, who came up with that proposal: in terms of engineering resources a substantially smaller company could have done it; but they wouldn't be able to say "Yeah, here's our HTTP replacement. We think it's pretty neat, and will probably use it when the millions of users of our browser and/or operating system contact our tens to hundreds of thousands of servers, which is often. If you guys like it, you can use it too; but even if you don't, we don't really care."
If you are very big, or a lot of your product line is very insular, there is still nothing preventing you from Just Doing It and assuming that things will work out(because, in your case, they very well might). If you are not one of those things, the pond in which you are a small fish is vastly larger than it used to be...
The trouble is that SSL is really playing two roles that aren't trivial to separate, because of the 'well-just-MiTM-with-a-self-signed-cert' problem; but which are substantially at odds with one another in other respects.
You've got identification, which you only really want in a subset of cases (your bank, say); but which is actually slightly expensive to do properly and then you've got encryption, which you want in basically all cases (would you ever not at least want it?) which is cheap; but requires the certificate.
Arguably, what we really need is some mechanism for measuring (presumably by consulting some number of 3rd parties, ideally widely distributed) certificate stability and certificate duration.
There are some certificates where you would actually want somebody to have done some thorough checking that the entity on the cert is who they say they are. However, much of the time your main concern is that the certificate isn't an MiTM, and that you are talking to the same person or entity you were talking to previously. You don't actually need to know their Real Official Name or anything; but you want to be sure that you aren't suddenly being fed a different certificate than people in other parts of the world, or on different ISPs, and you want to be sure that the certificate didn't change suddenly for mysterious reasons.
They do. Unfortunately, the 'shady software' is "basically all client software that does SSL/TLS and is designed with end users in mind". Because nobody really wants to bite the bullet and scare the users, all major OSes and browsers 'trust' a horrifying number of dubious CAs unless manually configured otherwise.
Given the (lack of) alternatives, it's hard to blame them for doing that rather than being abandoned by users; but it's pretty much the state of play right now.
Sure; but the people who use them prefer that they fill up as slowly as possible, because then they have to go identify another site that isn't at the other end of nowhere, has a lot of room, and nobody nearby who can make NIMBY stick. Clay-based litters are pretty much wholly innocuous, this isn't one of the 'green' replacements where the original was some sort of polychlorinated death that they are trying to phase out; but they add unnecessary volume to the solid waste stream, and volume is pretty much what you pay for in non-specialized waste disposal.
They rank rather low on the nastiness scale of even stuff that people are supposed to put in municipal trash, not just what they do put in there; but they are a fairly obvious low-hanging fruit for diverting something that would otherwise be landfilled into the compostable/yard waste category instead.
Apple's track record? Apple is actually pretty agnostic about open standards, they don't seem to have a pathological case of NIH syndrome or anything; but with two important caveats:
1. If the existing standard doesn't suit them for whatever reason, their implementation will be a variant of that standard and their only concern will be interoperability will first party and (to a slightly lesser extent) officially-blessed third party stuff. They won't reinvent the wheel just for kicks; but if they decide that their needs are somewhat different, their implementation will be as well, and it's just too bad if that's an issue. (It's not unlike the degree to which Microsoft 'based' Active Directory and Domains on, LDAP and Kerberos.)
2. Crypto: Unlike the old days, when you could only be proprietary by keeping your obfuscated binary protocol or your weirdo connector one step ahead of the reverse engineers, now you can have it all in the open and still nearly useless unless it's signed and blessed. Apple's "Facetime", for instance, is based on a lovely, standards-tastic, collection of standards; but important parts of setting up a connection involve mutual certificate verification between an Apple server and an Apple device, so that's effectively irrelevant to 3rd parties.
I have this chilling image of the waste packaging contractor dealing with a minor logistical mishap by just sending a couple of trucks over to Valu-Mart to buy whatever cat litter they had on the shelf and come back so they could get this week's barrels packed and shipped on time...
As you say, there isn't any systemic incentive to make the change, and nobody would approve it if it were formally submitted as a change proposal; so some sort of improvising using off-the-shelf litter that was incorrectly labelled (or just purchased by somebody who didn't know the salient details of why certain litters but not others were acceptable) seems like the most plausible thing I can imagine, though 'improvising' isn't really a virtue in this context.
It's considered a nuisance in this context because it's largely inert (and often formulated for absorbency and clumping, so people are advised not to flush it): Once used, the clay just adds weight and bulk to the solid waste stream and won't be going anywhere in approximately geologic time. Aside from very modest risks from mineral dusts, it's harmless enough; but it's not wildly efficient to landfill something that's mostly clay just to deal with animal feces that would degrade in a few weeks to months under proper conditions.
It's particularly weird given how touchy XP was about install media: even with a valid key and install medium that provided the same version(home, pro, etc.) it would inevitably whine if you used a retail key with OEM media, the reverse, or any other mismatched combination it happened to dislike, even if the result would be identical to what the poor sucker trying to install had a license key for.
Given that POS probably wasn't sold at a discount, I would have expected it to at least freak out at it being enabled on a system with a different category of license key and quite possibly to be something that would require a fresh install or major surgery to change after the fact.
I'm honestly a bit surprised that MS didn't bother to tie point-of-sale status to XP's license authentication mechanism, even in some relatively trivial way.
They were certainly willing to do that with some updates (anything where good old 'Windows Genuine Advantage' popped up) and, while the suitably motivated generally bypassed that without too much trouble, I imagine that that sort of wicked, wicked, circumvention made their legal position markedly less pleasant if MS wished to push the issue.
If it's just a registry key, no ties to the activation system at all, the situation starts to look a lot more like spoofing a browser UA to encourage the server to send you the version of the page it sends to some different browser.
Arguably, the bigger problem with devices like this is going to be that anything that screams "We Don't Care!", is born with an outdated version of Android, and is probably beyond easy 3rd-party remedy (unless HP has relaxed a bit since I picked up a cheap refurb of theirs to play with x86-android on, it'll be locked up fairly tight and without even an ADB or fastboot driver), is that it'll be obsolete fast.
On the PC side, it offends the purists; but you can reasonably expect ages of support and at least security updates by comparison. MS hates it; but their product lifecycle is pretty long, and all but the oddest PC components will have OEM drivers for the current Windows throughout its life, and often the next one (except scanners, those things are just shit, even compared to printers, not certain why.)
This thing? You don't care how cyanogen-friendly it is because you are the second coming of RMS, you care because that's the only thing that will keep it from dying with the same lousy stock build it was born with.
I have trouble clearing Himalayan Blackberries because of folks that seem to think they can't get enough fruit from the massive patch on the other side of the fence. Fools.
M9A1-7. Just be sure to practice looking innocent before using.
Given that 'being eaten' is the plan for plants that go to considerable metabolic expense to produce attractive fruits or berries, those probably aren't good candidates for this strategy. (Admittedly, humans probably excrete more of the seeds into the water treatment plant than birds do, so they probably aren't the ideal customer; but fruits are still the deliberately expendable seed carriers, not life-critical components.)
Let's hope the rest of the earth's species don't adopt this plan to control the invasive naked apes.
At a population level, the reverse might actually be true:
One of the few tactics that any species large enough to gun down faster than it can reproduce, or touchy enough that you can just set its habitat on fire, can embrace to survive, and even thrive, is to be docile and tasty. Humans go crazy for that, and promptly allocate massive amounts of effort, and delicious calories, to encouraging your population to increase dramatically. Sure, then they put a captive-bolt stunner into your brain and chop you up for parts; but being a darwinian winner isn't about quality of life...
Don't forget the influence of history: R wasn't designed for superiority to Python, Julia, and Ruby; but in large part to be a GNU-acceptable implementation of S, which may well have been designed for superiority to APL and FORTRAN; and which has existed since somewhere between the-before-time-when-the-gods-were-young and the start of the Second Trilobite War.
Slashdot Mirror
Just remember time discounting and the generally shoddy statistical intuitions of humans: While I don't doubt that your assessment is correct (I don't have the data, you do, and in any case I'm willing to agree for sake of argument), you have the sex first, sometimes even without consequence(I forget the exact stats; but some combination of failure to fertilize and early-stage spontaneous abortion keep even unprotected sex during fertile periods from leading to recognizable pregnancy 100% of the time, and the odds fall further in lower fertility periods) and then have to deal with kiddo later.
Given that humans tend to markedly discount future costs, and do basically every horrible thing imaginable to statistical judgements, it may well be simultaneously true that your assessment of overall cost over time is correct and laziness(in combination with poor assessment of risk-discounted future costs, and/or short term lapses in judgement caused by the relative attractiveness of futzing with a condom or hot animalistic fucking) leads people to keep having kids where a less-lazy approach would more rigorously apply preventative measures.
Insane. We flew within 2 months of our daughter being born and will be taking her to Japan next year. It is an excuse for the lazy.
What model of aircraft is now full of people who loath you?
Those certainly are plausible (and unfortunately common) issues. That's why I was thinking of the "you want to make sure that you aren't suddenly being fed a different certificate than people in other parts of the world, or on different ISPs" consideration. Annoyingly, that's the one that would require some sort of distributed observation system that you could talk to, rather than being comparatively trivial to do in software on your own system (as of right now, browsers don't usually provide a handy 'remember this domain's certificate and freak out?' button; but that's extension-level stuff to add). The thinking being that, short of the MiTM either compromising the observation system, or controlling so much of the network that their certificate looks like the trustworthy one, it would be impossible for a given attacker to present a false certificate to a numerous people in different parts of the world and connected to different parts of the internet.
Of course, the details of how to actually implement such a system, along with actually doing so, are a great deal trickier than just checking key continuity on the client...
Thankfully, the American Mall, once a backbone of the consumer experience, has apparently hit hard times, thus freeing up a substantial (probably depressing) amount of parking lot. If Millstone Station has developed advanced parking-lot-storage technology, we should be set for centuries to come!
If somebody were planning a bold replacement, it'd be neat to see something that actually took even slight advantage of the advances in what constitutes an acceptable database. With flat files, you can do some neat stuff by bringing a revision control system into the picture: see who made changes and when? No problem. Roll back a change? No problem. Diff what we are doing now with what we were doing six months ago? No problem. Spinning up a new machine? Just check out the configuration files and you are set. (I'm mostly a dabbler, so this never became my problem; but I imagine that a fully-robust implementation of this would be markedly more difficult, in that you'd need to know what was/wasn't critical to getting a network connection up and running, whether specific files were routinely churned so often as to be overwhelming, etc.; but for a hobby-scale handling of handpicked cases it's very convenient.)
.ini files that hang on in dark corners of Windows, or in the Unixlikes.)
If you went the database route, it'd be nice to see something designed with making querying, setting, and otherwise manipulating configurations (across any tractable number of systems that share enough authentication goo for it to work) something you get 'automatically' because of the fact that the config is in a database, rather than something you get, in bits and pieces, through specific utilities and hacks.
I think that that (aside from the relatively shallow learning curve, at least for applications whose config files aren't utter garbage) is what makes people so fond of text config files. You can modify them by hand; but because it's just text, basically anything that can spit strings and do useful things to them automatically serves as a potentially viable, even powerful, configuration editor. With binary configuration storage, you have a much more impoverished set of tools, in most cases (though a properly chosen binary format would be better off than ghastly legacy junk).
(The other factor, not strictly a consequence of registry vs. config files; but one that still seems to break down substantially, though not exclusively, along those lines, is what software vendors, especially 3rd party ones, choose to store: Even if you are totally satisfied with your registry editor tools, the unpleasant fact is that a lot of common software was clearly designed with absolutely no consideration of its configuration being edited except through the (usually GUI) interface it provides. Is it in the registry? Sure, the first run of the program created 50-odd dword values, each one more cryptic than the last. If you change a setting in the program and look again, sometimes you can see which one(s) changed. Obviously, absolutely nothing prevents an application with a text config file from doing the same, or worse, by just dumping a bunch of cryptic-fuck-you-hex values into its config; but some mixture of historical tradition and the implicit 'It's a text file, a human might read it...' pressure seems to keep that more restrained, whether it be in the assorted
Inconveniently, it would be hard to argue that we've made an improvement with any of our succeeding choices, especially if you like your exercises of power to be sparing and judicious.
While many colleges offer (arguably unecessarily) cushy gym facilities, they also tend to price anything they can describe as a PE 'class' more or less the same as anything else with credit-hours attached, though obviously only some majors accept many or any such credit hours for anything being fulfilling distribution requirements, at schools where those exist.
Now, I'm actually not sure if gym/coach staff are lower-paid than adjunct professors anymore; but you can pay some pretty silly prices on campus if you want some fairly minimal coaching or oversight, rather than just making things up in the gym; but that gets classed as a class. The base charges for whatever facilities are there, though, tend to either be low or Mandatory, so if self-directed is your thing, it's less of an issue.
He didn't say that 'power-seeking' was depraved, he said that two specific people were both depraved and power-seekers. Slight difference.
Though, since you ask, exercising power over others is something of a necessary evil, so while I don't rule out the possibility of perfectly decent people who also hold positions of authority, I do tend to default to skepticism about the character of anybody who appears too fond of it (and if they treat it as theirs by right? Very. Bad. Sign.)
Seeking to perfect power over the ever-troublesome natural world and self are, certainly, noble endeavors; but with power of the political flavor, the only honor is in exercising it as sparingly and judiciously as you can.
Because Americans love dynasties. Duh!
It's weird. You go and found a country that forbids noble titles and state religions and you get the US. You head across the pond to the UK, and you've got a monarchy less influential than some congressional committee positions and a state religion that can't even get people out of bed and into church one day a week(and the remaining subscribers are greying out pretty dangerously).
Not sure how that happened.
As best I can tell, the closest things to 'IT unions' are employer cartels (like the one that settled as fast as possible relatively recently, lest the discovery get really interesting). Despite any empirical evidence to the contrary, the employees have substantially bought the line that they are just too special and above average to be dragged down by obstructionist union thugs who worship only seniority.
I'd be inclined to suspect that the stagnation of the W3C and IETF is more a symptom than a cause: they might be 'central planners' in the sense that they get a bunch of technocrats together and try to hammer out the Glorious 3rd Five Year Plan; but they lack essentially all power that a real central planner would have(either to expropriate anyone who sneaks a patent into an IETF standard, or to crush somebody who just wanders off and does his own thing).
Trouble is, if you just wander off and do your own thing, you swiftly learn that the internet of today, unlike the early internet, is huge, heavily populated by people and companies who see it as a necessary evil rather than having any active desire to deal with it, and a certain amount of perverse cat-and-mouse caused by 'security'(why does so much stuff use, or look like, HTTP over port 80, even if it probably isn't the best solution? Because anything that doesn't won't be visible to cube drones slacking off or people on really shit ISPs...)
Given that it takes time for hardware and software to age out and be replaced, it's obviously a bad thing that the people who should be working on future standards, to guide the implementation of what replaces the stuff aging out, have absorbed the inertia of the larger internet (Even if it won't actually be in the field until everybody's old shit drops dead, it'll never reach production if it isn't hammered out and ready to be baked in to the replacements when that does happen); but I'd be very, very, surprised if the standards bodies actually manage to impose stagnation, rather than drawing their membership heavily(but somewhat unavoidably) from entities in the grips of stagnation themselves.
It's probably not for nothing that it was Google, rather than somebody smaller, who came up with that proposal: in terms of engineering resources a substantially smaller company could have done it; but they wouldn't be able to say "Yeah, here's our HTTP replacement. We think it's pretty neat, and will probably use it when the millions of users of our browser and/or operating system contact our tens to hundreds of thousands of servers, which is often. If you guys like it, you can use it too; but even if you don't, we don't really care."
If you are very big, or a lot of your product line is very insular, there is still nothing preventing you from Just Doing It and assuming that things will work out(because, in your case, they very well might). If you are not one of those things, the pond in which you are a small fish is vastly larger than it used to be...
The trouble is that SSL is really playing two roles that aren't trivial to separate, because of the 'well-just-MiTM-with-a-self-signed-cert' problem; but which are substantially at odds with one another in other respects.
You've got identification, which you only really want in a subset of cases (your bank, say); but which is actually slightly expensive to do properly and then you've got encryption, which you want in basically all cases (would you ever not at least want it?) which is cheap; but requires the certificate. Arguably, what we really need is some mechanism for measuring (presumably by consulting some number of 3rd parties, ideally widely distributed) certificate stability and certificate duration.
There are some certificates where you would actually want somebody to have done some thorough checking that the entity on the cert is who they say they are. However, much of the time your main concern is that the certificate isn't an MiTM, and that you are talking to the same person or entity you were talking to previously. You don't actually need to know their Real Official Name or anything; but you want to be sure that you aren't suddenly being fed a different certificate than people in other parts of the world, or on different ISPs, and you want to be sure that the certificate didn't change suddenly for mysterious reasons.
They do. Unfortunately, the 'shady software' is "basically all client software that does SSL/TLS and is designed with end users in mind". Because nobody really wants to bite the bullet and scare the users, all major OSes and browsers 'trust' a horrifying number of dubious CAs unless manually configured otherwise.
Given the (lack of) alternatives, it's hard to blame them for doing that rather than being abandoned by users; but it's pretty much the state of play right now.
Sure; but the people who use them prefer that they fill up as slowly as possible, because then they have to go identify another site that isn't at the other end of nowhere, has a lot of room, and nobody nearby who can make NIMBY stick. Clay-based litters are pretty much wholly innocuous, this isn't one of the 'green' replacements where the original was some sort of polychlorinated death that they are trying to phase out; but they add unnecessary volume to the solid waste stream, and volume is pretty much what you pay for in non-specialized waste disposal.
They rank rather low on the nastiness scale of even stuff that people are supposed to put in municipal trash, not just what they do put in there; but they are a fairly obvious low-hanging fruit for diverting something that would otherwise be landfilled into the compostable/yard waste category instead.
Apple's track record? Apple is actually pretty agnostic about open standards, they don't seem to have a pathological case of NIH syndrome or anything; but with two important caveats:
1. If the existing standard doesn't suit them for whatever reason, their implementation will be a variant of that standard and their only concern will be interoperability will first party and (to a slightly lesser extent) officially-blessed third party stuff. They won't reinvent the wheel just for kicks; but if they decide that their needs are somewhat different, their implementation will be as well, and it's just too bad if that's an issue. (It's not unlike the degree to which Microsoft 'based' Active Directory and Domains on, LDAP and Kerberos.)
2. Crypto: Unlike the old days, when you could only be proprietary by keeping your obfuscated binary protocol or your weirdo connector one step ahead of the reverse engineers, now you can have it all in the open and still nearly useless unless it's signed and blessed. Apple's "Facetime", for instance, is based on a lovely, standards-tastic, collection of standards; but important parts of setting up a connection involve mutual certificate verification between an Apple server and an Apple device, so that's effectively irrelevant to 3rd parties.
I have this chilling image of the waste packaging contractor dealing with a minor logistical mishap by just sending a couple of trucks over to Valu-Mart to buy whatever cat litter they had on the shelf and come back so they could get this week's barrels packed and shipped on time...
As you say, there isn't any systemic incentive to make the change, and nobody would approve it if it were formally submitted as a change proposal; so some sort of improvising using off-the-shelf litter that was incorrectly labelled (or just purchased by somebody who didn't know the salient details of why certain litters but not others were acceptable) seems like the most plausible thing I can imagine, though 'improvising' isn't really a virtue in this context.
It's considered a nuisance in this context because it's largely inert (and often formulated for absorbency and clumping, so people are advised not to flush it): Once used, the clay just adds weight and bulk to the solid waste stream and won't be going anywhere in approximately geologic time. Aside from very modest risks from mineral dusts, it's harmless enough; but it's not wildly efficient to landfill something that's mostly clay just to deal with animal feces that would degrade in a few weeks to months under proper conditions.
It's particularly weird given how touchy XP was about install media: even with a valid key and install medium that provided the same version(home, pro, etc.) it would inevitably whine if you used a retail key with OEM media, the reverse, or any other mismatched combination it happened to dislike, even if the result would be identical to what the poor sucker trying to install had a license key for.
Given that POS probably wasn't sold at a discount, I would have expected it to at least freak out at it being enabled on a system with a different category of license key and quite possibly to be something that would require a fresh install or major surgery to change after the fact.
I'm honestly a bit surprised that MS didn't bother to tie point-of-sale status to XP's license authentication mechanism, even in some relatively trivial way.
They were certainly willing to do that with some updates (anything where good old 'Windows Genuine Advantage' popped up) and, while the suitably motivated generally bypassed that without too much trouble, I imagine that that sort of wicked, wicked, circumvention made their legal position markedly less pleasant if MS wished to push the issue.
If it's just a registry key, no ties to the activation system at all, the situation starts to look a lot more like spoofing a browser UA to encourage the server to send you the version of the page it sends to some different browser.
Unfortunately, in the case of a lot of point of sale systems, the acronym does double duty. At least they are surprisingly expensive.
Arguably, the bigger problem with devices like this is going to be that anything that screams "We Don't Care!", is born with an outdated version of Android, and is probably beyond easy 3rd-party remedy (unless HP has relaxed a bit since I picked up a cheap refurb of theirs to play with x86-android on, it'll be locked up fairly tight and without even an ADB or fastboot driver), is that it'll be obsolete fast.
On the PC side, it offends the purists; but you can reasonably expect ages of support and at least security updates by comparison. MS hates it; but their product lifecycle is pretty long, and all but the oddest PC components will have OEM drivers for the current Windows throughout its life, and often the next one (except scanners, those things are just shit, even compared to printers, not certain why.)
This thing? You don't care how cyanogen-friendly it is because you are the second coming of RMS, you care because that's the only thing that will keep it from dying with the same lousy stock build it was born with.
I have trouble clearing Himalayan Blackberries because of folks that seem to think they can't get enough fruit from the massive patch on the other side of the fence. Fools.
M9A1-7. Just be sure to practice looking innocent before using.
Given that 'being eaten' is the plan for plants that go to considerable metabolic expense to produce attractive fruits or berries, those probably aren't good candidates for this strategy. (Admittedly, humans probably excrete more of the seeds into the water treatment plant than birds do, so they probably aren't the ideal customer; but fruits are still the deliberately expendable seed carriers, not life-critical components.)
Let's hope the rest of the earth's species don't adopt this plan to control the invasive naked apes.
At a population level, the reverse might actually be true:
One of the few tactics that any species large enough to gun down faster than it can reproduce, or touchy enough that you can just set its habitat on fire, can embrace to survive, and even thrive, is to be docile and tasty. Humans go crazy for that, and promptly allocate massive amounts of effort, and delicious calories, to encouraging your population to increase dramatically. Sure, then they put a captive-bolt stunner into your brain and chop you up for parts; but being a darwinian winner isn't about quality of life...
Don't forget the influence of history: R wasn't designed for superiority to Python, Julia, and Ruby; but in large part to be a GNU-acceptable implementation of S, which may well have been designed for superiority to APL and FORTRAN; and which has existed since somewhere between the-before-time-when-the-gods-were-young and the start of the Second Trilobite War.