*If* everyone picked exactly the same lib version, yes.
In practice, people aren't going to standardize on the same library version.
Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.
All pipelines in powershell are objects, and something will only become text if it has become serialised somewhere along the way (e.g., read/write from disk).
See output from 'netsh'. See use of 'write-output'. Maybe you call an array of strings meangingfully distinct from "text", but it really isn't. You can't use select-object, have to switch to select-string. Have to do an assignment and a get-member or gettype() to know what you are really in for.
Returning multiple objects from a query is a feature, not a bug.
My issue is not the plurality. My issue is that the singular will have a different set of behaviors as indicated by GetType than one. I would have either liked it if a single object was returned as a single element array, or if the language did a better job of implicit array creation if you treat such singular returns as an array.
And no, a cmd script can NOT turn code-signing off if you have UAC turned on
powershell set-executionpolicy bypass currentuser
If you have an enterprise CA, and an AD integrated subordinate, signing scripts is trivial. My workflow with writing powershell involves saving the file in notepad++, running "./add-signature foo.ps1" (add-signature is a 1-2 line script I've got which retrieves my code-signing cert and signs the argument with it) and then running the script. That's it.
First, that's hoops to jump through even assuming the infrastructure setup. Second, no convenient linux tools to generate the ASN.1 structures to sign in non-windows envs.
But, there are things you can do in Powershell in a few lines of code that you just can't do with a shell script without a massive time investment.
That's absolutely true of cmd and vbscript, less so in bash or perl or python on a linux system.
Much of the power of powershell lies in its ability to easily query and interact with WMI objects
WMI in my mind is less desirable than sysfs under linux which provides much the same data. WMI objects aren't very discoverable as they aren't unified under a single root. If you ask me about some data in wmi I have not previously worked with, it;s off to technet forums to search for the answer. In linux, a little ogling of sysfs and I can generally find it without so much as tabbing over to my browser.
not have to worry about people running malicious powershell scripts
Untrue, see above
If someone in the enterprise pushes a dodgy script (either accidentally, or maliciously), I can easily disable it from running, wherever the copies may exist by simply revoking the cert.
Ok, that's the one effective use case of the code signing as implemented today.
Want to actually search for something? The start screen makes more sense then the smallish non-resizable start menu window.
The size might make sense, but the behavior does not. In Win 7 desktops, I can generally type what I want to find and it will show up on the list. In Win 8, despite having more real estate they are more stingy with it. Search for 'update' and you get 'No apps match your search'. You have to ascertain that in fact you need to click over to a different category to see 'settings' results or 'file' results depending on what you are searching for.
The problem is that powershell is in an awkward place between languages like perl/python and shell scripting.
The pipe might be simply the string you see, or it might be a stream of objects that are being formatted, and that reality is generally not clear at a glance. In bourne shell, it's pretty much always what you see is what you get (for better or for worse). Once understood, this *usually* provides the programmer more power when they test to determine what the stream will look like, but it's still inconsintent as to whether provided cmdlets support pipeline input or not, causing very distinct calling conventions to mix and match cmdlets that require pipeline input and cmdlets that cannot comprehend pipeline input.
Many scenarios might present your code either a single object or a list depending on circumstance. Select-Object for example will return the result as one object not in an array if one matches, but will return an array if multiple matches. This means code that assumes one result will suddenly be faced with an array, and code that assumes it will see an array to iterate will break when faced with only one value.
Because they want the user to be able to be fast and loose with quoting, some odd behaviors creep in there. A string suddenly becomes an array because it had a , in it, and the user that had been typing things free form suddenly results in a vastly different argument being passed into your commandlet.
It's interesting you should mention the codesigning. It causes some headaches without a lot of meaningful protection (e.g. a.cmd script is allowed to run without consideration, and that.cmd can say 'powershell set-executionpolicy bypass' and then jump to ps1 file if it really wanted).
Process directives in functions are unable to effectively stop execution of the function. 'return' just iterates to next hop, and 'break' will escape all the way to the parent loop of function or exit the whole script if no loop.
Actually, we can *reproduce* sound 'good enough' but generating convincing sound from nothing is still beyond at least anything I know of. Speech synthesis, for example, is always obviously unnatural. We are still at a point where we have to assemble sounds from samples recorded or carefully engineered rather than spontaneously generated. Sure, we can do things like manipulate where the sound is being perceived as coming from, but we still require scripted voices and sound samples.
Video is more complicated so we can't cheat as much.
The problems are not what is possible with a tablet interface, the problems center around the dual personality awkwardly slapped together.
If you have a classic application, it's awkward to use in touch interaction.
If you do anything in metro, it's awkward to use without touch.
If you are running a Metro app, you cannot arbitrarily have it sized and present alongside arbitrarily many other apps.
If running a desktop app, it doesn't enumerate the same in win-tab (though alt-tab behaves differently) and the navigation schemes are just pretty fundamentally different.
As a developer, you have to pick from either a Metro app with very low (as-yet) market penetration *or* the desktop api that would support both the new and old editions of Windows.
Alt-tab and Win-Tab act significantly different from one another as well.
I can run netflix in browser and it works fine, but Windows 8 app fails to play on my laptop (an AMD driver issue around DRM, but speaks to the stark inconsistencies)
In short, it's not about what Microsoft enabled, it's about how poorly they executed in doing so. If MS had added the better interface tricks to the same, consistent API they offered before, perhaps this conversation would be different. Instead, they doubled down on Silverlight, renaming it as they went because Silverlight was a failure, creating a huge inconsistent mess between their 'Metro' strategy and the rest of the environment. When MS first rolled out.Net, they didn't make such a glaring mistake that affected the common end user, and they could have applied some of those sensibilties to Win8. As an example of doing it right, see how OSX added similarly competent treatment of full screen applications without requiring developers make a hard choice and without requiring users to jump between entirely distinct user experiences.
As the technology has matured, the inevitble is coming to pass, the laptop/desktop market is coming to a plateau. The tablet and phone markets will (or already have by some accounts) hit the same point. Some even say that the 'tablet' market other than iPad *started* in that fashion. Apple probably has the most durable strategy, inspiring their customer base to consider their devices a fashion statement as well as a tool (same way some auto makers can extract more volume and margin out of select models versus others)
While there of course are examples of people who use Tablets to displace their usage of computers, by far the vast majority have both depending on circumstance. Maybe they bother to bring their laptop out to lunch or the couch less, but at work and at home they are still pounding on a traditional PC system at least once a day.
I'm talking about kickstart/autoyast vs. unattend.xml.
In kickstart/autoyast/preseed, you can feed in the pre-crypted value. In windows, you must feed in the password. You don't have the option of, say, feeding in the NTLMv2 hash. Of course, NTLMv2 hash is far weaker than any of the modern crypt() strategies in a linux system.
In some environments, security is an issue. If it's network installable, then chances are they can get the kickstart/unattend/whatever file off the network. For most linux envs done right, the risk is disclosure of the/etc/shadow variant of the file severely mitigating the risk, but in Windows, you cannot use any sort of meaningful protection.
If you do it from stock media, policy may still prevent it from containing the media (e.g. high chance the technician won't take extra care and might lose media with sensitive data).
There are environments that automate everything else except the local administrator passwore. There are very few autoinstall mechanisms that meaningful protect the password across deployment (e.g. the Flex System Manager from IBM does it for the OSes it can deploy, and you can craft a Windows install scheme that has no usable local accounts and relies entirely upon active directory sacrificing the ability to administer it offline, but overwhelmingly the majority of automated OS deployments will leave passwords vulnerable if they are tasked with setting them.
"The liver is the only internal human organ capable of natural regeneration of lost tissue; as little as 25% of a liver can regenerate into a whole liver." Other organs can heal, the liver can actually grow back.
My point was that the GP was saying too much javascript is used such that disabling javascript is infeasible in scenarios where, really, javascript is superfluous.
His point was about web content being more dynamic than he thinks is required. A fair point, nowadays a straightforward web form with very limited scope is frowned upon if it neglects to do some sort of javascript trickery or another. He isn't after *more* capability, he seeks a more constrained experience and to have more developers exhibit a shred of restraint rather than mandate moderately more open ended access to the client facilities for superfluous bells and whistles. If a browser hangs up nowadays, it's almost certainly due to badly written javascript or javascript implementation gone insane in the face of valid javascript. Simplistic content doesn't choke up browsers and in a lot of cases, that simplicistic content model *could* suffice for the purpose. There are cases where javascript can enrich the experience beyond what is reasonable without it, but web developers immediately jump to the deep end without a second thought today.
Now, in terms of 'powerful and flexible', I'd argue that inherently it cannot hold that crown precisely because javascript is restricted from doing things like opening arbitrary filehandles and such. This isn't a bad thing, but it means the claim of 'most powerful' is flawed. Javascript is a popular language not due to having 'the' best set of capabilities or the best syntax (everyone bundles some sort of 'library' precisely to bandaid over javascripts failing at the low level), it's popular by virtue of being ubiquitous.
Has it been that long since you looked at IBM products? As of the Nehalem generation of servers, RSA no longer applies.
Guess my question would be what the perceived feature gap between HP and IBM on this front. It's probably no longer valid. That's not to say that there is good reason to run to IBM to the exclusion of HP, but probably not a strong reason to avoid IBM anymore.
They don't have a major refresh every year, years with refreshes appear to have crazy year to year growth followed by a year of apparent sharp decrease. One 'bad' year is not unexpected if preceded or succeeded by a certain event on their roadmap.
Huh? When did this happen? Or do you mean the hard drive business, which is very much not the same as their Shark stuff (and of course the Ramsan, the SVC, and XIV stuff they bought and the various netapp things they rebadge)
e.g. that's the way infiniband works. QoS and flow control are done by the switches, but routing decisions are left up to the subnet manager. It's really analagous to the concepts put fourth in SDN.
This is the aspect of it that astounds me. Cisco does a solid enough job and all, but in terms of manageability, they aren't untouchable. They are largely untouched by many of the competitors who fail to grasp why Cisco is so entrenched, but if they had a hint of vision and understanding, they'd be comparable to Cisco in short order. True, Cisco has a lot of momentum, but deliver comparable manageability at an attractive price, and Cisco's special hold will dilute more easily than many would guess. Particularly since Cisco hasn't been very competitive performance wise and especially not price performance wise in a long while (they don't need to be and to get that position would require investment they don't feel the need to make)
It is kind of problematic to add it to a detachable control plane. The flow controllers can only be divorced from the 'data plane' only because there is a modest amount of traffic to set up the fairly 'dumb' flows. If the flow controller had to get enough data to competently do QoS, it would be a scalability nightmare for a large fabric. For a small fabric, doable, but at that point the flow controller concept kind of loses a lot of the promise of value. I suppose you can add nearly one flow controller per switching device, but you get nearly back where you started. There is some remaining value in the flexibility of the system, but that could have been achieved through more open firmware without the distinction being created between data and control plane.
It's about UI design. For the same reasons that metro is frustrating on a desktop, so too would Android or IOS as they are currently designed today. The multitasking paradigm in the mobile phones is tolerated, but most everyone sees the downsides of implicit app management causing an app to 'close' when you really thought of it as a task switch. The ability to reconstruct state from stored data on switch away perfectly varies app to app from perfect to not implemented at all.
If you want to see how an industry keeps people on an upgrade treadmill, look no further than the cell phone market.
Once upon a time, the subsidy scheme was required to get people to play in the market given the genuinely high cost of the devices. Nowadays, 'unlocked' prices are hyper-inflated to lend a sense of legitimacy to carrier subsidies. Every two years, the average consumer might as well buy a new phone because it's 'just such a deal that would go to waste' even if their last device still works fine for their needs.
It's the same way so many people buy cars so frequently that they always have car payments. They get accustomed to the payment and suddenly *not* having a car payment is 'weird' and means they better get a new car.
Meanwhile, consumer PCs never really embraced some scheme to get people to have some low, forgettable monthly payment (cloud computing being an exception). They see the expense in a straightforward manner and thus don't feel the same compulsion to upgrade. Therefore, the bulk of the market goes to buying a new one when it breaks.
The dollar used to be a receipt for a certain amount of gold that you owned in the federal reserve
And gold is only valuable because someone says it is. In a societal collapse, abount the only currency would be ammo, food, shelter, and medicine. "Just a piece of paper" isn't appreciably different than "just a chunk of gold" in that regard.
I think the single biggest failing is that it uses centralized CAs which means expensive certs, which means people don't use the encryption except for specialized uses.
The RFC is heavily worded around organizational management of keys. In that context, you aren't using Verisign or Thawte (and ideally you wouldn't even trust external CAs though certain frameworks like Microsoft's make that a challenging proposition), you are using one specific to your organization.
Given the fact that this document is a 'best practices' sort of thing rather than actually defining some sort of protocol, I find the venue of an RFC (even TFS incorrectly marks this sort of thing as a 'standard) questionable.
If they were looking for a techncial solution to actually enforce some of what is prescribed, basically it's describing the precise sorts of things x509 has baked in. Expiration rules to force examination of things like need-to know or even continued employment. Keys having to be blessed by an organizational authority rather than empowering each indivdiual user. Certificate revocation.
Basically, ssh *should* have embraced x509 as a PKI standard. The biggest failing of x509 is the CA system lacking a facility to limit scope of particular CAs leading to implementations shipping with a default set of free-for-all CA certificates. So long as ssh infrastructure doesn't pre-ship with any CA certs until the target organization adds one, that one flaw is mitigated severely.
Slashdot Mirror
*If* everyone picked exactly the same lib version, yes.
In practice, people aren't going to standardize on the same library version.
Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.
All pipelines in powershell are objects, and something will only become text if it has become serialised somewhere along the way (e.g., read/write from disk).
See output from 'netsh'. See use of 'write-output'. Maybe you call an array of strings meangingfully distinct from "text", but it really isn't. You can't use select-object, have to switch to select-string. Have to do an assignment and a get-member or gettype() to know what you are really in for.
Returning multiple objects from a query is a feature, not a bug.
My issue is not the plurality. My issue is that the singular will have a different set of behaviors as indicated by GetType than one. I would have either liked it if a single object was returned as a single element array, or if the language did a better job of implicit array creation if you treat such singular returns as an array.
And no, a cmd script can NOT turn code-signing off if you have UAC turned on
powershell set-executionpolicy bypass currentuser
If you have an enterprise CA, and an AD integrated subordinate, signing scripts is trivial. My workflow with writing powershell involves saving the file in notepad++, running "./add-signature foo.ps1" (add-signature is a 1-2 line script I've got which retrieves my code-signing cert and signs the argument with it) and then running the script. That's it.
First, that's hoops to jump through even assuming the infrastructure setup. Second, no convenient linux tools to generate the ASN.1 structures to sign in non-windows envs.
But, there are things you can do in Powershell in a few lines of code that you just can't do with a shell script without a massive time investment.
That's absolutely true of cmd and vbscript, less so in bash or perl or python on a linux system.
Much of the power of powershell lies in its ability to easily query and interact with WMI objects
WMI in my mind is less desirable than sysfs under linux which provides much the same data. WMI objects aren't very discoverable as they aren't unified under a single root. If you ask me about some data in wmi I have not previously worked with, it;s off to technet forums to search for the answer. In linux, a little ogling of sysfs and I can generally find it without so much as tabbing over to my browser.
not have to worry about people running malicious powershell scripts
Untrue, see above
If someone in the enterprise pushes a dodgy script (either accidentally, or maliciously), I can easily disable it from running, wherever the copies may exist by simply revoking the cert.
Ok, that's the one effective use case of the code signing as implemented today.
Want to actually search for something? The start screen makes more sense then the smallish non-resizable start menu window.
The size might make sense, but the behavior does not. In Win 7 desktops, I can generally type what I want to find and it will show up on the list. In Win 8, despite having more real estate they are more stingy with it. Search for 'update' and you get 'No apps match your search'. You have to ascertain that in fact you need to click over to a different category to see 'settings' results or 'file' results depending on what you are searching for.
The problem is that powershell is in an awkward place between languages like perl/python and shell scripting.
The pipe might be simply the string you see, or it might be a stream of objects that are being formatted, and that reality is generally not clear at a glance. In bourne shell, it's pretty much always what you see is what you get (for better or for worse). Once understood, this *usually* provides the programmer more power when they test to determine what the stream will look like, but it's still inconsintent as to whether provided cmdlets support pipeline input or not, causing very distinct calling conventions to mix and match cmdlets that require pipeline input and cmdlets that cannot comprehend pipeline input.
Many scenarios might present your code either a single object or a list depending on circumstance. Select-Object for example will return the result as one object not in an array if one matches, but will return an array if multiple matches. This means code that assumes one result will suddenly be faced with an array, and code that assumes it will see an array to iterate will break when faced with only one value.
Because they want the user to be able to be fast and loose with quoting, some odd behaviors creep in there. A string suddenly becomes an array because it had a , in it, and the user that had been typing things free form suddenly results in a vastly different argument being passed into your commandlet.
It's interesting you should mention the codesigning. It causes some headaches without a lot of meaningful protection (e.g. a .cmd script is allowed to run without consideration, and that .cmd can say 'powershell set-executionpolicy bypass' and then jump to ps1 file if it really wanted).
Process directives in functions are unable to effectively stop execution of the function. 'return' just iterates to next hop, and 'break' will escape all the way to the parent loop of function or exit the whole script if no loop.
There's all sorts of weirdness in powershell.
We already have perfect sound simulation
Actually, we can *reproduce* sound 'good enough' but generating convincing sound from nothing is still beyond at least anything I know of. Speech synthesis, for example, is always obviously unnatural. We are still at a point where we have to assemble sounds from samples recorded or carefully engineered rather than spontaneously generated. Sure, we can do things like manipulate where the sound is being perceived as coming from, but we still require scripted voices and sound samples.
Video is more complicated so we can't cheat as much.
The problems are not what is possible with a tablet interface, the problems center around the dual personality awkwardly slapped together.
If you have a classic application, it's awkward to use in touch interaction.
If you do anything in metro, it's awkward to use without touch.
If you are running a Metro app, you cannot arbitrarily have it sized and present alongside arbitrarily many other apps.
If running a desktop app, it doesn't enumerate the same in win-tab (though alt-tab behaves differently) and the navigation schemes are just pretty fundamentally different.
As a developer, you have to pick from either a Metro app with very low (as-yet) market penetration *or* the desktop api that would support both the new and old editions of Windows.
Alt-tab and Win-Tab act significantly different from one another as well.
I can run netflix in browser and it works fine, but Windows 8 app fails to play on my laptop (an AMD driver issue around DRM, but speaks to the stark inconsistencies)
In short, it's not about what Microsoft enabled, it's about how poorly they executed in doing so. If MS had added the better interface tricks to the same, consistent API they offered before, perhaps this conversation would be different. Instead, they doubled down on Silverlight, renaming it as they went because Silverlight was a failure, creating a huge inconsistent mess between their 'Metro' strategy and the rest of the environment. When MS first rolled out .Net, they didn't make such a glaring mistake that affected the common end user, and they could have applied some of those sensibilties to Win8. As an example of doing it right, see how OSX added similarly competent treatment of full screen applications without requiring developers make a hard choice and without requiring users to jump between entirely distinct user experiences.
As the technology has matured, the inevitble is coming to pass, the laptop/desktop market is coming to a plateau. The tablet and phone markets will (or already have by some accounts) hit the same point. Some even say that the 'tablet' market other than iPad *started* in that fashion. Apple probably has the most durable strategy, inspiring their customer base to consider their devices a fashion statement as well as a tool (same way some auto makers can extract more volume and margin out of select models versus others)
While there of course are examples of people who use Tablets to displace their usage of computers, by far the vast majority have both depending on circumstance. Maybe they bother to bring their laptop out to lunch or the couch less, but at work and at home they are still pounding on a traditional PC system at least once a day.
I'm talking about kickstart/autoyast vs. unattend.xml.
In kickstart/autoyast/preseed, you can feed in the pre-crypted value. In windows, you must feed in the password. You don't have the option of, say, feeding in the NTLMv2 hash. Of course, NTLMv2 hash is far weaker than any of the modern crypt() strategies in a linux system.
In some environments, security is an issue. If it's network installable, then chances are they can get the kickstart/unattend/whatever file off the network. For most linux envs done right, the risk is disclosure of the /etc/shadow variant of the file severely mitigating the risk, but in Windows, you cannot use any sort of meaningful protection.
If you do it from stock media, policy may still prevent it from containing the media (e.g. high chance the technician won't take extra care and might lose media with sensitive data).
There are environments that automate everything else except the local administrator passwore. There are very few autoinstall mechanisms that meaningful protect the password across deployment (e.g. the Flex System Manager from IBM does it for the OSes it can deploy, and you can craft a Windows install scheme that has no usable local accounts and relies entirely upon active directory sacrificing the ability to administer it offline, but overwhelmingly the majority of automated OS deployments will leave passwords vulnerable if they are tasked with setting them.
"The liver is the only internal human organ capable of natural regeneration of lost tissue; as little as 25% of a liver can regenerate into a whole liver." Other organs can heal, the liver can actually grow back.
All my shows grabbed using SickBeard on a server.
And the networks don't care one bit about your opinion as you provide them no revenue opportunity.
The liver is one of the more resiliant organs (the only one that can regenerate). It's probably the easiest organ to start with.
My point was that the GP was saying too much javascript is used such that disabling javascript is infeasible in scenarios where, really, javascript is superfluous.
His point was about web content being more dynamic than he thinks is required. A fair point, nowadays a straightforward web form with very limited scope is frowned upon if it neglects to do some sort of javascript trickery or another. He isn't after *more* capability, he seeks a more constrained experience and to have more developers exhibit a shred of restraint rather than mandate moderately more open ended access to the client facilities for superfluous bells and whistles. If a browser hangs up nowadays, it's almost certainly due to badly written javascript or javascript implementation gone insane in the face of valid javascript. Simplistic content doesn't choke up browsers and in a lot of cases, that simplicistic content model *could* suffice for the purpose. There are cases where javascript can enrich the experience beyond what is reasonable without it, but web developers immediately jump to the deep end without a second thought today.
Now, in terms of 'powerful and flexible', I'd argue that inherently it cannot hold that crown precisely because javascript is restricted from doing things like opening arbitrary filehandles and such. This isn't a bad thing, but it means the claim of 'most powerful' is flawed. Javascript is a popular language not due to having 'the' best set of capabilities or the best syntax (everyone bundles some sort of 'library' precisely to bandaid over javascripts failing at the low level), it's popular by virtue of being ubiquitous.
IBM RSA
Has it been that long since you looked at IBM products? As of the Nehalem generation of servers, RSA no longer applies.
Guess my question would be what the perceived feature gap between HP and IBM on this front. It's probably no longer valid. That's not to say that there is good reason to run to IBM to the exclusion of HP, but probably not a strong reason to avoid IBM anymore.
They don't have a major refresh every year, years with refreshes appear to have crazy year to year growth followed by a year of apparent sharp decrease. One 'bad' year is not unexpected if preceded or succeeded by a certain event on their roadmap.
Huh? When did this happen? Or do you mean the hard drive business, which is very much not the same as their Shark stuff (and of course the Ramsan, the SVC, and XIV stuff they bought and the various netapp things they rebadge)
e.g. that's the way infiniband works. QoS and flow control are done by the switches, but routing decisions are left up to the subnet manager. It's really analagous to the concepts put fourth in SDN.
break the Cisco strangle-hold
This is the aspect of it that astounds me. Cisco does a solid enough job and all, but in terms of manageability, they aren't untouchable. They are largely untouched by many of the competitors who fail to grasp why Cisco is so entrenched, but if they had a hint of vision and understanding, they'd be comparable to Cisco in short order. True, Cisco has a lot of momentum, but deliver comparable manageability at an attractive price, and Cisco's special hold will dilute more easily than many would guess. Particularly since Cisco hasn't been very competitive performance wise and especially not price performance wise in a long while (they don't need to be and to get that position would require investment they don't feel the need to make)
It is kind of problematic to add it to a detachable control plane. The flow controllers can only be divorced from the 'data plane' only because there is a modest amount of traffic to set up the fairly 'dumb' flows. If the flow controller had to get enough data to competently do QoS, it would be a scalability nightmare for a large fabric. For a small fabric, doable, but at that point the flow controller concept kind of loses a lot of the promise of value. I suppose you can add nearly one flow controller per switching device, but you get nearly back where you started. There is some remaining value in the flexibility of the system, but that could have been achieved through more open firmware without the distinction being created between data and control plane.
It's about UI design. For the same reasons that metro is frustrating on a desktop, so too would Android or IOS as they are currently designed today. The multitasking paradigm in the mobile phones is tolerated, but most everyone sees the downsides of implicit app management causing an app to 'close' when you really thought of it as a task switch. The ability to reconstruct state from stored data on switch away perfectly varies app to app from perfect to not implemented at all.
If you want to see how an industry keeps people on an upgrade treadmill, look no further than the cell phone market.
Once upon a time, the subsidy scheme was required to get people to play in the market given the genuinely high cost of the devices. Nowadays, 'unlocked' prices are hyper-inflated to lend a sense of legitimacy to carrier subsidies. Every two years, the average consumer might as well buy a new phone because it's 'just such a deal that would go to waste' even if their last device still works fine for their needs.
It's the same way so many people buy cars so frequently that they always have car payments. They get accustomed to the payment and suddenly *not* having a car payment is 'weird' and means they better get a new car.
Meanwhile, consumer PCs never really embraced some scheme to get people to have some low, forgettable monthly payment (cloud computing being an exception). They see the expense in a straightforward manner and thus don't feel the same compulsion to upgrade. Therefore, the bulk of the market goes to buying a new one when it breaks.
The dollar used to be a receipt for a certain amount of gold that you owned in the federal reserve
And gold is only valuable because someone says it is. In a societal collapse, abount the only currency would be ammo, food, shelter, and medicine. "Just a piece of paper" isn't appreciably different than "just a chunk of gold" in that regard.
I think the single biggest failing is that it uses centralized CAs which means expensive certs, which means people don't use the encryption except for specialized uses.
The RFC is heavily worded around organizational management of keys. In that context, you aren't using Verisign or Thawte (and ideally you wouldn't even trust external CAs though certain frameworks like Microsoft's make that a challenging proposition), you are using one specific to your organization.
Given the fact that this document is a 'best practices' sort of thing rather than actually defining some sort of protocol, I find the venue of an RFC (even TFS incorrectly marks this sort of thing as a 'standard) questionable.
If they were looking for a techncial solution to actually enforce some of what is prescribed, basically it's describing the precise sorts of things x509 has baked in. Expiration rules to force examination of things like need-to know or even continued employment. Keys having to be blessed by an organizational authority rather than empowering each indivdiual user. Certificate revocation.
Basically, ssh *should* have embraced x509 as a PKI standard. The biggest failing of x509 is the CA system lacking a facility to limit scope of particular CAs leading to implementations shipping with a default set of free-for-all CA certificates. So long as ssh infrastructure doesn't pre-ship with any CA certs until the target organization adds one, that one flaw is mitigated severely.