There's a lot more politics to it than that. LibreOffice started as Novell's Go-OO fork, which contained things covered by MS patents that could not be upstreamed because the indemnity only covered Novell. They managed to spin it very well about wanting to avoid Oracle being in control though...

Why? It's not like people were using ion thrusters too much. Most people don't want to use them because you can't accelerate the game much with them on (which is IMHO pretty stupid, they could just treat the ion thrusters as a 10x more powerful thrust source and then only simulate physics on one frame out of 10 or similar... they're so low thrust that even that would be less likely to destabilize the simulation than nuclear rockets on physics time warp) (in that regard, I don't know why time warping doesn't just self-limit itself based on the amount of forces being applied to the craft... ). And the cost of the fuel is just an absurdity, it's neither realistic nor useful toward balancing gameplay.

If there's anything that needs to be nerfed it's the nuclear rockets, almost everyone uses them and they make the game far, far easier. I know it's hard to make a "realistic" nuclear rocket design with real world-ish thrust/isp figures that's not overpowered for the game; the reason they're not used in the real world isn't because of weaknesses in that regard, but because they're difficult to make and the public is afraid of them. So why not make that their weakness in the game? You could even up their atmospheric Isp and maybe thrust to a more realistic value... but make it so that for every second the rocket is being used, there's a tiny risk of a runaway criticality incident in the reactor (come on, we know how kerbals cut corners on engineering ;) ) that could lead to the explosion of the engine. That risk would deter some players from using them, while others would consider it an acceptable riskto the mission if low enough (perhaps one in every 10 spacecraft you send to Mun explodes in transit ;) ), and still others would design spacecraft to be able to handle the loss of engines via isolation, redundancy, etc.

I think it'd be good for both gameplay and realism - "Here's awesome cutting edge technology that we haven't quiiiiite worked out the bugs on!". Totally in the Kerbal spirit.

You might have chipped it, but you didn't scratch it, unless your walls are made of diamond or something.

Having a high Mohs hardness does nothing to prevent breaks; all it does is prevent scratches from softer materials. A substance can have an incredibly high hardness but still be very brittle. You can scratch steel with a piece of chert, but if you drop a big piece of chert and a big piece of steel out a second story window, only the former is going to shatter into dozens of fragments on impact.

As if they will give a damn any your regulations... If they did, they would be a proper taxi service.

States have these peculiar individuals who work for them known as "police" who throw people who explicitly violate their regulations a place called "jail", and possibly another one called "prison".

Uber will have to play by the rules or get out of state. Otherwise their drivers and Uber corporate itself will be heavily fined at the least every day of operation, and at worst, people will go to prison.

Uber is an international corporation with venture capitol investors. They're fine trying to circumvent existing law by playing around with weasel words, like calling themselves "ridesharing" when they're really a taxi service. But when there's a bill that targets them specifically, they're not going to be allowed by the police to just keep operating in that manner.

It's an entirely new ISA that is intended to be freely licensable.

There are 32-bit and 64-bit variants of the ISA (128-bit is coming). It also includes a variable-length instruction encoding (though currently all instructions are 32 bits) so that it's easy to extend (finding gaps in the MIPS opcode space can be challenging).

Really? Usually we want to use something for teaching that's easy to understand and modify...

Which you don't do with a simplified Verilog implementation. If you want to be able to easily modify something in an academic setting, then you want a high-level HDL, such as BlueSpec or CHISEL. BERI or Rocket fits this need a lot better that MIPSfpga.

Thanks for clarifying. There was nothing in the web page to indicate this (a fairly common omission on ImagTec blog postings, by the way).

I'm sorry, but that's complete nonsense. All of the branch-likely instructions were removed and replaced by the compact branches. These are emitted by gcc and are very common in gcc-compiled code (which appears to use them when it can't find an instruction to fill the delay slot with). Trust me on this - I spend a huge amount of my life looking at objdump output from MIPS binaries and instruction traces.

No you don't. You reused the opcodes, unless there's a newer version of the spec than the one I've seen.

It's hard enough to be scratchproof to the vast majority of things we encounter in our daily lives. Once you're harder than quartz and tool steel, there's not much you'll encounter in normal circumstances that can scratch you.

It's really not the spinel aspect that I find neat. It's the blurb about their process. They say they got it to work by two things: one, extreme purity (no surprise there), and two, mixing. No matter how well you try to mix fine powders together by any normal means such as shaking, you're never going to get a perfect mixture where all of the particles pack down together to their optimally dense arrangement. Apparently they've come up with a process that allows just that (they don't go into details).

Well, that's worth far more than spinel. Cheap and scalable production of materials comprised of perfectly arranged microstructures? It seems like such a thing could things in every field of materials science, from batteries to superconductors.

If, that is, it lives up to how the article makes it sound. TFA is rather high on hype and short on details.

I'm familiar with the Microchip implementation. This is a 300-MHz-class 32-bit processor. Not particularly modern and not really fertile ground for R&D.

We did have two or three suggestions from commenters of open MIPS processor implementations, some of which are more modern. One uses a proprietary high-level HDL, which I haven't investigated.

There was a study posted on Slashdot about this myth a few years ago. They concluded that Americans care more about their teeth because good dental care is expensive and so is a status symbol. Having few teeth is one of the stereotypes of poor/stupid people in the US. Middle class and aspiring middle class people in the US spend money on their teeth (cosmetically, at least) because if they don't then they look poor. For people in the UK, anyone can afford good dental care (for a while, it was easier for very poor people to because a lot of dentists weren't taking new NHS customers except under duress and people on certain forms of income support had guaranteed treatment), so going to the dentist is just seen as a chore and often slipped down priorities.

I was slightly ahead for arithmetic (but not by much), but I was at the very bottom for writing - to the extent that I was the only one having to stay in at break times for extra practice. This was not at a selective school (I started at one aged 7), this was at a school with a full mix of ability.

That's rather my point. My school managed to teach all of us those things, what's wrong with schools in the USA?

I keep a tiny wireless access point in my suitcase for these cases. Even with ethernet on my laptop, my phone and tablet don't have an RJ-45 connector and I don't always want to be using my laptop as an AP. Most hotel networks can't come close to saturating 802.11g, let alone .n.

I'm moderately associated with RISC V (the lowRISC people are upstairs and I'm in the acknowledgements section of the RISC V spec). The main drawback of RISC V currently is the lack of software. Krste claims that the cost of the software ecosystem for RISC V will be around a billion dollars. My friends at ARM think that he's underestimated that by at least a factor of two. I had a student working on RISC V this year (using the BlueSpec in-order implementation) and the state of the LLVM toolchain is a joke - it's several man-years of work away from basic functional correctness (he had to fix a number of bugs to get simple benchmarks to work), getting it to be as performant as ARM (or even MIPS) is a lot further out.

MIPS ought to have a big advantage there, but they've squandered it. MIPSr6 is actually quite a nice ISA (I like it more than RISC V), but it is not backwards compatible with MIPS I-V or MIPSr1-5 (yes, those are different. Just go with it), so they lose all of their software ecosystem.

Sadly, both processors lost to the dust, in the end. Back around 2005, there were a lot of people who couldn't spell dual though, and 'duel processor' machines were going for about half what people were paying people who could spell for 'dual processor' machines on eBay. It was an object lesson in the financial value of learning to spell...

Everything else in KSP has had months of testing (perhaps even years) and they change fundamental things like the aerodynamics model without letting it be tested by the established community?

But isn't that so in the Kerbal spirit? ;) Hmm, what's the coding equivalent of forgetting a ladder? :)