I've had zero problems with MSOffice compatibility. Admittedly, there may just not be a huge amount that I am asking of the program, but I generate simple documents and send them out as .docx all the time, and I don't get any complaints. Nor do I see that they're misformatted. Likewise I load MSOffice files, both Word and Excel, on a pretty regular basis. I've had zero word problems recently, and the only problems I had with Excel files were some very oddball macros that just didn't make it over correctly.

I'm not an LO fanboy by any means, I think its got some pretty annoying issues, and it certainly hasn't kept up with all the newest features of Word, but OTOH I don't need any of those features! Its a solid program for doing fairly basic stuff like letters, resumes, cards, and similar stuff. You can do a 100 page document if you don't care about any elaborate features either, though I am happy to admit it isn't the best tool for that.

I still find LO Writer to be utterly bug-ridden. It screws up styles and page formatting with dismal regularity, sometimes in unrecoverable ways. Its OK if you're writing small documents, letters, etc. If you want to write anything large or with anything more than the most basic sort of formats, you're better off looking at a DTP program, Writer is NOT your tool.

Calc is OK, but its VERY easy to crash. The data range functionality is buggy as all heck. Often its literally just impossible to declare some range or other, the program will simply crash with 100% regularity. OTOH it works pretty well in every other respect that I've needed.

I can't really say much about the other components. The illustrating package seems to do basic stuff OK, but I've rarely done anything challenging with it. Again, if you really want to do anything elaborate you're going to want to use something like Inkscape or one of the Adobe products.

Its a free program, I'm certainly not complaining. If you are willing to suffer some inconveniences you can do a lot with it, but IMHO I'd MUCH MUCH rather see the LO team focus on killing bugs in basic low level functionality than adding fancy new features that I'm unlikely to use if just basic 3 level hierarchical sections, paragraphs, tables, and simple text frames are so buggy.

Yeah, I can respect Ron Paul. I think there are some fatal flaws with the whole Libertarian concept of government, but honestly I find it frustrating when many people assume that being somewhat 'to the left' means a lack of respect for basic rights. I think Bernie is actually pretty good there. Opinions can differ on what exactly is most important in that realm. Its just unfortunate that the Ron Pauls and Bernie Sanders of the world seem to be painted as opponents and not allies. That may change.

Yeah, well, she's obviously highly intelligent and at least modestly open to actual evidence-based reasoning. One would have to believe she's the infinitely preferable choice between those two. Thus Sanders endorsed her. One has to understand, Bernie is a VERY pragmatic politician. Many people confuse his strong ideological orientation for the type of rigid inflexibility that buffoons like Ted Cruz exhibit, but nothing could be further from the truth. He's determined that he's not going to further his agenda at this time better in some other way, so he's going to push for Clinton's election. He'll still be a Senator, and his seat there is UTTERLY secure. I expect he'll be forging some new political alliances, and he's got a BIG push on now to get real progressives into both state and national elected offices. Its a longer-term strategy, but that's what needs to happen.

Meh, everyone at the higher levels of government is a 'violentist', they ALL believe that the logic of force is the logic of human relations. Now, maybe Sanders is (to an extent) an exception, but the point is Clinton is hardly any more warlike than any other president the US has had in the 20th Century. So it is hardly a big giant evil label to put on her, unless you're interested in indicting the whole executive branch, all of Congress, etc. I'm just saying, that's a bridge, or 10, too far at this juncture. I'd love to see a Sanders in place who would absolutely go to a last-resort policy on using force, but that does not mean he'd never use it. Truth is US policy is not just invented whole-cloth by each President.

Well, we can't say for certain where Clinton will go with AGW and such things, but she's shown NO interest. There's zero indication that she will make even the smallest political sacrifices in order to further climate negotiations or put in place laws and regulations badly needed in the US. All indications are that instead she will maintain the existing status-quo, which if it goes on for another 8 years will utterly demolish any hope of bringing climate change under control without severe and likely near-catastrophic consequences (certainly extremely expensive consequences that will set back economic growth in the third world by decades, if not halt it altogether).

Remember? This is the guy who advocates replacing the Republic with some sort of crazy dictator/king/something. Well, he sees an opportunity for it to happen, because if Trump is elected? There won't be elections anymore. Not in the way we think of them now. They'll be rigged sham affairs more like what goes over in places like Russia. THAT is what he's behind. Not that he probably thinks Trump specifically should be in charge, but once you've ditched the reality of people having a say in the system then guys like him with loads of money figure they'll rearrange things to suite themselves. Its a rather vapid fantasy, but there are fools of all stripes in this world.

As someone who's actually KNOWN Bernie Sanders (to the extent that I've lived in Burlington when he was Mayor, met the guy, argued with him, etc, I don't have any personal relationship with him) for 30 years, and greatly appreciated what he's brought to national politics in the last year or so, I believe this 'Sanders supporters hate Hillary' meme is mostly bunk. There may be a very vocal minority of people who became 'Sanders supporters' suddenly in the last 6-12 months because it was fashionable and they yell and squawk about how much they 'hate Hillary' because that's apparently fashionable too.

See, I would draw a huge distinction. I dislike the ESTABLISHMENT, and all the dirty tricks that the powers which be have used against Sanders IS galling. Clinton is ABSOLUTELY a pillar of that community. OTOH if you look at her in terms of an actually realistic view and not the bizarro-world distorto-vision that FOX News and etc have created around her, she's a relatively center-left candidate with fairly conventional views for a President. Nothing is going to change vastly, but its likely she'll implement some modest policy changes and programs that are part of the agenda for more left-leaning people. In fact she'll probably continue largely in the same vein as Obama, with increases in the minimum wage, labor-friendly policies outside of trade, some expansion of publicly funded healthcare, and otherwise she's probably closer to Nixon than to say Kennedy.

The bad things will be the environment, which Clinton seems to have little interest in at a critical juncture, and the military-intelligence-police-industrial-state that seems to have been building itself under every president of the last 70 years happily regardless of what policies they supposedly espouse. I'm not even convinced a President Sanders or somesuch could change those things.

Any given model and set of assemblies of a common household item is going to be produced in large numbers. Yes, in all, there are undoubtedly quite a few different variations of microwave oven, but as I explained before, calling that 'most of the applications in the world' is hardly meaningful. Any differences there are purely "we used the 82455 UART instead of the 82-C455 UART this time" which hardly matters. I will let you in on a little secret, a LOT of the code in those things isn't assembler, its PL/M or similar vendor-specific stuff. Much easier to code and frankly nobody gives a shit about the performance of microwave oven code as long as it works.

Every time you fly on a commercial airliner you depend on code I had a considerable hand in writing. I've written large pieces of assembly language code. I'd say if someone is 'dropping into assembler because they can't get the compiler to bow to their wishes' they are either a crappy programmer, or they have a compiler that sucks. If you're writing OSes and such then you DO sometimes have a need to write some assembly code, but its not because the compiler won't do what you want. I suppose there could be other cases, perhaps when accessing functionality that is very specific to certain hardware, or that is very new, etc, but I've rarely run into that kind of thing myself. Particularly in this day-and-age there are almost always good libraries that deal with most of those issues already.

Well, Objective-C is irrelevant, its a language that was designed from day one to be compiled to machine language. Dalvik is also QUITE DIFFERENT from actual Java. While a LOT of Java source, particularly for straightforward and relatively static user-facing applications, will compile and work on Android, the vast majority of actual Java application code, backend server stuff running in JavaEE environments for example, that requires dynamic class loading, including security management etc, is not suitable for this kind of treatment. If you, as an Android developer, have gotten the impression that "any Java can be run on Android, its just a matter of APIs" this is a false impression. Likewise with other products like RoboVM. Its not that it cannot be done of course, as I said before anything is possible, but once you get to the point of basically reproducing ALL of the functionality of the JVM, dealing with validating bytecode, supporting code injection (necessary for any IOC container), etc then you've probably evaporated most or all of the benefit, since Java isn't exactly that far behind native code to start with. This is why AoT has essentially gotten little or no traction in the enterprise world. There are allowances in some JVM's to maintain JIT state between runs of JVM, which can deal with some issues of performance at startup, etc, but nobody is compiling these server-side apps down to machine code. Certainly not in any market segment I've been exposed to so far.

Well, yes, trivially JVMs are C/C++ programs and thus anything you can do in Java you can compile down to machine language, just like you can a C program. Truthfully though in many cases its not practical to do so because functionality depends on being able to reference the Java bytecode representation of the class for various purposes (as an example). Now, you could, TECHNICALLY, retain such a representation for each class within your code (assuming there's a bounded set of classes) and you could include an entire byte-code-to-machine-code translator to translate classes that are dynamically loaded, and on and on and on, but its obviously just ridiculous at that point. Thus MOST modern Java applications are simply not candidates for conversion not because the technology can't exist or doesn't (for the most part) exist, but because its simply not a good idea.

GC is only part of the whole equation with Java efficiency. A LOT of it also has to do with runtime optimization of code. Over time a JVM can make a lot of inferences and learn a LOT about code and make many tweaks that are forever beyond a static compiler. The JVM also has a perfect understanding of what parts of the code NEED to be optimized, something developers rarely experience in practice. There are still vast areas where much greater improvements can be achieved as well, such as locality awareness, which isn't currently a real strong point of JVMs. As the world shifts more and more back to a dumb client/smart server kind of processing model Java's efficiency characteristics keep serving it better and better (not to say there aren't even more advanced ways to get there, but Java is a very practical alternative).

I'm sorry, but its ridiculous to count Samsung Microwave model 333-X and 334-X, that run 95% of the same code and differ by one feature, and each factory rev of each one of those, which may differ by 0 or a few bytes of code as a separate program, that's preposterous. By that measure every single installed copy of the Linux OS is a separate program since they SURELY link to a unique subset of all the possible libraries out there, use different libc's, etc etc etc. This kind of counting is utterly bogus.
You have to understand that when you say "small applications" you are talking about a VERY VERY small class of applications, ones that compile to no more than at most a few 100 or perhaps 1000 bytes of code and contain a few hundred instructions. ANYTHING more extensive than that is not human-optimizable to the level that a compiler can achieve. Frankly its just infeasible and not cost-effective to attempt full hand optimization of larger code bases, and anything less will fall short of what the best compilers will do. Understand, I say this as someone who has written a great deal of assembly language code, assemblers, real-time applications and system code, etc. I also wrote FORTH compilers which performed both local and global optimizations on performance-critical code. I have a good idea how this stuff works, even if I'm not really involved in the area currently. I can certainly put out some VERY good MC68k code, but I know for a fact that the best commercial compilers, starting in the early 90's, began to exceed our ability to do it faster except in very small sections of code like interrupt handlers.
I worked extensively with PASC FORTH and OS-9/68k back in the day. We did lots of very cool stuff and a lot of that code (the entire OS and much of the compiler) were written in hand-coded assembler. Now, go look at the history of OS-9/68k, which is a high performance Posix-oid RTOS, and you will see that it was replaced in the mid-90's by OS-9000, which is entirely written in C, and was at the time equally fast, and is now MUCH faster (presumably, nobody even bothers with OS-9 anymore). I'd note that even in OS-9000 certain sections that handle clock ticks, basic interrupt controller handling logic, and some other bits ARE still assembly. Those are bits that are SMALL pieces of code where a human can consider every aspect of execution and, if you are a real deep subject matter expert on the specific architecture, eek out enough clock cycles to make it worthwhile. Other than that? You'd just make the bulk of the OS slower if you tried to code it in assembler.
I'd note that OS's like OS-9000 (things like VxWorks for instance) are embedded in all sorts of things. Many appliances, many commercial spacecraft, aircraft, industrial systems, etc. Truthfully, THESE are the super common things, because each one REALLY IS unique, or close to it.

In what world are 'the majority of applications' written in assembly language? This is the rankest fantasy. The vast majority of all applications are running on vast server farms in huge data centers. The other vast majority are running on desktops, laptops, tablets, and phones. Another vast category are running on relatively highly capable embedded devices that run on 32-bit microcontrollers, of which a PLETHORA exist based on either MC68k (FreeScale CodFire, Dragonball, etc), or various low-power iterations of ARM processors. The amount of stuff running on little 8 or 16 bit controllers is, in terms of running code and instructions actually executed, trivial. Yes, there may be zillions of copies of toasters and microwaves out there, but to imagine that they are 'most of the applications' running in the modern world is ludicrous.

You're correct, C itself is simply a way to tell a compiler to generate SOME SORT of instructions that accomplish X. If X is possible in environment Y, then C COULD be used in that environment. Practically speaking you could take a compiler that targets your instruction set, use a libc version with that and a cstart.o with that which are tailored to the specific environment and do what you're suggesting.

Of course in some very resource constrained environments that MAY not be worth the bother, and optimizers are certainly less effective when they have very few options to choose between. It may also be that in many cases only a small subset of C constructs CAN be effectively translated to a really limited environment.

So, there's a SMALL set of cases where you may have no choice but hand assembling code. These are going to be extremely resource constrained. Things like embedded sensors that run on ambient power (thermal, vibration, etc) or the energy of a wi-fi signal they're picking up. This is where you get into nano-watt power budgets and 'processors' that have only a couple registers, a few dozen bytes of RAM, and a tiny amount of ROM. Usually their ONLY function is to do some Analog to DIgital conversion and dump the results in a fixed format to a radio or other similar interface. This kind of 'code' is really just replacing a bunch of custom fixed-function electronics with a very basic progammability for design flexibility reasons. No real decisions are made in code, etc. These days anything that incorporates any significant control laws, etc is going to be on a control system that's talking to such sensors, and that will be in 99.99% of cases at least a 16-bit controller. Heck, embedded military systems all went 32-bit 20 years ago now. These things are all programmed in PL/1, PL/M, ADA, or some other HLL.

There have been Java to GCC intermediate representation translators forever, basically since like 1998. The issue there is simply that many dynamic features of Java effectively can't be translated to machine code, so only a subset of Java is translatable. The other issue is that JITs are EXTREMELY sophisticated optimizers, much more so even than C compilers (because they can analyze the run-time behavior of the code and do on-the-fly optimizations AS WELL AS anything a C/C++/Whatever compiler could do statically). There are tools to dynamically optimize or simulate ASM/HLL code to achieve similar results, but they require a lot of expertise to use and cost developer time, and therefor money, to run. Java OTOH just does it.

In fact, in MANY cases, Java programs are faster than C/C++ equivalents. This is especially true for large, long-running, applications like servers and whatnot.

Beyond that, Sun produced a whole line of chips in the 90's that run Java byte code directly, so your JVM simply ran application code on bare metal and provided OS type services via in-VM implementations. I don't know if embedded Java stuff uses that sort of approach or exactly how they do it, but my guess is they have very lightweight runtimes that are simply compiled into a JVM. Its not as if JavaME requires some huge amount of OS functionality. It has to have some degree of 'file system' perhaps, but that can be a quite primitive affair that simply associates an InputStream with a name. Likewise they don't need to worry about many of the APIs at all, so the whole thing can be quite small, many functions like security managers and classloaders and such are just stubs, etc. I'm guessing you practically speaking need some sort of 32 bit processor, but things like FreeScale ColdFire+ and low power ARM based designs are now EXTREMELY low-end. There's still some stuff running old 8-bit and 16-bit 80's processors but those are getting fewer and further between. The only real exceptions are the ultra-low energy IoT stuff, remote unpowered sensors running on ambient power and such. Most of those are probably programmed in FORTH anyway.