The story said jack crap about Hydrogen storage for fusion, in addition, we don't have a method at the moment for using Hydrogen fusion as an energy source.
I like your bit about nuclear weaponry (sic), the reason we use it as oppose to, I dunno, Lithium, just something out of the air here, is because it is simpler and therefore easier to build a detonation device out of. Not because we feel that we're going to get more bang per buck with Hydrogen. When it comes to leveling cities, cheap and effective is favored more over costly and unsure.
Another thing, even if we used Hydrogen for energy in the fusion way of things, it's still pretty shitty compared to say Helium or Boron, wild guess as to why Einstein,
Finally, basic high school chemistry would have taught you JACK SHIT about fusion since that's not fucking chemistry!!! Please feel free to educate yourself about the difference between nuclear physics and fucking chemistry. You have an awesome rest of your life.
The whole point of Wayland, and I could be wrong on this one, is to avoid the mistakes of X. From your solution, we just go back to the days of hack around the core.
The core protocol is flawed and the project shouldn't be afraid to make some sort of shift when there is a pretty good reason for that change. If dude was purposing change for just change sake, yeah I would get it. But the protocol doesn't implement basic window management within the core, and makes it insanely difficult at the plugin level. I, for one, think dude has a point.
That is exactly what happened to X. Everyone was afraid of changing the core protocol, afraid that it would break older stuff. Look where that got it. About a bazillion extensions. At some point backwards compatibility breaks the baker and I know that is hearsay in the OSS community. I know there has been a lot of boneheaded change for change sake forks, but I really don't see this as falling into that category.
Depending on the logic, it may make no sense to the system to go into neutral at 125 MPH or to turn off the system. Worst yet, the whole thing could have just killed over completely. So requests being sent to the dispatcher never even make it. The only thing in these kinds of situations that's going to work is a hard reset, which regrettably they don't tend to build one of those buttons into cabin of a car. So the only solution is to pull the plug... Which is located under the hood.
Maybe someone could pull a Keanu Reeves and slide under the moving vehicle? Unplug it from there?
It's like your car is saying, "I'm sorry Dave, I'm too busy pushing the accelerator to process your request to shift into neutral, please try again later."
Going into neutral with the gas pedal down is going to trigger an ignore signal from the system and thus the request to switch into neutral will not be dispatched to the transmission. Likewise with ignitions, having forward motion in a non-collision situation will have any request to disengage the engine ignored. Heck, some electronic systems won't care. If the car isn't stopped, collision or not, the system may very well ignore any request to disengage the engine.
The problem is that a lot of these drive by wire systems make a lot of bad assumptions about things and there really isn't a standard guide book on what to make sure does and does not happen, so it varies pretty wildly between systems. Some cars will allow you to switch to neutral, and neutral alone, while the gas pedal is down (never mind that the system is having a fault on requests to accelerate.) Some cars will let you burn through the break pads. The parking brake is always manual, so you'd figure someone would put a kill switch in there. Nope, pulling on the parking brake with the accelerator stuck will just get you some nice brake dust blowing out of your wheels. There are a ton of WTF thinking that goes into some of the programming of these systems.
Stuck accelerators can be cause by any number of faults, some of those faults are checked, some not. The ones that are checked, can try resets or allow you to stop the car safely. The ones that get missed cause this kind of crap where, no matter what you do, your car is now programmed to go as fast as it can in a forward motion and getting under the hood and pulling the plug to the system for a hard reset is the only solution.
There is a serious need for someone to come up with logical standard operating procedures for these types of systems. Airplane manufactures do it for their fly by wire systems so that the pilot always stays in control, even when the system would rather beg to differ on the matter. I haven't the foggiest idea on why this kind of thing eludes car makers.
It's just too time consuming to find the right spot on an Excel fill it out and even then you might have validation issues. A web system that handles all of that is a much more efficient method for a lot of reasons. Validation, central administration, version control, wide distribution, wide consumption, etc...
However your argument still doesn't change the main thing I covered. You still need your desktop people to make and review your forms you fill out. There still is a whole process for review which is most likely done on desktop, and so on. If your form is genetic enough, which that depends on the level of complexity you have in the sheet, the look is less important that the collection of data. You could easily use some other office suite for your data entry. Again that depends on what you're doing here. However in a lot of the cases I've reviewed mobile Microsoft office could either be replaced with a web based solution or any old office software could be used in it's place, once people understood that the majority of content creation didn't happen on mobile devices.
Again I'm not saying there isn't a need for mobile office, it is just that a lot of the use cases I've come across could be better done sans office considering that mobile users are usually expected to flip something open, enter less than ten kilos of information, and be done for the day for what they are expected to do on a mobile device. If you're a college student and you're on a budget, then yeah if your class requires Microsoft Office that might be something to look into. If you're expected to build an entire Power Point presentation on the go and all you have is your iPad, then yeah if you have to share that file to someone on a PC, that might be another, but if you are the one giving the presentation, just plug the iPad to the projector via wireless. There are plenty of options for this.
Your data shouldn't rely on an underlying presentation platform, if it does, you have an inherent problem with how you store and collect that data that leads you to such vendor lock in as to require Microsoft Office to be a make or brake call in your mobile strategy. Mobile platforms require some sort of liberation of the connections because there are certain calls you can't make in a BYOD environment.
Office doesn't offer a ton in the way of content creation on mobile devices. Trying to use Office RT is just a waste unless you really have the little snappy keyboard and at that point, I rather be using a laptop than a mobile device. Unless something seriously changes in the Office UI department that can make the software more usable on a mobile device, I'll stick to the free stuff on Android (which granted, Google is seriously fucking up on delivering anything above pure shit on the Android platform for office documents) or iWork on Apple devices (which thus far has been the only serious productivity software for mobile devices, which is a shame because it's feature set leaves a ton lacking.)
I'm not saying that there is no need for productivity software on mobile devices, just saying that every vendor thus far has yet to produce something that is really going to be the tipping point that says, Damn it! I've really got to get MS Office/Google's Paid Office/iWork on my phone!!!
The most common thing I see is mobile users relying on desktop users to build the sheets from ground up and mobile users, adding bits of information as they go. If a large amount of information is needed in a read-only environment, convert to PDF is the number one thing I see desktop users do for mobile users. They can markup and annotate the PDF and send back to desktop users for review and change. Because all of this "works," there just isn't the same value for MS Office on Mobile as it has on Desktop. Hence, Apple would be at a serious disadvantage paying Microsoft to port it to iOS, they'd be getting very little in return. Someone at some point has to figure out how to give mobile users enough freedom that they don't have to keep going back to the desktop to build a document, without it taking an act of Congress to actually build.
You may find yourself pulling up Qt Quick for implementing a "find dialog" or a "insert criteria dialog", but if you are writing the main window in Qt Quick, you either have a very modular/small project or you are using the wrong tool for the job. The best way I tell others is that Qt Quick is for doing up quick UIs, not complicated UIs. Qt Quick would be excellent for Palsmoids, horrific for an entire email application (unless you have really broken the program down to very small bits.)
As an example, I have a program that we use here in the office to connect to PostgreSQL. The connect to dialog is Qt Quick, the window with all the tables and fields is pure QWidgets. The fill-in-the-form order request window is Qt Quick, the order summary window is QWidgets (mostly because it has all kinds of sort and filter buttons). So keep the Qt Quick stuff small and simple and you will find that it's nice to use for all those one offs that do not need a lot of logic behind the window.
That is not to say that Qt Quick *cannot* do a large application, just that it will be easier to continue to do so with QWidget, and that is the whole point, to make things easier. Also, I strongly encourage you (and for that matter anyone seriously looking at Qt) to pick up some C++11. Qt 5 has been written to make logical use of some of the newer stuff in C++11 and those concepts do very much indeed make your code very, very clean. I will admit that I was quite skeptical at first about that point.
Coal miners, sanitation engineers and police officers get paid a lot more than their skills would demand because of the unpleasantness of their work.
I've not known coal miners to be making that much cash. In these parts they can stand to make $33,600 topped out and starting around $26500. So that's a spread of $12.75 per hour to $16.15 per hour, with the usual pay increase $0.05 to $0.10 per hour per year.
Additionally, I think you place very little value on their skill. Most miners are using pretty advance machinery which have complex displays that show gas concentrations, slurry input/output, core rotor tempature, coolant inflow, rotor RPM, and so forth. Most of the miners go to school for pretty much a two year degree for operations and a four year degree is required for mechanics.
This isn't the pick axe and cart operation that some like to think that is coal mining. Surface mining is a little less complex, but still more demanding that one would expect.
Yes, the people who have their jobs dislike that crap that they put up with day in and day out, but they don't keep going because the pay is super fat. I could tell you, but hell, come on out here to Kentucky, Tennessee, or West Virginia and see for yourself why they go in and out of a mine day in and day out.
I'm sure it will be enlightening.