I doubt it does. In fact, I'm willing to bet it does not, because every time I see this complaint (and I see it all the time), it is because an idiot PHB made a stupid, uninformed, technically clueless decision. Standards compliance is never on the RFP of a PHB. And if it is, it disappears as soon as the PHB gets distracted by something shiny.
If it is something PHBs love, it is vendor lockin.
You chose your vendor poorly. Hope you learned from it. Next time choose a standards based VPN solution that works across many different platforms and clients.
Even worse, because every SOC is a haphazard pile of random and arbitrarily buggy peripherals, there is no deterministic way (at run time) to enumerate all of the peripherals, and thus which various driver variants (and even worse, binary blobs) are required to make them work.
So by definition, none of this can EVER go into the mainline. Every kernel fork is its own disconnected universe, dedicated to a single snapshot of a single SOC and its particular collection of peripherals.
But if you try to explain this to a PHB (or, say TI), you'll get nothing but blank stares. There is nobody home.
The reason embedded device kernels never get updated is because the source code for them is on some SOC vendor's way out there fork of some ancient kernel that nobody with a clue actively develops for anymore.
And the vendor (say, TI) had hired a bunch of clueless interns to write the "BSP"s (old acronym from the binary blob obsessed asshats at vxworks et al) for their SOCs and the cluster of shoddily designed peripherals crowbarred into the SOC.
And those interns wrote code so toxic and broken that no sane kernel developer would ever have accept any of their garbage into any mainline kernel tree.
So there are all these embedded devices out there with kernels from the 90s, and it would take time (and expertise) that none of the vendors have (including the SOC suppliers, like TI) to merge the changes into something even remotely contemporary.
All of this because the requirements for these embedded projects (dictated by clueless PHBs) is only "linux support" not "mainline kernel support", so SOC vendors (like TI) just don't have the incentive to develop SOC peripheral driver code suitable for mainline inclusion.
You don't have to be intelligent/reasonable to control intelligent/reasonable people, you just have to convince them that you are. You can go on being a clueless dipshit in all other respects.
Because if you aren't incompetent, you won't get yelled at.
Unlike a corporate structure, where you don't get yelled if you play the game right.
If you are incompetent, please don't develop linux kernel code. Go work for a corporation.You'll find you're a better fit, and if you play your cards right, you won't get yelled at no matter how bad you are at your job.
It's a shame that browsers have such freakouts over self signed certs, because there is really little difference between them and officially signed certs
Exactly. Especially since you can get a "real" cert from one of many, many, free cert signing services. What is the point?
I'm not Arker, and his analysis hides all kinds of issues, especially considering not every gun out there is a.22lr pistol.
Bottom line, Armatix doesn't want you carrying their firearms for self defense for a reason. Somehow I don't think cops would take kindly to you telling them they have to replace all of their carry weapons with.22lr
This is exactly the point. The things that drive violent crime are not caused by increased firearm ownership rates. To that extent, you an expect any efforts to reduce firearm ownership rates to have no effect on violent crime.
What are the odds that somebody is going to run up to you while you are target shooting or hunting, wrest your firearm from you, and shoot you with it?
Non-critical firearms are generally stored locked and unloaded when there is a concern that a child or unauthorized person might get a hold of it.
I'm not sure I follow. I am saying I dislike all legislation that makes firearms less reliable, including mag disconnects and poorly designed drop safeties.
I don't think most LCIs (unless very poorly designed) affect reliability, aside from the fact that they add more (pointless, IMO) complexity to the slide.
In any case, the problem with roster legislation is that while their stated purpose is "safety", they are invariably expanded to include any tech that can be added, such that it is becomes harder and harder to import new models into the state. A perfect example is CA's roster laws: even firearms that are identical (except cosmetically) to rostered models have to be re-submitted for testing *and* are required to adhear to all new rostering requirements, even though other identical models (albiet older) are already on the roster.
At no point are any new features ever subject to any scrutiny with regards to safety.... for example, microstamping. Is a firearm that does not have microstamping less safe than one that does?
Now you could argue that to you, it doesn't matter. All you care about is that there are less firearms being sold in CA. That is fine. That is your opinion. But you cannot claim the roster is about the "safety" of individual firearms, only that it is having the desired effect of slowing importation of firearms into the state.
TSA trying oh so very hard to appear effective.
If it doesn't feature the Carnot cycle, it isn't actually A/C, IMO.
Suing likely will cost more than just eating the remainder of the service contract, AND has no guarantee of success.
This is why the whole "proprietary software is supported so it has a lower TCO" is often a myth.
Lockin always has risk, and to that extent, presents a very real cost.
He has a choice.
Pay lawyers to get out of the contract (and run the risk of paying lawyers and STILL being on contract).
Eat the remainder of the support costs, learn from his mistakes, and move on.
Guess which probably costs less and has a better EV?
Either way, somebody made a poor decision, and it is going to cost money and time.
I doubt it does. In fact, I'm willing to bet it does not, because every time I see this complaint (and I see it all the time), it is because an idiot PHB made a stupid, uninformed, technically clueless decision. Standards compliance is never on the RFP of a PHB. And if it is, it disappears as soon as the PHB gets distracted by something shiny. If it is something PHBs love, it is vendor lockin.
You chose your vendor poorly. Hope you learned from it. Next time choose a standards based VPN solution that works across many different platforms and clients.
if (ret = fun()) printf ("fun failed, ret=%d\n", ret);
Now, of course most compilers warn you when you do that...
Absolutely. The situation is not sustainable.
Even worse, because every SOC is a haphazard pile of random and arbitrarily buggy peripherals, there is no deterministic way (at run time) to enumerate all of the peripherals, and thus which various driver variants (and even worse, binary blobs) are required to make them work.
So by definition, none of this can EVER go into the mainline. Every kernel fork is its own disconnected universe, dedicated to a single snapshot of a single SOC and its particular collection of peripherals.
But if you try to explain this to a PHB (or, say TI), you'll get nothing but blank stares. There is nobody home.
The reason embedded device kernels never get updated is because the source code for them is on some SOC vendor's way out there fork of some ancient kernel that nobody with a clue actively develops for anymore.
And the vendor (say, TI) had hired a bunch of clueless interns to write the "BSP"s (old acronym from the binary blob obsessed asshats at vxworks et al) for their SOCs and the cluster of shoddily designed peripherals crowbarred into the SOC.
And those interns wrote code so toxic and broken that no sane kernel developer would ever have accept any of their garbage into any mainline kernel tree.
So there are all these embedded devices out there with kernels from the 90s, and it would take time (and expertise) that none of the vendors have (including the SOC suppliers, like TI) to merge the changes into something even remotely contemporary.
All of this because the requirements for these embedded projects (dictated by clueless PHBs) is only "linux support" not "mainline kernel support", so SOC vendors (like TI) just don't have the incentive to develop SOC peripheral driver code suitable for mainline inclusion.
You don't have to be intelligent/reasonable to control intelligent/reasonable people, you just have to convince them that you are. You can go on being a clueless dipshit in all other respects.
Because if you aren't incompetent, you won't get yelled at.
Unlike a corporate structure, where you don't get yelled if you play the game right.
If you are incompetent, please don't develop linux kernel code. Go work for a corporation.You'll find you're a better fit, and if you play your cards right, you won't get yelled at no matter how bad you are at your job.
It's a shame that browsers have such freakouts over self signed certs, because there is really little difference between them and officially signed certs
Exactly. Especially since you can get a "real" cert from one of many, many, free cert signing services. What is the point?
FEC algorithms do not treat (an unknown number) of lost bits as a stream of 0 bits, since it can't know how many bits are lost.
FEC generally does not seek to recover lost data, only the proper state of flipped bits.
You mean Iain Banks.
If it was a bit more advanced I'd sign up in a heartbeat
Daniel Sterling received (and still receives) death threats. Does that mean he's right, and all of his critics are crazy?
So clearly the whole ideal of "the general public shouldn't have guns, only cops" doesn't make sense either.
Step 1) Have a constitutional convention to repeal the 2nd
Step 2) Let me keep my firearms for sporting purposes.
Step 3) ???
Step 4) PROFIT
I'm not Arker, and his analysis hides all kinds of issues, especially considering not every gun out there is a .22lr pistol.
Bottom line, Armatix doesn't want you carrying their firearms for self defense for a reason. Somehow I don't think cops would take kindly to you telling them they have to replace all of their carry weapons with .22lr
What about people killed with their own firearms, or stolen firearms? Sure there are a few hundred. Should their lives simply be disregarded?
Yes. If they are outliers, and the numbers of lives saved dwarfs the statistical relevance of your outliers.
"If we can save just one life" is not a good basis for sound public policy making when it disregards broader consequences.
"Disabling shots" are not used intentionally, and for a reason. Stating that they are "used frequently" is an outright fabrication.
You watch too many movies and/or play too many video games.
This is exactly the point. The things that drive violent crime are not caused by increased firearm ownership rates. To that extent, you an expect any efforts to reduce firearm ownership rates to have no effect on violent crime.
What are the odds that somebody is going to run up to you while you are target shooting or hunting, wrest your firearm from you, and shoot you with it?
Non-critical firearms are generally stored locked and unloaded when there is a concern that a child or unauthorized person might get a hold of it.
I'm not sure I follow. I am saying I dislike all legislation that makes firearms less reliable, including mag disconnects and poorly designed drop safeties.
I don't think most LCIs (unless very poorly designed) affect reliability, aside from the fact that they add more (pointless, IMO) complexity to the slide.
In any case, the problem with roster legislation is that while their stated purpose is "safety", they are invariably expanded to include any tech that can be added, such that it is becomes harder and harder to import new models into the state. A perfect example is CA's roster laws: even firearms that are identical (except cosmetically) to rostered models have to be re-submitted for testing *and* are required to adhear to all new rostering requirements, even though other identical models (albiet older) are already on the roster.
At no point are any new features ever subject to any scrutiny with regards to safety.... for example, microstamping. Is a firearm that does not have microstamping less safe than one that does?
Now you could argue that to you, it doesn't matter. All you care about is that there are less firearms being sold in CA. That is fine. That is your opinion. But you cannot claim the roster is about the "safety" of individual firearms, only that it is having the desired effect of slowing importation of firearms into the state.