Microsoft releases a feature in year Y. Application that could benefit can't use it till year Y+12.
Sure, but about the only thing in the Windows world that really are OS-version-dependent are device drivers, and even those are remarkably portable. MS supports APIs forever, and I couldn't tell you what APIs any particular program I have uses as an application written for Windows XP generally looks/behaves the same as one written for Win7. Sure, MS did do something fairly new with Metro, but unless you're writing applications for tablets/netbooks I don't think there is really anything you desperately need to use there.
So Microsoft needs to break companies of that habit.
Lots of people say this, but the day that MS breaks companies of this habit is the day MS breaks companies out of being dependent on MS. If a company needs to completely retool its application landscape every 3-4 years in order to stick with Windows, then they really don't need to do all that much more to ditch Windows. That isn't a great position for MS to be in when it comes time to negotiate licenses.
Being able to upgraded once a decade is one of MS's biggest selling points. Then, even if you do upgrade they provide backwards compatibility at the application level basically forever - I wouldn't be surprised if you could run calc.exe from Win3.1 on Windows 7. In practice it doesn't work quite that well, but you can go much further back on Windows than you can on virtually every other OS out there. I can't count the number of times glibc's ABI has been changed in the time that I've been using it, and I'm not really what I'd consider a Linux old-timer.
That was Sun's position. I think they were right. The problem was always that some percentage of applications were thick client. Usually rolling into enterprise from the home/small business space or needed performance. So in practice it was too hard to do, since thin client needs to be true for 100%.
For all but the most performance-intensive operations Citrix works just fine. Companies have cut down on travel so much that many of the traditional demand for offline access is going away as well (plus, being completely offline is becoming increasingly rare). However, on the other hand there is AJAX/etc and it isn't really clear whether the future looks more like Sunfire or Chromebooks.
With the rise of mobile applications the home/small business space is moving back towards a rich client experience. With the rise of touch interfaces performance matters tremendously humans are disturbed by latencies above 1ms with touch / visual (no system is that responsive yet). So I don't think this is going to happen.
True, though one of the things that is also helping with mobile applications is the ditching of a lot of legacy practices that caused all kinds of problems. Mobile apps don't generally have dependencies other than the OS API, which makes them very easy to install/remove/etc. They're highly contained, though at least in Android there is the ability for applications to interact on more SOA-like ways. There is no support for adding device drivers, so the need to maintain OS compatibility really is limited to the API. Oh, and whoever makes the device gets 1/3rd of the application revenue - not sure how well that will go over when a company wants to buy a $2M automation platform with 100 installs...
You don't expect >10 years of active support for IT systems unless you're running a freaking nuclear power plant.
Not entirely true. Granted, things today have gotten a bit better due to all the pain companies felt back in the early 2000s getting off of NT, but there still are a lot of software packages out there that only support a single operating system.
Story usually goes like this. Company buys a $10M ProGadget 7 which comes with a PC running FooOS 3 and ControlSoft 12. Then 5 years later IT says that FooOS 3 has got to go and you need to upgrade to FooOS 5 within two years. The guy who uses the ProGadget 7 calls up the vendor and the vendor tells them that ControlSoft 12 only works on FooOS 3. So the guy who needs the ProGadget 7 to do his job tells IT he can't comply. IT then does some homework and tells the gadget operator that there is no problem - they just have to get a ProGadget 9 which works with ControlSoft 17 and that works fine on FooOS 5. The problem is that a ProGadget 9 costs another $10M and the original purchase only made sense when amortized over 10 years. The competition is just living with FooOS 3 so they can either raise their prices and go out of business, or not use the ProGadget and go out of business.
Boeing, Raytheon... need to learn that Microsoft's expiration dates mean something. Microsoft may not let them fail. But they should change them such a ton that they learn their lesson and build a 3-4 year upgrade policy into their desktop infrastructure.
I doubt that the bulk of the complaining comes from companies the size of Raytheon and Boeing. The issue is likely more with medium-sized companies that don't have a huge IT function and volume licensing agreements. I work at a Fortune 500 company and we've probably had the option to upgrade from XP since Vista came out - the choice of when to do so was more about logistics and internal costs than licensing.
A 3-4yr OS upgrade policy was not really feasible going back 10 years with the huge reliance on stuff like ActiveX and Win32 applications. Many of those applications have capital costs in the millions of dollars (when you look at the costs of licensing and customization), and you can't just amortize those costs over 4 years and have them make sense - not to mention the army of IT workers you'd need to mange the increase in project volume to oversee all those replacements.
However, there is no need for a 3-4yr policy - MS supports its OSes for 10 years from the date that a replacement is available. That usually works out to something like 13 years from date of introduction. An 8-10 year replacement cycle seems completely adequate and lets you also cherry-pick OS releases since MS tends to shoot themselves in the foot every other iteration.
Longer-term companies should try to move as much as they can to pure web-based or at least thin-client software. To the degree that this can be done you greatly reduce the complexity of upgrading client OS or the need for standardization. If you really could get all the software to run in a browser you could even just roll out something like ChromeOS, or give every employee a choice of what they want and have a support policy of reimage first, ask questions later.
The question is: How much does it actually cost them (in dollars) to support XP?
Probably no more than it would cost Ubuntu to support 4.10, which was released a full 3 years after XP, and de-supported 7.5 years ago.
Look, I love Linux as much as the next guy, but I don't think absolutely complaining about the length of MS's desktop OS support has a leg to stand on. MS supports their desktop OSes from 10 years after the next version is available - they don't even measure from date of first introduction.
What other OS releases from 1999 still get full security backports? I can't think of one. XP is STILL supported today (goes back to 2001), OSX only goes back to 2007, RHEL goes back to 2007 (though they promise that the current release will get 13 years, which is comparable to Windows), and Ubuntu promises 5 years now, but they don't currently support any desktop OS released more than 1.5 years ago (previous LTS releases did not get as much support).
Sure, it would be nice if XP were supported until 2100, but you can't really fault them for drawing a line SOMEWHERE.
Its purpose was to force insurance companies to cover pre-existing conditions.
Wrong. The purpose was to force people to hand over their money to private companies whether they want to or not. It's called Fascism.
Sure, 2/3rds of the country is screaming for healthcare reform because they really don't care about their health at all, but they just want to force you to buy insurance when you just want to be left alone and pay for your own bills and die as soon as you run out of money.
Or maybe it really is about getting rid of the ban on denial of payment for pre-existing conditions.
So, which form of health reform do you favor - one that allows companies to deny treatment for any condition they consider pre-existing (you can always sue them if you disagree), or one that does not allow companies to do this? If the latter, how would you do this without requiring everybody to be insured?
And if you want to tell me that you don't favor health reform, then I'll just tell you to have your favorite candidates win the election next time.
You can't have your cake and eat it too - retroactive insurance just doesn't work. Insurance can only work when there is a known risk but an uncertain outcome. When you know the outcome, then there just isn't a market for insurance at all. What is the free market for people paying you $10 so that they can immediately hand you $100 in bills for you to pay for them? No country in the world operates this way - whether healthcare is public or private.
I'd say that it is appropriate for the government to regulate both, but for different reasons.
It is appropriate to require car drivers to have insurance because the risk of accidents is relatively high, and that means that others are likely to be subject to losses for which the driver is liable but unable to pay. Insurance is mandatory to protect everybody else from you.
In the case of health insurance it is a bit more roundabout. We want to protect everybody from false claims of everything being a prior condition, so we want to ban companies from making that claim. Then in turn we end up having to protect companies from people really having prior conditions and making the company pay for it. So, it is more of a compromise.
Government has decided that it is a bad decision for people to not purchase health insurance. I know many perfectly reasonable, rational people who did not purchase health insurance before the ACA because it was not worth it to them.
The insurance mandate wasn't created to force people to buy insurance, though obviously it has that side-effect. Its purpose was to force insurance companies to cover pre-existing conditions. If you force companies to cover pre-existing conditions and you don't force people to buy insurance, then everybody signs up for insurance in the ER and cancels as soon as they are discharged, and the entire industry collapses (whether public, private, or whatever - though public insurance usually is tax-funded and thus everybody is forced to buy it).
Disallowing coverage for pre-existing conditions sounds good on paper - it is how every other insurance system works. The problem is that health insurance isn't like car insurance. If you car looks like it was in an accident, chances are that it was in an accident, and the police can tell you exactly when that happened and it is obvious whether the car was insured at that time or not.
Now take somebody who has a heart attack a week after getting insurance. They might have keeled over with insurance, but that plaque in the arteries has been forming for years. We don't even know what causes that plaque to form, let alone when that chain of events started. On top of that you get sleezy insurance companies that will dig back 10 years and find three days that you were out of work and uninsured 8 years ago and argue that you must have eaten a cheesesteak on one of those days that kicked off the whole chain of events and deny your claim.
Denial of pre-existing conditions is the cause of half the mess that is the US insurance system, and nobody wanted a new system that kept that feature in place. That made an insurance mandate unavoidable from the start. The only question is what form it took. If there were a public option then the mandate would come from the fact that taxes are mandatory - even if you don't sign up you're effectively still insured because you're paying into the system.
In fact, one of the biggest problems with Obamacare is that the penalty for not signing up is too low. It is cheaper to not buy insurance than to buy it, and thus the incentive to sign up in the hospital still exists. The penalty should be substantially higher than the cost of buying insurance - thus creating a fund that can pay for any bills incurred while uninsured.
How much capital gains tax did Facebook pay to the IRS when they created $90B in stock certificates that didn't exist the instant before the IPO? I doubt they had to pay capital gains on issuing stock. Those who bought and sold it, of course, had to do so.
Why wouldn't bitcoin be any different? The person creating the bitcoin is creating an asset, not buying/selling one.
In the US, To be taxed at the lower rate, it must be classified as "long-term" - I.e. the asset must be held for at least a year before it's sold. Other (short-term) gains are taxed at the same rate as income.
Isn't capital gains tax charged on the appreciation of an asset from the moment you acquire it to the moment you sell it?
If you mine a bitcoin and sell it immediately, then the capital gain on it would be zero. You would only have a gain if you bought the bitcoins from somebody else. That is of course how many bitcoins are acquired.
I'm not suggesting that a plane couldn't be remote-flown effectively, or that the autopilot isn't capable of doing nearly everything. I don't think any today are capable of doing the takeoff roll on their own, and some essential controls like flaps/etc aren't controlled by the autopilot. Also, I don't believe that most aircraft can handle the necessary mode changes, like moving from following path navigation to switching to a CatIII ILS. There is no reason that couldn't be changed, but there would need to be a few changes.
However, the way aircraft actually operate you'd still need about 2 people per plane at certain points in the flight to be safe. You could certainly have them only control the aircraft at critical points and have them take care of other aircraft while they're in cruise/etc with just occasional check-ins.
The autopilot is perfectly capable of following the programmed course all the way to the ground. The reason you need about two people managing the autopilot is that this planned course can't always be predicted before takeoff. If the crew gets the correct news on approach/runway while they're not too busy before decent then they can take their time programming it into the computer and one person wouldn't have any problems keeping up. However, if the winds shift, or ATC has to deal with traffic, or whatever, and during approach the pilots get directions to switch to some other approach/runway then there is a huge pile of time-critical work to be done. The airplane is moving forward at 250kts (that's more than a mile every 15 seconds) along its previously planned route, the crew has to figure out where the new route is in relation to the current one and how to transition from one to the other. Often the crew will just put the plane on a manual course or direct-to course just to get it moving in the correct general direction while they program in the rest of the course. Anything that gets programmed in needs to be checked, because there could be clouds and mountains and buildings in the area and you don't tell a plane to go anywhere without making sure it is absolutely correct. If there is doubt the pilots might need to do a climb to the regions minimum safe altitude - charts indicate heights that are guaranteed to be free of terrain/obstructions with room for safety so once a plane is above that altitude the only issues are time/convenience and running out of fuel (assuming weather doesn't require the plane to try to land sooner).
A few crashes have happened as a result of pilots not managing changes during critical segments of flight.
Not all of the factors that lead to last-minute changes are preventable. Better automation could probably reduce the impact of traffic, but nothing can prevent a storm from moving through, or winds from changing. So, even if remotely piloted a plane will still need 1-2 people paying attention to it during critical phases of flight. Now, those people probably won't be looking out the window or handing yokes - they'll probably be sitting at computer terminals and touchscreens and such. In fact, route planning/entry/verification could probably be done more effectively from a console designed expressly for that purpose vs a cockpit designed for direct manipulation of control surfaces.
There are also a lot of good concepts like no-lights-is-good - when you first power on an aircraft you see a LOT of lights. When you're in cruise the entire panel is basically dark aside from the autopilot mode indicators and the flight instruments (map, attitude, alititude, speed, etc). On some aircraft even some common autopilot functions (like autothrottle and yaw dampening) are only lit if they are off, because they're almost never off (well, unless you want to crash into a jetty at SFO - and I don't think the 777 is one of those lit-if-off autothrottles). On an airbus the autothrottle isn't even a toggle so much as how the throttle control behaves.
That is also why PC fight simulators aren't really that practical to use unless they're full of "cheats" or you make heavy use of the pause button. You really can't keep up with an airliner landing workflow with a mouse and keyboard and joystick the way you can if the radio actually has a dial on it or dedicated keypad. Even the jets aren't designed to be flown by a single person (though in a non-emergency situation they probably could be at a higher risk of missing something important).
Except we've all seen evidence of PhDs having an awesome theoretical grasp of something, and absolutely zero practical grasp of something.
I'd argue that being able to design an engine and being able to drive a truck are really orthogonal skillsets. Sure, there is some overlap in the basics, but you could be really good at one and not at the other. You could also be good at both, or neither.
Perhaps one of the key skills for a successful truck driver is the ability to maintain attention through many hours of relative boredom and then be instantly at-attention when something goes wrong. That doesn't seem like a skill that has anything to do with the ability to do engineering/science/etc. Maybe back in the days when scientists counted shooting stars or scintillations manually it would have been a bit of a closer fit.
Most businesses in the US are surprisingly competitive - it isn't really trivial for anybody to just walk in and take somebody else's job, no matter how easy it might seem. Ever watch the Top Gear episode where they try to figure out how to work the tractor?
I never claimed that Nokia had assets worth $3.6B in India. My intent was simply to explain that if the parent post's assertion that the tax was based on the factory value was true, then Nokia really couldn't just walk away. I was faulting the deductive logic of the post I replied to, not affirming the premises the argument was based upon.
"Probably" means you don't know what you're talking about.
No, it simply means that I don't make wild assertions without fully checking the facts, like telling you that you don't know what you're talking about.
I'm only aware of one or two cases in the last decade where somebody might have gotten indefinitely detained on US soil (the shoe bomber comes to mind). I'm not sure there are actually any cases of actual indefinite detentions. I think the US government has been charging anybody caught on US soil. However, I could be wrong.
If I am wrong, well, you could be helpful and provide the stats.
The fact is that you're FAR more likely to get kidnapped if you go visit someplace in South America than you are likely to end up in Gitmo if you go visit Chicago. In fact, I'd say you're probably more likely to end up in Gitmo if you go to South America than if you go to the US, because the US uses Gitmo to house people caught outside the US to avoid introducing them into the US justice system.
Well, my whole point was that you were less likely to get kidnapped on US soil (or in the EU) than in some random third world country. So, I'd consider it relevant whether the US does the aforementioned abductions on US soil or not. You're more likely to end up in Gitmo if you're outside the US than in it.
My post had nothing to do with whether this practice is right or wrong.
I'd be fine with just banning retirement savings as an employment benefit entirely then, or (gasp!) simply making it a government benefit. Though, if it were a government benefit I probably would substantially raise the eligibility ages, and I'm also for more benefits for people who are between jobs (the nature of the society we live in makes it hard for everybody to be employed).
In the US, failure of 401ks is usually not a problem. The issue of investment risk/planning certainly is a problem, but not disappearance of the funds themselves. There are never "shortfalls" - they are just bank accounts and the statement reflects how much you hold. I'm sure there are lots of disappointments, but the balance reflects the performance of the investment. A shortfall implies that there is some targeted amount of money that should be in the fund, and with 401ks there is no target.
For the most part they tend to be invested in mutual funds, which publish a daily NAV which is nothing more than the total money held by the fund divided by the number of shares. Unless there is fraud that always works out. If there is fraud virtually all mutual funds are SPIC insured.
Pension plans are an entirely different story. Shortfalls often exist, since they are often defined-benefit. If the company goes bankrupt the pension gets lost, and anybody who worked at the company for the previous few decades takes the loss. That's why I consider 401ks to be superior to pensions. I'm the first to agree that they have their own issues.
My big issue with pensions is that they're a form of false advertising. A company gets you to work today for less income because they dangle a promise of more income in the future. However, that's really just an investment of a different kind. Sure, investing in mutual funds carries all kinds of risks, but the current state is that people invest everything in a SINGLE company, and one that happens to be their employer so that if it goes belly-up they end up like the employees of Enron. (Oh, on that note I would ban requirements that 401k funds be invested in company stock.)
Look, I'm more annoyed with the civil liberty issues in the US than most, but you're stretching things. The US government probably has only detained a few people indefinitely on US soil in the last decade, and while their treatment is clearly unconstitutional they didn't exactly have clean hands. On the other hand, in quite a few countries out there you run a significant risk of being kidnapped and held for ransom simply for looking like an American. The risks are not comparable.
Ditto for power reliability. Ok, so the US had a big blackout for a few hours 10 years ago, and California had a self-imposed series of blackouts about 15 years ago. I'd also agree that we're really pushing the limits on capacity such that we're at risk of some major problems. However, in many regions in Asia you can count on the power going out almost daily for hours.
I won't claim that Walmart workers are well-treated. However, they certainly are much higher-cost than workers in Asia in absolute terms, which is all the company paying them cares about. There is a big difference between $7/hour and $5/day.
Ok, so you have $10k in a bank account in Peru. You want to transfer the money to your account in the US. The bank says that before you're allowed to move the money you have to pay a $500 tax to the government.
The new tax is $3B. The old tax is $300M. The factory is not even worth $300M. Your analogy is silly.
I'm just explaining the post you replied to, which stated, "The tax is on the value of the factory. The factory is obviously more valuable than the tax liability." If that statement is not true, then my explanation of that statement would not be true. I cannot personally vouch for the value of Nokia's holdings in India.
Sure, this is a shakedown, but it isn't like Nokia can just walk away. Most likely they need to bribe the right person, which is how business is often done outside the US/EU.
Keep in mind that what the US calls "EFT" and what the rest of world calls "EFT" is a bit like the difference between what kids listened to music on in the 80s vs today.
EFT exists in the US - it isn't the same thing as wire transfer.
There was a good NPR episode on this recently.
The issue is that the US EFT system (called ACH or the Automated Clearing House) is a batch-based system that involves several days (err, BUSINESS DAYS!) of latency. It was invented at a time when this was actually an advance over checks and back then literally involved transporting reels of tapes (as opposed to bags of checks). Today it works like you'd expect a more modern operation to work, aside from daily batching, shutdowns during off-hours, etc.
Banks have opposed improving the US EFT system, in part because it would cost them money to implement any changes, but mostly because they can make a fortune charging for wire transfers when you don't want it to take several days to send money around. Wire transfers usually take seconds, like ordinary money transfers anywhere else, and they cost tens of dollars each.
I do pay my bills electronically though via EFT. It just takes a day or two for payments to get through (and sometimes it takes a week if the bank actually does have to cut a check).
Why not just use digital cash - the kind that was invented back in the 90s. That is completely anonymous and untraceable, but it relies on having a bank that issues the currency and then deposits it when it changes hands. Like cash it can be stolen though - it really IS anonymous and untraceable so don't let somebody else get a copy of your money or you'll find it spent when you go to spend it.
Yup. If you don't mind trusting a central authority then there is a completely anonymous alternative to Bitcoin and that is digital cash.
It is a sound technology rooted in crypto that has been around for ages. It allows a trusted bank to issue currency that can be freely exchanged in an anonymous fashion online and then redeemed back with the bank. That is, the bank could give me a string of bytes worth $10, which I could then use to give you a different string of bytes, and then you could give the bank that string of bytes and get $10 deposited into your account, but the bank would not be able to tell where that string of bytes originated, but they could be sure it is authentic.
For whatever reason I can't find a good description online. The concept is that the individual actually creates the currency and encrypts it, and then the bank signs it blindly to make it authentic. The signature is such that it remains valid if the message is decrypted, so the currency can then be used without the bank being able to associate the currency with what it signed. The obvious weakness is how the bank knows what it is signing, and that is done by having the currency creator issue a large number of identically valued pieces of currency, and then the bank asks for the decryption keys to all but one of its choosing. If the currency it verifies is valid then it assumes that the one it couldn't read is valid and signs it. There is no real chance of getting away with forging money as a result (the bank could ask you to generate a million $20 bills and only sign one of them, so you'd have to guess which of the million ones to forge and there would be ramifications if you were caught doing it).
This is much more anonymous than Bitcoin - it works just like bills in circulation. However, it relies on a central bank, which can issue all the currency it wants to. It is superior to cash in most ways, but it isn't useful for offline transactions, because currency can be copies and only the first copy that makes it to the bank is valid (so be sure to deposit that cash before calling the sale done).
The irony is that despite the fact that contracts for the sale of real estate are registered in my jurisdiction, we still have to pay for title insurance in case the government's records aren't correct. It would be trivial to switch to a system like Australia's (the databases already exist), but for the loss of income to the insurance companies, and to banks who find their loans refinanced more often due to the reduction in closing costs.
Slashdot Mirror
Microsoft releases a feature in year Y. Application that could benefit can't use it till year Y+12.
Sure, but about the only thing in the Windows world that really are OS-version-dependent are device drivers, and even those are remarkably portable. MS supports APIs forever, and I couldn't tell you what APIs any particular program I have uses as an application written for Windows XP generally looks/behaves the same as one written for Win7. Sure, MS did do something fairly new with Metro, but unless you're writing applications for tablets/netbooks I don't think there is really anything you desperately need to use there.
So Microsoft needs to break companies of that habit.
Lots of people say this, but the day that MS breaks companies of this habit is the day MS breaks companies out of being dependent on MS. If a company needs to completely retool its application landscape every 3-4 years in order to stick with Windows, then they really don't need to do all that much more to ditch Windows. That isn't a great position for MS to be in when it comes time to negotiate licenses.
Being able to upgraded once a decade is one of MS's biggest selling points. Then, even if you do upgrade they provide backwards compatibility at the application level basically forever - I wouldn't be surprised if you could run calc.exe from Win3.1 on Windows 7. In practice it doesn't work quite that well, but you can go much further back on Windows than you can on virtually every other OS out there. I can't count the number of times glibc's ABI has been changed in the time that I've been using it, and I'm not really what I'd consider a Linux old-timer.
That was Sun's position. I think they were right. The problem was always that some percentage of applications were thick client. Usually rolling into enterprise from the home/small business space or needed performance. So in practice it was too hard to do, since thin client needs to be true for 100%.
For all but the most performance-intensive operations Citrix works just fine. Companies have cut down on travel so much that many of the traditional demand for offline access is going away as well (plus, being completely offline is becoming increasingly rare). However, on the other hand there is AJAX/etc and it isn't really clear whether the future looks more like Sunfire or Chromebooks.
With the rise of mobile applications the home/small business space is moving back towards a rich client experience. With the rise of touch interfaces performance matters tremendously humans are disturbed by latencies above 1ms with touch / visual (no system is that responsive yet). So I don't think this is going to happen.
True, though one of the things that is also helping with mobile applications is the ditching of a lot of legacy practices that caused all kinds of problems. Mobile apps don't generally have dependencies other than the OS API, which makes them very easy to install/remove/etc. They're highly contained, though at least in Android there is the ability for applications to interact on more SOA-like ways. There is no support for adding device drivers, so the need to maintain OS compatibility really is limited to the API. Oh, and whoever makes the device gets 1/3rd of the application revenue - not sure how well that will go over when a company wants to buy a $2M automation platform with 100 installs...
You don't expect >10 years of active support for IT systems unless you're running a freaking nuclear power plant.
Not entirely true. Granted, things today have gotten a bit better due to all the pain companies felt back in the early 2000s getting off of NT, but there still are a lot of software packages out there that only support a single operating system.
Story usually goes like this. Company buys a $10M ProGadget 7 which comes with a PC running FooOS 3 and ControlSoft 12. Then 5 years later IT says that FooOS 3 has got to go and you need to upgrade to FooOS 5 within two years. The guy who uses the ProGadget 7 calls up the vendor and the vendor tells them that ControlSoft 12 only works on FooOS 3. So the guy who needs the ProGadget 7 to do his job tells IT he can't comply. IT then does some homework and tells the gadget operator that there is no problem - they just have to get a ProGadget 9 which works with ControlSoft 17 and that works fine on FooOS 5. The problem is that a ProGadget 9 costs another $10M and the original purchase only made sense when amortized over 10 years. The competition is just living with FooOS 3 so they can either raise their prices and go out of business, or not use the ProGadget and go out of business.
Boeing, Raytheon... need to learn that Microsoft's expiration dates mean something. Microsoft may not let them fail. But they should change them such a ton that they learn their lesson and build a 3-4 year upgrade policy into their desktop infrastructure.
I doubt that the bulk of the complaining comes from companies the size of Raytheon and Boeing. The issue is likely more with medium-sized companies that don't have a huge IT function and volume licensing agreements. I work at a Fortune 500 company and we've probably had the option to upgrade from XP since Vista came out - the choice of when to do so was more about logistics and internal costs than licensing.
A 3-4yr OS upgrade policy was not really feasible going back 10 years with the huge reliance on stuff like ActiveX and Win32 applications. Many of those applications have capital costs in the millions of dollars (when you look at the costs of licensing and customization), and you can't just amortize those costs over 4 years and have them make sense - not to mention the army of IT workers you'd need to mange the increase in project volume to oversee all those replacements.
However, there is no need for a 3-4yr policy - MS supports its OSes for 10 years from the date that a replacement is available. That usually works out to something like 13 years from date of introduction. An 8-10 year replacement cycle seems completely adequate and lets you also cherry-pick OS releases since MS tends to shoot themselves in the foot every other iteration.
Longer-term companies should try to move as much as they can to pure web-based or at least thin-client software. To the degree that this can be done you greatly reduce the complexity of upgrading client OS or the need for standardization. If you really could get all the software to run in a browser you could even just roll out something like ChromeOS, or give every employee a choice of what they want and have a support policy of reimage first, ask questions later.
The question is: How much does it actually cost them (in dollars) to support XP?
Probably no more than it would cost Ubuntu to support 4.10, which was released a full 3 years after XP, and de-supported 7.5 years ago.
Look, I love Linux as much as the next guy, but I don't think absolutely complaining about the length of MS's desktop OS support has a leg to stand on. MS supports their desktop OSes from 10 years after the next version is available - they don't even measure from date of first introduction.
What other OS releases from 1999 still get full security backports? I can't think of one. XP is STILL supported today (goes back to 2001), OSX only goes back to 2007, RHEL goes back to 2007 (though they promise that the current release will get 13 years, which is comparable to Windows), and Ubuntu promises 5 years now, but they don't currently support any desktop OS released more than 1.5 years ago (previous LTS releases did not get as much support).
Sure, it would be nice if XP were supported until 2100, but you can't really fault them for drawing a line SOMEWHERE.
More likely the FBI wanted to be able to charge anyone possessing or sharing it with copyright infringement.
Makes sense. A few more years of RIAA lobbying and that will carry a heavier sentence than treason or espionage.
Its purpose was to force insurance companies to cover pre-existing conditions.
Wrong. The purpose was to force people to hand over their money to private companies whether they want to or not. It's called Fascism.
Sure, 2/3rds of the country is screaming for healthcare reform because they really don't care about their health at all, but they just want to force you to buy insurance when you just want to be left alone and pay for your own bills and die as soon as you run out of money.
Or maybe it really is about getting rid of the ban on denial of payment for pre-existing conditions.
So, which form of health reform do you favor - one that allows companies to deny treatment for any condition they consider pre-existing (you can always sue them if you disagree), or one that does not allow companies to do this? If the latter, how would you do this without requiring everybody to be insured?
And if you want to tell me that you don't favor health reform, then I'll just tell you to have your favorite candidates win the election next time.
You can't have your cake and eat it too - retroactive insurance just doesn't work. Insurance can only work when there is a known risk but an uncertain outcome. When you know the outcome, then there just isn't a market for insurance at all. What is the free market for people paying you $10 so that they can immediately hand you $100 in bills for you to pay for them? No country in the world operates this way - whether healthcare is public or private.
I'd say that it is appropriate for the government to regulate both, but for different reasons.
It is appropriate to require car drivers to have insurance because the risk of accidents is relatively high, and that means that others are likely to be subject to losses for which the driver is liable but unable to pay. Insurance is mandatory to protect everybody else from you.
In the case of health insurance it is a bit more roundabout. We want to protect everybody from false claims of everything being a prior condition, so we want to ban companies from making that claim. Then in turn we end up having to protect companies from people really having prior conditions and making the company pay for it. So, it is more of a compromise.
Government has decided that it is a bad decision for people to not purchase health insurance. I know many perfectly reasonable, rational people who did not purchase health insurance before the ACA because it was not worth it to them.
The insurance mandate wasn't created to force people to buy insurance, though obviously it has that side-effect. Its purpose was to force insurance companies to cover pre-existing conditions. If you force companies to cover pre-existing conditions and you don't force people to buy insurance, then everybody signs up for insurance in the ER and cancels as soon as they are discharged, and the entire industry collapses (whether public, private, or whatever - though public insurance usually is tax-funded and thus everybody is forced to buy it).
Disallowing coverage for pre-existing conditions sounds good on paper - it is how every other insurance system works. The problem is that health insurance isn't like car insurance. If you car looks like it was in an accident, chances are that it was in an accident, and the police can tell you exactly when that happened and it is obvious whether the car was insured at that time or not.
Now take somebody who has a heart attack a week after getting insurance. They might have keeled over with insurance, but that plaque in the arteries has been forming for years. We don't even know what causes that plaque to form, let alone when that chain of events started. On top of that you get sleezy insurance companies that will dig back 10 years and find three days that you were out of work and uninsured 8 years ago and argue that you must have eaten a cheesesteak on one of those days that kicked off the whole chain of events and deny your claim.
Denial of pre-existing conditions is the cause of half the mess that is the US insurance system, and nobody wanted a new system that kept that feature in place. That made an insurance mandate unavoidable from the start. The only question is what form it took. If there were a public option then the mandate would come from the fact that taxes are mandatory - even if you don't sign up you're effectively still insured because you're paying into the system.
In fact, one of the biggest problems with Obamacare is that the penalty for not signing up is too low. It is cheaper to not buy insurance than to buy it, and thus the incentive to sign up in the hospital still exists. The penalty should be substantially higher than the cost of buying insurance - thus creating a fund that can pay for any bills incurred while uninsured.
A stock certificate is an asset.
How much capital gains tax did Facebook pay to the IRS when they created $90B in stock certificates that didn't exist the instant before the IPO? I doubt they had to pay capital gains on issuing stock. Those who bought and sold it, of course, had to do so.
Why wouldn't bitcoin be any different? The person creating the bitcoin is creating an asset, not buying/selling one.
In the US, To be taxed at the lower rate, it must be classified as "long-term" - I.e. the asset must be held for at least a year before it's sold. Other (short-term) gains are taxed at the same rate as income.
Isn't capital gains tax charged on the appreciation of an asset from the moment you acquire it to the moment you sell it?
If you mine a bitcoin and sell it immediately, then the capital gain on it would be zero. You would only have a gain if you bought the bitcoins from somebody else. That is of course how many bitcoins are acquired.
I'm not suggesting that a plane couldn't be remote-flown effectively, or that the autopilot isn't capable of doing nearly everything. I don't think any today are capable of doing the takeoff roll on their own, and some essential controls like flaps/etc aren't controlled by the autopilot. Also, I don't believe that most aircraft can handle the necessary mode changes, like moving from following path navigation to switching to a CatIII ILS. There is no reason that couldn't be changed, but there would need to be a few changes.
However, the way aircraft actually operate you'd still need about 2 people per plane at certain points in the flight to be safe. You could certainly have them only control the aircraft at critical points and have them take care of other aircraft while they're in cruise/etc with just occasional check-ins.
The autopilot is perfectly capable of following the programmed course all the way to the ground. The reason you need about two people managing the autopilot is that this planned course can't always be predicted before takeoff. If the crew gets the correct news on approach/runway while they're not too busy before decent then they can take their time programming it into the computer and one person wouldn't have any problems keeping up. However, if the winds shift, or ATC has to deal with traffic, or whatever, and during approach the pilots get directions to switch to some other approach/runway then there is a huge pile of time-critical work to be done. The airplane is moving forward at 250kts (that's more than a mile every 15 seconds) along its previously planned route, the crew has to figure out where the new route is in relation to the current one and how to transition from one to the other. Often the crew will just put the plane on a manual course or direct-to course just to get it moving in the correct general direction while they program in the rest of the course. Anything that gets programmed in needs to be checked, because there could be clouds and mountains and buildings in the area and you don't tell a plane to go anywhere without making sure it is absolutely correct. If there is doubt the pilots might need to do a climb to the regions minimum safe altitude - charts indicate heights that are guaranteed to be free of terrain/obstructions with room for safety so once a plane is above that altitude the only issues are time/convenience and running out of fuel (assuming weather doesn't require the plane to try to land sooner).
A few crashes have happened as a result of pilots not managing changes during critical segments of flight.
Not all of the factors that lead to last-minute changes are preventable. Better automation could probably reduce the impact of traffic, but nothing can prevent a storm from moving through, or winds from changing. So, even if remotely piloted a plane will still need 1-2 people paying attention to it during critical phases of flight. Now, those people probably won't be looking out the window or handing yokes - they'll probably be sitting at computer terminals and touchscreens and such. In fact, route planning/entry/verification could probably be done more effectively from a console designed expressly for that purpose vs a cockpit designed for direct manipulation of control surfaces.
There are also a lot of good concepts like no-lights-is-good - when you first power on an aircraft you see a LOT of lights. When you're in cruise the entire panel is basically dark aside from the autopilot mode indicators and the flight instruments (map, attitude, alititude, speed, etc). On some aircraft even some common autopilot functions (like autothrottle and yaw dampening) are only lit if they are off, because they're almost never off (well, unless you want to crash into a jetty at SFO - and I don't think the 777 is one of those lit-if-off autothrottles). On an airbus the autothrottle isn't even a toggle so much as how the throttle control behaves.
That is also why PC fight simulators aren't really that practical to use unless they're full of "cheats" or you make heavy use of the pause button. You really can't keep up with an airliner landing workflow with a mouse and keyboard and joystick the way you can if the radio actually has a dial on it or dedicated keypad. Even the jets aren't designed to be flown by a single person (though in a non-emergency situation they probably could be at a higher risk of missing something important).
Except we've all seen evidence of PhDs having an awesome theoretical grasp of something, and absolutely zero practical grasp of something.
I'd argue that being able to design an engine and being able to drive a truck are really orthogonal skillsets. Sure, there is some overlap in the basics, but you could be really good at one and not at the other. You could also be good at both, or neither.
Perhaps one of the key skills for a successful truck driver is the ability to maintain attention through many hours of relative boredom and then be instantly at-attention when something goes wrong. That doesn't seem like a skill that has anything to do with the ability to do engineering/science/etc. Maybe back in the days when scientists counted shooting stars or scintillations manually it would have been a bit of a closer fit.
Most businesses in the US are surprisingly competitive - it isn't really trivial for anybody to just walk in and take somebody else's job, no matter how easy it might seem. Ever watch the Top Gear episode where they try to figure out how to work the tractor?
I never claimed that Nokia had assets worth $3.6B in India. My intent was simply to explain that if the parent post's assertion that the tax was based on the factory value was true, then Nokia really couldn't just walk away. I was faulting the deductive logic of the post I replied to, not affirming the premises the argument was based upon.
"Probably" means you don't know what you're talking about.
No, it simply means that I don't make wild assertions without fully checking the facts, like telling you that you don't know what you're talking about.
I'm only aware of one or two cases in the last decade where somebody might have gotten indefinitely detained on US soil (the shoe bomber comes to mind). I'm not sure there are actually any cases of actual indefinite detentions. I think the US government has been charging anybody caught on US soil. However, I could be wrong.
If I am wrong, well, you could be helpful and provide the stats.
The fact is that you're FAR more likely to get kidnapped if you go visit someplace in South America than you are likely to end up in Gitmo if you go visit Chicago. In fact, I'd say you're probably more likely to end up in Gitmo if you go to South America than if you go to the US, because the US uses Gitmo to house people caught outside the US to avoid introducing them into the US justice system.
Well, my whole point was that you were less likely to get kidnapped on US soil (or in the EU) than in some random third world country. So, I'd consider it relevant whether the US does the aforementioned abductions on US soil or not. You're more likely to end up in Gitmo if you're outside the US than in it.
My post had nothing to do with whether this practice is right or wrong.
Unless they might be removed from office by a different branch of the government.
By "government" I meant the totality of government, not some random representative of it.
I'd be fine with just banning retirement savings as an employment benefit entirely then, or (gasp!) simply making it a government benefit. Though, if it were a government benefit I probably would substantially raise the eligibility ages, and I'm also for more benefits for people who are between jobs (the nature of the society we live in makes it hard for everybody to be employed).
In the US, failure of 401ks is usually not a problem. The issue of investment risk/planning certainly is a problem, but not disappearance of the funds themselves. There are never "shortfalls" - they are just bank accounts and the statement reflects how much you hold. I'm sure there are lots of disappointments, but the balance reflects the performance of the investment. A shortfall implies that there is some targeted amount of money that should be in the fund, and with 401ks there is no target.
For the most part they tend to be invested in mutual funds, which publish a daily NAV which is nothing more than the total money held by the fund divided by the number of shares. Unless there is fraud that always works out. If there is fraud virtually all mutual funds are SPIC insured.
Pension plans are an entirely different story. Shortfalls often exist, since they are often defined-benefit. If the company goes bankrupt the pension gets lost, and anybody who worked at the company for the previous few decades takes the loss. That's why I consider 401ks to be superior to pensions. I'm the first to agree that they have their own issues.
My big issue with pensions is that they're a form of false advertising. A company gets you to work today for less income because they dangle a promise of more income in the future. However, that's really just an investment of a different kind. Sure, investing in mutual funds carries all kinds of risks, but the current state is that people invest everything in a SINGLE company, and one that happens to be their employer so that if it goes belly-up they end up like the employees of Enron. (Oh, on that note I would ban requirements that 401k funds be invested in company stock.)
Look, I'm more annoyed with the civil liberty issues in the US than most, but you're stretching things. The US government probably has only detained a few people indefinitely on US soil in the last decade, and while their treatment is clearly unconstitutional they didn't exactly have clean hands. On the other hand, in quite a few countries out there you run a significant risk of being kidnapped and held for ransom simply for looking like an American. The risks are not comparable.
Ditto for power reliability. Ok, so the US had a big blackout for a few hours 10 years ago, and California had a self-imposed series of blackouts about 15 years ago. I'd also agree that we're really pushing the limits on capacity such that we're at risk of some major problems. However, in many regions in Asia you can count on the power going out almost daily for hours.
I won't claim that Walmart workers are well-treated. However, they certainly are much higher-cost than workers in Asia in absolute terms, which is all the company paying them cares about. There is a big difference between $7/hour and $5/day.
Ok, so you have $10k in a bank account in Peru. You want to transfer the money to your account in the US. The bank says that before you're allowed to move the money you have to pay a $500 tax to the government.
The new tax is $3B. The old tax is $300M. The factory is not even worth $300M. Your analogy is silly.
I'm just explaining the post you replied to, which stated, "The tax is on the value of the factory. The factory is obviously more valuable than the tax liability." If that statement is not true, then my explanation of that statement would not be true. I cannot personally vouch for the value of Nokia's holdings in India.
Sure, this is a shakedown, but it isn't like Nokia can just walk away. Most likely they need to bribe the right person, which is how business is often done outside the US/EU.
Keep in mind that what the US calls "EFT" and what the rest of world calls "EFT" is a bit like the difference between what kids listened to music on in the 80s vs today.
EFT exists in the US - it isn't the same thing as wire transfer.
There was a good NPR episode on this recently.
The issue is that the US EFT system (called ACH or the Automated Clearing House) is a batch-based system that involves several days (err, BUSINESS DAYS!) of latency. It was invented at a time when this was actually an advance over checks and back then literally involved transporting reels of tapes (as opposed to bags of checks). Today it works like you'd expect a more modern operation to work, aside from daily batching, shutdowns during off-hours, etc.
Banks have opposed improving the US EFT system, in part because it would cost them money to implement any changes, but mostly because they can make a fortune charging for wire transfers when you don't want it to take several days to send money around. Wire transfers usually take seconds, like ordinary money transfers anywhere else, and they cost tens of dollars each.
I do pay my bills electronically though via EFT. It just takes a day or two for payments to get through (and sometimes it takes a week if the bank actually does have to cut a check).
Why not just use digital cash - the kind that was invented back in the 90s. That is completely anonymous and untraceable, but it relies on having a bank that issues the currency and then deposits it when it changes hands. Like cash it can be stolen though - it really IS anonymous and untraceable so don't let somebody else get a copy of your money or you'll find it spent when you go to spend it.
Yup. If you don't mind trusting a central authority then there is a completely anonymous alternative to Bitcoin and that is digital cash.
It is a sound technology rooted in crypto that has been around for ages. It allows a trusted bank to issue currency that can be freely exchanged in an anonymous fashion online and then redeemed back with the bank. That is, the bank could give me a string of bytes worth $10, which I could then use to give you a different string of bytes, and then you could give the bank that string of bytes and get $10 deposited into your account, but the bank would not be able to tell where that string of bytes originated, but they could be sure it is authentic.
For whatever reason I can't find a good description online. The concept is that the individual actually creates the currency and encrypts it, and then the bank signs it blindly to make it authentic. The signature is such that it remains valid if the message is decrypted, so the currency can then be used without the bank being able to associate the currency with what it signed. The obvious weakness is how the bank knows what it is signing, and that is done by having the currency creator issue a large number of identically valued pieces of currency, and then the bank asks for the decryption keys to all but one of its choosing. If the currency it verifies is valid then it assumes that the one it couldn't read is valid and signs it. There is no real chance of getting away with forging money as a result (the bank could ask you to generate a million $20 bills and only sign one of them, so you'd have to guess which of the million ones to forge and there would be ramifications if you were caught doing it).
This is much more anonymous than Bitcoin - it works just like bills in circulation. However, it relies on a central bank, which can issue all the currency it wants to. It is superior to cash in most ways, but it isn't useful for offline transactions, because currency can be copies and only the first copy that makes it to the bank is valid (so be sure to deposit that cash before calling the sale done).
No objections there.
The irony is that despite the fact that contracts for the sale of real estate are registered in my jurisdiction, we still have to pay for title insurance in case the government's records aren't correct. It would be trivial to switch to a system like Australia's (the databases already exist), but for the loss of income to the insurance companies, and to banks who find their loans refinanced more often due to the reduction in closing costs.