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.
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.
Civil or criminal solutions are intrinsically Local, with varying measures of corruption involved.
No, I disagree. Governmental authorities are not equal, and that's helpful in this potential area of regulation.
If the United States and European Union were to introduce common IT security fitness requirements then they would likely be more than enough to form a "critical mass." A fairly straightforward legislative remedy, at least conceptually, would be to require Internet connected device and software vendors to provide complementary, opt-out, timely security updates for a minimum of X years after product withdrawal from sale (where X varies by product category, never less than 5) or, if failing in their obligations, to be barred from selling any new devices and to owe per device per month financial penalties to a consumer restitution fund. The penalty amount would be based on the product's market price but also subject to an inflation-adjusted minimum. Vendors might also be required to post performance bonds before first sale so that these security obligations (and restitution) survive their corporate demise. Then, even if Uganda, for example, does not enact the same legislation (or does not enact "proxy" legislation which simply says "the product can only be sold in Uganda if also legally offered for sale in the U.S. or E.U."), the combined might of the world's two largest economies would be enough to establish a global standard in vendor security maintenance practices.
Government product fitness regulation could work quite well in this instance.
Repeating something often enough doesn't make it true.
Rather the point! The fact is that the Java programming language and runtimes, today, utterly dominate Blu-ray disc players, Android smartwatches, and Android smartphones, to pick some examples. (And what examples they are!) They're powerful evidence that Java hardware and software efficiencies have improved tremendously over two decades. Java is a raging market success, including on devices that cannot afford much inefficiency. It's reasonable and rational to mark-to-market dated views of Java's hardware and software performance attributes. The successful, high efficiency use cases are staring us in the face, literally.
Of course it is still quite possible (a) to write lousy code that the toolchain and runtime, for any language, cannot performance-fix sufficiently for your intended use cases; (b) to have certain scenarios where Java and its toolchain/runtime (for a particular implementation at a particular moment in time) do not produce the very highest efficiency/performance result technically achievable. Point (a) is always true (although a richer and deeper toolchain, and associated skills, can help a lot), and point (b) simply means that you toss efficiency/performance into your calculus with the relative importance it merits for your particular needs. There are other programming languages (and associated runtimes) available, including five durable ones: COBOL, FORTRAN, C, C++, and PL/I. Plus myriad not-yet-durable (and most never will be) options. (Pascal, Ada, ALGOL.... IT history is littered with them.)
If Java is so great... why Mozilla and almost any sane browser ask us to not run anything based on it and block the plug-in?
Because the browser plug-in security model was/is fundamentally broken. Browser vendors are discontinuing that plug-in model for every plug-in. If you want to continue running PC client side Java applications then you'll be moving to something called Java Web Start. JWS is a different, more secure way to launch those applications. Meanwhile, the Web sites you visit are often running lots of Java code to generate the content your Web browser displays. And if you're browsing the Web from an Android device (far more numerous than PCs) then most of the apps you run are written in Java. There's more Java than ever, but the ways and places Java runs are changing and multiplying.
There is a need for a light weight, garbage collected language with static typing an efficient compilation, but it does not exist. So Java it is.
Exactly. However, Java is pretty damn lightweight and efficient nowadays -- a heck of a lot less heavy than many alternatives. Partly that's because hardware improved, but mostly it's because several Java implementations have improved tremendously over the circa two decades and counting of Java's history. So, for example, Java is a mandatory part of the Blu-ray standards on ~$50 video players. And Google's Android Runtime (ART), another implementation of Java technology, is the world's most popular smartphone platform. On the server side there are extremely fast starting, lightweight, lower memory runtimes such as IBM's WebSphere Liberty Profile. The traditional efficiency rap against Java doesn't apply any more. "Back in the day" people complained about COBOL because it was "too slow" compared to that (allegedly) hand tuned Assembler code they weren't actually writing. Well, for several years, they had a point. By about the 1970s they didn't. Hardware improved, and the compilers got a lot better -- and that process continues, also for COBOL. Java used to be slow, sure...but what's that in your hand and on your wrist now? (And color TV used to suck, and car tires used to blow out at the first pothole....)
Another huge point in Java's (and for that matter COBOL's) favor is that it's a durable programming language. The invested value in Java code, and the ability to draw from that code portfolio to solve problems, is utterly massive. It's so massive that the Java programming language has crossed over into IT immortality along with only a very few other programming languages (FORTRAN, C, C++, and probably PL/I). Also, Java is the most demonstrably portable programming language (and compilation/runtime path) we have. (Any other nominees?) It's not at all hard to write functionally portable Java code that'll run, unmodified, on platforms ranging from Android smartwatches to z/OS mainframes. That's the default, and it really does work. High quality, performance-optimized and/or battery-optimized code is always a separate question. Any programmer can write lousy code in efficiency terms, and most do at least for Version 1.
"Sort of." Java 8 added unsigned integer arithmetic methods to Integer. Examples: compareUnsigned, divideUnsigned, parseUnsignedInt, remainderUnsigned, toUnsignedLong, etc. You still use long and int, and they still have the capability to store signed values. However, if you want, you only use them for unsigned values and with the Unsigned methods.
I don't think it's a "glaring omission." Life is quite difficult without signed integers -- you've really got to have those. Signed integers (of sufficient width) can functionally do everything unsigned integers can do. (What *functionality* are you missing?) If you have both signed and unsigned integers then you've got to have facilities for typecasting, and that has proven to be at least complicated enough. I think the reason unsigned integer data types were created in other languages has much more to do with the "every bit is precious" constraints in the formative years of those languages and their ancestors. They didn't want to "spend" a precious bit on a sign for every integer, hence the unsigned integer data type. Well, the 1990s (and even 1980s) came calling, with 32-bit and 64-bit addressable memory, and we don't have to be quite so bit thrifty. Every integer can have its sign, even if we never need it.
Signed strings and characters in Java were probably a mistake, though.
Bearing in mind that public funds are involved here, I'm struggling to understand why improving radio communications using "plasma bomb" satellites is such a great idea when satellites already do such a great job improving radio communications. In other words, we have vast numbers of artificial ionosphere "bouncers" already orbiting our planet, and we can also have high altitude tethered balloons and long duration airborne aircraft (perhaps solar electric) that the likes of Google and Facebook are working on -- and with much less investment than even one copy of the some of the aircraft the U.S. Air Force flies. We already know how to bounce radio signals all around the globe, and it's already cheap, reliable, and secure. So what's the "value add" here that merits substantial public investment? Anybody have any ideas?
One further point. I'm implicitly assuming long-term capital gains tax rates, and that's a reasonable assumption when oversimplifying slightly. For the record, short-term holdings (assets held less than one year) can get taxed at ordinary income tax rates. The top marginal U.S. income tax rate is currently 43.4% inclusive of the Net Investment Income Tax (NIIT) if it applies. However, short-term holdings presumably haven't gained as much value as long-term holdings, especially in the aggregate, unless you've been particularly lucky. And there's a simple solution for that, too: wait until the short-term holdings become long-term holdings (held for one year), then expatriate.
These are not exactly middle class problems, are they?;) You've got to be solidly within the top 5% on a wealth basis to get to an Expatriation Tax calculation, never mind actually owing any Expatriation Tax. And then, if you do pay some, you're resetting your cost basis anyway. You're just paying Uncle Sam what you would have paid when you sold the assets, less a blanket exemption. That's quite fair when checking out permanently, just as you must settle your hotel bill and minibar tab when you check out of a hotel.
You've provided reasonable links, but you simply haven't read that information correctly. Here's how the U.S. Expatriation Tax actually works (assuming your net worth exceeds $2 million or that you otherwise are subject to the Expatriation Tax), oversimplifying only slightly:
1. Take your total worldwide net worth at fair market value as if all your assets were sold the day before your expatriation date.
2. Subtract your total worldwide cost basis from your net worth. The result is your total gain from your mark-to-market "deemed sale."
3. Subtract $690,000 (tax year 2015, adjusted annually for inflation) from your total gain. The result is your total taxable gain. If your total taxable gain is zero or negative, stop: you do not owe any Expatriation Tax.
4. Otherwise, pay ordinary capital gains tax rates on your total taxable gain, with a current top marginal tax rate of 23.8% (if the NIIT applies, and I'm not sure it does, but let's assume that). This is your total U.S. Expatriation Tax.
If you owe Expatriation Tax your cost basis is reset. Any subsequent capital gains on U.S. assets will only be taxed based on your new, reset cost basis. Note that "wash sale" rules do not apply when making the Expatriation Tax calculation, so deemed sale capital losses are not limited within the calculation. To some degree you can pay your Expatriation Tax in installments if you wish and only pay statutory interest on deferred payments (currently 3%). If your assets are generating a higher after-tax rate of return (quite likely) then stretching out your Expatriation Tax payment to the maximum extent allowed by law is a good idea. You may also wish to stretch out your Expatriation Tax payments if you prefer to raise funds more slowly, perhaps as in the form of interest, dividends, royalties, and/or earned income.
The U.S. Expatriation Tax is not a hardship by any reasonable definition of hardship, and it's quite disingenuous to complain about not getting a $250,000 capital gains exclusion on a home when you're getting a $690,000 blanket exclusion. But if it were a hardship, there's a simple, 100% effective solution to avoid the U.S. Expatriation Tax: don't renounce or relinquish U.S. citizenship.
Microsoft is also ending/has ended the few important cloud-based services that support Nokia's S40-based devices. As of mid-2015, S40 still had almost double Windows Phone's global mobile user marketshare (according to StatCounter), so Microsoft's sunsetting of S40 services has a bigger global impact.
Both S40 and Windows Phone are in decline, though S40's bigger share is declining somewhat faster. Regardless, it's probably not good business strategy to upset over 4% of the world's mobile device users (S40) with premature termination of the few Microsoft/ex-Nokia services they do use. As far as I can tell, Microsoft is really not doing anything to help S40 users get to Windows Phone even if they wanted to go there. It's a major lost opportunity. For example, Microsoft could have: (1) held onto the Ovi Store (instead of outsourcing it to Opera where it's even more moribund); (2) provided a reasonable set of core, basic Microsoft services for S40 (notably Skype Chat, OneDrive with basic document viewing, and a basic Outlook.com client); (3) provided an S40 on-device application that keeps basic phone settings (contacts, calendar, bookmarks/favorites, text messages, etc.) synced across devices to smooth the path to Windows Phone; and/or (4) provided an S40 emulator for Windows Phone so that users could migrate as much or as little as they wanted. None of that would have cost very much to do or been hard to do, but as far as I know Microsoft took none of those steps. Consequently S40 device users are not switching to Windows Phone when they get new devices. It appears that, among S40 device users who are in the market for a new device, more of them are choosing new (or newer) S40 devices than are choosing Windows Phone devices! Google is winning most of them, though, primarily with Android One devices.
Of all the companies that should understand this phenomenon, you'd think Microsoft would. Don't orphan users! Give them realistic options to continue doing business with you, and they very well might! And if a 2.3% global marketshare business makes sense (Windows Phone), then keep shipping one or two S40 devices every year to hang onto as much of that ~4% marketshare as possible for as long as possible, with the sensible/inexpensive transition offerings I described. There is an ongoing market for a relatively simple mobile device with a truly long battery life and a more pocketable form factor, the segment of the market that Nokia dominated with S40. There's nothing wrong with that, and Microsoft should keep at it. (Microsoft is sort of doing that -- they still have a couple S40 devices on sale -- but they're not executing well.)
I completely agree. I'm afraid that was not one of the smarter things Linus -- an otherwise routinely brilliant guy -- has said. Outlook is a good example. As another example, if you look at the (continuing) evolution of mainframes and their operating systems -- and you must if you want to understand IT security fully, competently -- one interesting bit of history is that IBM had to rewrite OS/360 MVT in the early 1970s. That rewrite (OS/VS2 Version 2 MVS, later evolving through several MVS releases into OS/390 then z/OS) notably included adding what became SAF to get the security design right, though there were many other security design-related decisions in that massive rewrite effort. IBM, with all its resources -- and with ostensibly a less complex base -- couldn't stomp out all the bugs in OS/360, and there were lots of ongoing security and integrity problems in OS/360. (The two are closely related.) The z/OS security subsystem, RACF, uses SAF interfaces, and so do other security subsystems/providers such as ACF2 and TopSecret. Yes, you can choose your preferred security subsystem on this most popular mission-critical operating system. The security architecture is that clean and separated, as it should be.
Asymmetric information is a classic market failure, and automotive engineering is full of asymmetric information. Moreover, there are externalities, another classic market failure. Your Jeep's loss of control can cause my Chevrolet's trip into a brick wall, for example. Your Jeep's unregulated tailpipe emissions cause smog. Markets don't always (or even frequently) work well. But if you disagree, there are a few countries that offer unregulated free markets. I suggest moving to Somalia if you're an enthusiastic fan of free markets.
IBM's DB2 is the most prominent, most direct, most capable alternative. DB2 ranges from the zero license charge DB2 Express-C all the way up to the true continuous business service, mission critical DB2 for z/OS (that even Larry Ellison says nice things about). There's even a DB2 database cum tightly coupled operating system (IBM i). IBM publishes an Oracle to DB2 Conversion Guide and associated migration tools, and IBM has done a lot of work to implement technologies (e.g. PL/SQL) that make it easier to move to DB2. I don't know of any other realistic options because they have various shortcomings such as poor cross-platform support (notably Microsoft SQL Server), questionable SQL and/or ACID attributes, poor application support, and/or questionable enterprise support. In some cases you might be able to get away with MariaDB, for example, but you're probably going to need at least some DB2 to clear out Oracle completely -- and that's what you really need to do if you've got an abusive relationship. You'll also have to clear out some Oracle applications and middleware, but IBM is an obvious competitor there, too.
Slashdot Mirror
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.
Civil or criminal solutions are intrinsically Local, with varying measures of corruption involved.
No, I disagree. Governmental authorities are not equal, and that's helpful in this potential area of regulation.
If the United States and European Union were to introduce common IT security fitness requirements then they would likely be more than enough to form a "critical mass." A fairly straightforward legislative remedy, at least conceptually, would be to require Internet connected device and software vendors to provide complementary, opt-out, timely security updates for a minimum of X years after product withdrawal from sale (where X varies by product category, never less than 5) or, if failing in their obligations, to be barred from selling any new devices and to owe per device per month financial penalties to a consumer restitution fund. The penalty amount would be based on the product's market price but also subject to an inflation-adjusted minimum. Vendors might also be required to post performance bonds before first sale so that these security obligations (and restitution) survive their corporate demise. Then, even if Uganda, for example, does not enact the same legislation (or does not enact "proxy" legislation which simply says "the product can only be sold in Uganda if also legally offered for sale in the U.S. or E.U."), the combined might of the world's two largest economies would be enough to establish a global standard in vendor security maintenance practices.
Government product fitness regulation could work quite well in this instance.
Repeating something often enough doesn't make it true.
Rather the point! The fact is that the Java programming language and runtimes, today, utterly dominate Blu-ray disc players, Android smartwatches, and Android smartphones, to pick some examples. (And what examples they are!) They're powerful evidence that Java hardware and software efficiencies have improved tremendously over two decades. Java is a raging market success, including on devices that cannot afford much inefficiency. It's reasonable and rational to mark-to-market dated views of Java's hardware and software performance attributes. The successful, high efficiency use cases are staring us in the face, literally.
Of course it is still quite possible (a) to write lousy code that the toolchain and runtime, for any language, cannot performance-fix sufficiently for your intended use cases; (b) to have certain scenarios where Java and its toolchain/runtime (for a particular implementation at a particular moment in time) do not produce the very highest efficiency/performance result technically achievable. Point (a) is always true (although a richer and deeper toolchain, and associated skills, can help a lot), and point (b) simply means that you toss efficiency/performance into your calculus with the relative importance it merits for your particular needs. There are other programming languages (and associated runtimes) available, including five durable ones: COBOL, FORTRAN, C, C++, and PL/I. Plus myriad not-yet-durable (and most never will be) options. (Pascal, Ada, ALGOL.... IT history is littered with them.)
If Java is so great... why Mozilla and almost any sane browser ask us to not run anything based on it and block the plug-in?
Because the browser plug-in security model was/is fundamentally broken. Browser vendors are discontinuing that plug-in model for every plug-in. If you want to continue running PC client side Java applications then you'll be moving to something called Java Web Start. JWS is a different, more secure way to launch those applications. Meanwhile, the Web sites you visit are often running lots of Java code to generate the content your Web browser displays. And if you're browsing the Web from an Android device (far more numerous than PCs) then most of the apps you run are written in Java. There's more Java than ever, but the ways and places Java runs are changing and multiplying.
There is a need for a light weight, garbage collected language with static typing an efficient compilation, but it does not exist. So Java it is.
Exactly. However, Java is pretty damn lightweight and efficient nowadays -- a heck of a lot less heavy than many alternatives. Partly that's because hardware improved, but mostly it's because several Java implementations have improved tremendously over the circa two decades and counting of Java's history. So, for example, Java is a mandatory part of the Blu-ray standards on ~$50 video players. And Google's Android Runtime (ART), another implementation of Java technology, is the world's most popular smartphone platform. On the server side there are extremely fast starting, lightweight, lower memory runtimes such as IBM's WebSphere Liberty Profile. The traditional efficiency rap against Java doesn't apply any more. "Back in the day" people complained about COBOL because it was "too slow" compared to that (allegedly) hand tuned Assembler code they weren't actually writing. Well, for several years, they had a point. By about the 1970s they didn't. Hardware improved, and the compilers got a lot better -- and that process continues, also for COBOL. Java used to be slow, sure...but what's that in your hand and on your wrist now? (And color TV used to suck, and car tires used to blow out at the first pothole....)
Another huge point in Java's (and for that matter COBOL's) favor is that it's a durable programming language. The invested value in Java code, and the ability to draw from that code portfolio to solve problems, is utterly massive. It's so massive that the Java programming language has crossed over into IT immortality along with only a very few other programming languages (FORTRAN, C, C++, and probably PL/I). Also, Java is the most demonstrably portable programming language (and compilation/runtime path) we have. (Any other nominees?) It's not at all hard to write functionally portable Java code that'll run, unmodified, on platforms ranging from Android smartwatches to z/OS mainframes. That's the default, and it really does work. High quality, performance-optimized and/or battery-optimized code is always a separate question. Any programmer can write lousy code in efficiency terms, and most do at least for Version 1.
"Sort of." Java 8 added unsigned integer arithmetic methods to Integer. Examples: compareUnsigned, divideUnsigned, parseUnsignedInt, remainderUnsigned, toUnsignedLong, etc. You still use long and int, and they still have the capability to store signed values. However, if you want, you only use them for unsigned values and with the Unsigned methods.
I don't think it's a "glaring omission." Life is quite difficult without signed integers -- you've really got to have those. Signed integers (of sufficient width) can functionally do everything unsigned integers can do. (What *functionality* are you missing?) If you have both signed and unsigned integers then you've got to have facilities for typecasting, and that has proven to be at least complicated enough. I think the reason unsigned integer data types were created in other languages has much more to do with the "every bit is precious" constraints in the formative years of those languages and their ancestors. They didn't want to "spend" a precious bit on a sign for every integer, hence the unsigned integer data type. Well, the 1990s (and even 1980s) came calling, with 32-bit and 64-bit addressable memory, and we don't have to be quite so bit thrifty. Every integer can have its sign, even if we never need it.
Signed strings and characters in Java were probably a mistake, though.
Bearing in mind that public funds are involved here, I'm struggling to understand why improving radio communications using "plasma bomb" satellites is such a great idea when satellites already do such a great job improving radio communications. In other words, we have vast numbers of artificial ionosphere "bouncers" already orbiting our planet, and we can also have high altitude tethered balloons and long duration airborne aircraft (perhaps solar electric) that the likes of Google and Facebook are working on -- and with much less investment than even one copy of the some of the aircraft the U.S. Air Force flies. We already know how to bounce radio signals all around the globe, and it's already cheap, reliable, and secure. So what's the "value add" here that merits substantial public investment? Anybody have any ideas?
One further point. I'm implicitly assuming long-term capital gains tax rates, and that's a reasonable assumption when oversimplifying slightly. For the record, short-term holdings (assets held less than one year) can get taxed at ordinary income tax rates. The top marginal U.S. income tax rate is currently 43.4% inclusive of the Net Investment Income Tax (NIIT) if it applies. However, short-term holdings presumably haven't gained as much value as long-term holdings, especially in the aggregate, unless you've been particularly lucky. And there's a simple solution for that, too: wait until the short-term holdings become long-term holdings (held for one year), then expatriate.
;) You've got to be solidly within the top 5% on a wealth basis to get to an Expatriation Tax calculation, never mind actually owing any Expatriation Tax. And then, if you do pay some, you're resetting your cost basis anyway. You're just paying Uncle Sam what you would have paid when you sold the assets, less a blanket exemption. That's quite fair when checking out permanently, just as you must settle your hotel bill and minibar tab when you check out of a hotel.
These are not exactly middle class problems, are they?
You've provided reasonable links, but you simply haven't read that information correctly. Here's how the U.S. Expatriation Tax actually works (assuming your net worth exceeds $2 million or that you otherwise are subject to the Expatriation Tax), oversimplifying only slightly:
1. Take your total worldwide net worth at fair market value as if all your assets were sold the day before your expatriation date.
2. Subtract your total worldwide cost basis from your net worth. The result is your total gain from your mark-to-market "deemed sale."
3. Subtract $690,000 (tax year 2015, adjusted annually for inflation) from your total gain. The result is your total taxable gain. If your total taxable gain is zero or negative, stop: you do not owe any Expatriation Tax.
4. Otherwise, pay ordinary capital gains tax rates on your total taxable gain, with a current top marginal tax rate of 23.8% (if the NIIT applies, and I'm not sure it does, but let's assume that). This is your total U.S. Expatriation Tax.
If you owe Expatriation Tax your cost basis is reset. Any subsequent capital gains on U.S. assets will only be taxed based on your new, reset cost basis. Note that "wash sale" rules do not apply when making the Expatriation Tax calculation, so deemed sale capital losses are not limited within the calculation. To some degree you can pay your Expatriation Tax in installments if you wish and only pay statutory interest on deferred payments (currently 3%). If your assets are generating a higher after-tax rate of return (quite likely) then stretching out your Expatriation Tax payment to the maximum extent allowed by law is a good idea. You may also wish to stretch out your Expatriation Tax payments if you prefer to raise funds more slowly, perhaps as in the form of interest, dividends, royalties, and/or earned income.
The U.S. Expatriation Tax is not a hardship by any reasonable definition of hardship, and it's quite disingenuous to complain about not getting a $250,000 capital gains exclusion on a home when you're getting a $690,000 blanket exclusion. But if it were a hardship, there's a simple, 100% effective solution to avoid the U.S. Expatriation Tax: don't renounce or relinquish U.S. citizenship.
Microsoft is also ending/has ended the few important cloud-based services that support Nokia's S40-based devices. As of mid-2015, S40 still had almost double Windows Phone's global mobile user marketshare (according to StatCounter), so Microsoft's sunsetting of S40 services has a bigger global impact.
Both S40 and Windows Phone are in decline, though S40's bigger share is declining somewhat faster. Regardless, it's probably not good business strategy to upset over 4% of the world's mobile device users (S40) with premature termination of the few Microsoft/ex-Nokia services they do use. As far as I can tell, Microsoft is really not doing anything to help S40 users get to Windows Phone even if they wanted to go there. It's a major lost opportunity. For example, Microsoft could have: (1) held onto the Ovi Store (instead of outsourcing it to Opera where it's even more moribund); (2) provided a reasonable set of core, basic Microsoft services for S40 (notably Skype Chat, OneDrive with basic document viewing, and a basic Outlook.com client); (3) provided an S40 on-device application that keeps basic phone settings (contacts, calendar, bookmarks/favorites, text messages, etc.) synced across devices to smooth the path to Windows Phone; and/or (4) provided an S40 emulator for Windows Phone so that users could migrate as much or as little as they wanted. None of that would have cost very much to do or been hard to do, but as far as I know Microsoft took none of those steps. Consequently S40 device users are not switching to Windows Phone when they get new devices. It appears that, among S40 device users who are in the market for a new device, more of them are choosing new (or newer) S40 devices than are choosing Windows Phone devices! Google is winning most of them, though, primarily with Android One devices.
Of all the companies that should understand this phenomenon, you'd think Microsoft would. Don't orphan users! Give them realistic options to continue doing business with you, and they very well might! And if a 2.3% global marketshare business makes sense (Windows Phone), then keep shipping one or two S40 devices every year to hang onto as much of that ~4% marketshare as possible for as long as possible, with the sensible/inexpensive transition offerings I described. There is an ongoing market for a relatively simple mobile device with a truly long battery life and a more pocketable form factor, the segment of the market that Nokia dominated with S40. There's nothing wrong with that, and Microsoft should keep at it. (Microsoft is sort of doing that -- they still have a couple S40 devices on sale -- but they're not executing well.)
I completely agree. I'm afraid that was not one of the smarter things Linus -- an otherwise routinely brilliant guy -- has said. Outlook is a good example. As another example, if you look at the (continuing) evolution of mainframes and their operating systems -- and you must if you want to understand IT security fully, competently -- one interesting bit of history is that IBM had to rewrite OS/360 MVT in the early 1970s. That rewrite (OS/VS2 Version 2 MVS, later evolving through several MVS releases into OS/390 then z/OS) notably included adding what became SAF to get the security design right, though there were many other security design-related decisions in that massive rewrite effort. IBM, with all its resources -- and with ostensibly a less complex base -- couldn't stomp out all the bugs in OS/360, and there were lots of ongoing security and integrity problems in OS/360. (The two are closely related.) The z/OS security subsystem, RACF, uses SAF interfaces, and so do other security subsystems/providers such as ACF2 and TopSecret. Yes, you can choose your preferred security subsystem on this most popular mission-critical operating system. The security architecture is that clean and separated, as it should be.
Asymmetric information is a classic market failure, and automotive engineering is full of asymmetric information. Moreover, there are externalities, another classic market failure. Your Jeep's loss of control can cause my Chevrolet's trip into a brick wall, for example. Your Jeep's unregulated tailpipe emissions cause smog. Markets don't always (or even frequently) work well. But if you disagree, there are a few countries that offer unregulated free markets. I suggest moving to Somalia if you're an enthusiastic fan of free markets.
IBM's DB2 is the most prominent, most direct, most capable alternative. DB2 ranges from the zero license charge DB2 Express-C all the way up to the true continuous business service, mission critical DB2 for z/OS (that even Larry Ellison says nice things about). There's even a DB2 database cum tightly coupled operating system (IBM i). IBM publishes an Oracle to DB2 Conversion Guide and associated migration tools, and IBM has done a lot of work to implement technologies (e.g. PL/SQL) that make it easier to move to DB2. I don't know of any other realistic options because they have various shortcomings such as poor cross-platform support (notably Microsoft SQL Server), questionable SQL and/or ACID attributes, poor application support, and/or questionable enterprise support. In some cases you might be able to get away with MariaDB, for example, but you're probably going to need at least some DB2 to clear out Oracle completely -- and that's what you really need to do if you've got an abusive relationship. You'll also have to clear out some Oracle applications and middleware, but IBM is an obvious competitor there, too.