Based on this recent case I'd say the answer is yes.

Encrypted data cannot be effectively compressed. Storage device-level compression's big shortcoming is that it's fundamentally incompatible with encryption (except for storage device-level encryption). In other words, to get any benefit from compression you have to make sure that whatever you're sending to the storage device is UNencrypted. Do you really want to shut off all or most higher level encryption? To disable dm-crypt/LUKS2, FileVault, BitLocker, and PGP, as examples?

If you want to see where computing's future lies (sometimes far future), then it's often helpful to look at today's mainframes. Mainframes are now compressing and encrypting (and decrypting and uncompressing) everything, often more than once ("multi-layered" encryption), "at rest" and "in flight," using specialized compression and encryption accelerators directly on their main CPU cores backed with uniquely strong Hardware Security Modules (HSMs) to protect keys, and with full software support up and down the stack that avoids burdening application programmers with all the responsibility. Mainframe storage devices then only ever deal with storing and retrieving encrypted data -- or at least that's what they're designed to do if implemented per "best practices." (IBM calls this "Pervasive Encryption.")

This sort of arrangement is really the only way to compress/encrypt (and decrypt/uncompress) if you care about security at all. If encryption is solely or predominantly the province of a storage device, then there are all sorts of inherent security risks.

They're at ~99.5% service availability for all of 2018 if they're at the 45 hour outage mark and come back into full service right away. That's a lot, lot worse than Citibank and the Visa network, as examples. Anyone want to place odds on that number falling to ~3.5% for the year?

Maybe. Cars have never been better, so "more like a car" is quite appealing, actually. I know I don't want my smartphone (or the other airline passenger's smartphone) to behave like a Samsung Galaxy Note 7. It shouldn't electrocute anybody, it should be secure (and not only when the manufacturer first shipped it), and it should fully honor my privacy requirements. It should be repairable and not more fragile than a snowflake in Bangkok. I should be able to use it to summon an ambulance or police officer reliably, with my correct location, and even if I don't have the correct SIM and only have a weak signal on another carrier's tower (or a Wi-Fi connection). It should support truly important public safety alerting, such as "tornado approaching." It should not jam the signals of the whole neighborhood's baby monitors. If I ever get a hearing aid, I ought to still be able to hear the other caller.

In short, yes, there is some appropriate role for government regulation of smartphones.

1. Naively capping H-1Bs at 1,000 per organization would only result in more organizations. The outsourcers would simply lean on shell companies. Depending on the elasticities, workers would get paid even less in order to fund the extra overhead. That won't work.

2. There is an easy fix, actually: set minimum H-1B salaries to $10,000 per month (2017 dollars, inflation indexed) nationwide, up to $2,000/month more (2017 dollars) in high cost of living areas (e.g. Silicon Valley), plus require that the employer post a 12 month bond. That'll have zero impact on Apple and several other legitimate H-1B employers. Closely monitor compliance (e.g. compare to tax records), deport any employee paying kickbacks, throw anybody accepting kickbacks in prison, and keep the bond if there are any rule violations.

3. A variation on #2 is to hold monthly or quarterly H-1B auctions. The bid price is the employee's salary, and the highest salaries win, subject to a $10,000/month (2017 dollars) floor.

Options #2 and #3 would help boost government revenues since high salaries (for both the H-1Bs and resident workers) mean higher tax payments.

Singapore sets strict quotas on total vehicles, by type, using a simple auction system. So let's suppose the quota is capped at one million vehicles of all types. Private cars might represent 600,000 of that total. (These numbers are approximately correct for Singapore.) If you want to buy a car, you have to get a Certificate of Entitlement (CoE), good for 10 years. As a car comes off the road and is scrapped or exported, its CoE is returned to the public pool and auctioned. The highest bidders win. Currently (mid 2017) a CoE is fetching about US$35,000. That's not the car or anything that goes with it. It's merely the cost of a 10 year license to place a new car on the road. You also have to buy, register (with ample tax), insure, park, and fuel the car, and that costs money, too. You also must have an electronic toll device, and congested areas (primarily the central business district) have variable tolls to enter. If you get out of line the penalties are severe, and you cannot bribe your way out of such problems.

Do those basic things (a strict overall cap on the vehicle population at an appropriate level, and variable electronic tolling for the areas most prone to congestion), and you have eliminated traffic problems. Public buses can then run on reliable schedules, road construction doesn't cause too much agony, and there's an excellent revenue source for both.

This problem is well solved if people want it solved. Just copy Singapore.

Yes, z/OS.

If you don't trust an identified host to execute your transaction how does blockchain magically make that better?

Tanktalus provided one example upthread, what you might call "trusted competition" (or "competitive trust"). More generally, "trust" in the real world has many complexities, many shades of gray, and they are are not static. You might trust Ben Carson (or at least a younger one) to perform complex neurosurgery on your infant, but you might not trust him to run HUD. (Ben Carson didn't trust Ben Carson to run HUD. Oops.) As another analogy, during the Cold War the United States and the Soviet Union trusted each other in certain ways, not in others. In particular, they trusted each other to blow each other up if sufficiently provoked ("Mutual Assured Destruction").

You could easily make the same basic argument about Bitcoin, and I might even join you in making that argument -- that the world is full of currencies (including many better currencies in terms of what currencies are supposed to do), and there are many other ways to create and to operate a currency than to use Blockchain algorithms (and to consume the equivalent of Holland's entire electricity demand in the process, last I checked). I remember the early commercial Internet when lavishly funded startups like Pets.com could advertise on the Superbowl but made absolutely no business sense. Blockchain is going to have its share of dubious applications and hucksters. Bridge well crossed, actually. Blockchain's first use case (Bitcoin) might be extra dubious. That said, I'm not brave enough to predict that Blockchain algorithms have no reasonable use cases that are "best fits" for the technology, especially if parties who understand business and government at least fairly well are working together. No matter. We'll find out soon enough, probably within the next year or so.

By that I mean, Intel, coke, att etc each get only one vote's worth of trust each, same as Linus, stallman, BoA and any registered, trusted developers.

Because that's not what certain industries (or regulators) want, but they have many, many use cases where Blockchain fabrics are useful. The Linux Foundation's Hyperledger fabric (and open source code) certainly isn't opposed to "flat" consensus models -- you can do that! But telling the semiconductor industry, or the beverage industry, or some other group that they must adopt one specific consensus model slams hard into reality very quickly. Choice is good, even democratic. ;)

Hyperledger provides something called Byzantine Fault Tolerance using the PBFT protocol as a supplied consensus algorithm. It's a great choice for many use cases, in part because it's well proven over many years, with mathematical proof. So you've got something solid to work with, out of the box. But the consensus algorithm is pluggable, and there are Hyperledger users plugging away. Pluggable consensus is critically important for openness and flexibility.

IBM started offering Blockchain as a Service some months before Microsoft did. This particular announcement is significant because IBM is apparently the first to offer Linux Foundation Hyperledger 1.0 Blockchain as a Service, and in the industry unique ultra high security form, too.

Devrtm (the original poster) can donate his/her Bitcoin to any IRS 501(c)(3) tax exempt charity(ies) that accept(s) Bitcoin, for example the Electronic Frontier Foundation. Devrtm can then enjoy a U.S. personal income tax deduction for the full, fair market value of his/her donation, with no capital gains tax owed. It may be possible to make the donation anonymously, but Devrtm must keep records of the donation in his/her personal files, to document the tax deduction in case there is a future IRS inquiry. The tax deduction will likely be worth substantially more than what Devrtm paid (if anything) to obtain the Bitcoin. If Devrtm is subject to state or local income tax then there may also be charitable deductions allowed in those tax returns.

Once you spend even a few minutes trying to understand how financial and other industries operate (and want to operate in the future), you quickly realize that one size does not fit all. There are a few Blockchain use cases when it makes sense (if you can meet the scalability requirements) to have an open network, to distribute every transaction record (in whole form) to every node, and to have a "flat" consensus mechanism, with every node getting one equal vote. An awful lot of real world use cases don't fit that particular formula -- maybe most of them. Yet Blockchain, as a solution approach, still makes a great deal of sense if you can relax those artificial restrictions. That's exactly what the Hyperledger/Linux Foundation community has done. The Hyperledger 1.0 network can be permissioned, can avoid distributing every record (contents) to every node (but still maintains the chain itself), and offers pluggable consensus mechanisms. And you don't have to consume the equivalent of Holland's total electricity production, and climbing, to make it work -- far from it. That's flexible, and that's significant progress. It's also open source.

That's the real answer. First of all, IBM ranks right at the top in terms of number of patents granted, and it has for a couple decades running. With all those patents, of course they'll vary in quality and significance. Second, IBM is the first to admit that its patent strategy is primarily defensive -- to grab the patents (or to make disclosures to establish prior art, which it also does a lot) before a patent troll, or a fading technology company turning into a future patent troll, does. IBM makes surprisingly little money on patent licensing, especially given the size and significance of its patent portfolio.

Just as one example, the primary reason Linux wasn't strangled in its crib is because IBM effectively extended its IP shield over it. We know that history, because most of it is public now. IBM profited (and profits) to some extent from Linux's success, but that's single digit percentage stuff. Something approaching 99% of the financial benefits accruing from Linux go to everybody else in the industry. IBM is fine with that, since it's still a winning profit equation for them.

With a malfunctioning patent system, I'm OK with IBM -- and other players that behave like IBM -- grabbing the patents. If their business models are to secure patents for defense -- and to stick to those business models -- that's OK with me. But I still want the patent system to be fixed.

Washington State has a sales tax. If an individual cannot enter the United States, that individual buy a pair of sneakers in Washington State, and the state is nearly instantaneously deprived of sales tax revenue. Retailers in Washington must file sales tax returns, and pay sales tax, as frequently as once per month. The State of Washington has already lost some sales tax revenue from the end of January, 2017, that would be owed in about 10 days (mid-February, 2017).

Washington's Solicitor General made a 100% factually correct argument about one aspect of the harm to the State, and the judge agreed.

That's not a great argument. Companies, big or small, that ship security defective products, and that do not repair security defects in timely and convenient fashion, probably shouldn't be making Internet connected products at all. If your company ships crap, and if your crap stays crappy, causing material external harm to others, why should your company expect government acquiescence in your crappiness? You shouldn't.

Besides, it's not a "big" versus "small" issue, not in this instance. There are some excellent, security savvy companies that happen to be small, and there are some truly awful ones that happen to be big. What would be helpful to small businesses, if there is new regulation (probably), is for the industry to get ahead of that regulation and to promote a common, industry wide approach so that the U.S., E.U., and other regulatory "zones" are as uniform as possible. Frankly I'm surprised regulators have had as much patience as they've had. That patience won't last.