Yay for you. You were so smart reading, writing, and doing long division at kindergarten age. If only everyone else was so brilliant.
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.
Its not natural or obvious how to use the three seashells. School is there to teach that.
That's rather my point. My school managed to teach all of us those things, what's wrong with schools in the USA?
The hotel with only wired in the room.
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
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.
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?
Yeah, the old aerodynamics was pretty horrible. Add a nosecone to your blunt-tipped rocket and it increases the drag? What kind of logic is that? It needed to be fixed.
There's a couple balance issues I'd like to see fixed, mind you. For example, it's possible to make small solar ion-powered aircraft in Kerbal. But only small ones, because all of the ion engines available are tiny, and all of the fixed solar panels are tiny, so while technically it's possible to make bigger craft, the necessary part spam makes the game unplayable. Fuel for ion engines is also absurdly and unrealistically expensive for no obvious reason. Yet solar panels and RTGs produce orders of magnitude more power than they should for a given size, if ion engine power to thrust ratios for a given ISP are used as the baseline.
Drop xenon costs, tweak power production / consumption for existing hardware, and add in nuclear reactor power sources (after all, they have nuclear rockets, we know kerbals understand nuclear physics), and and you could balance that out pretty well in terms of both gameplay and at least slightly more approaching realism.
(Note that one may be tempted to say that the ion thrusters are far too high power, but at least that's plausible if we assume that they're MPD thrusters with some type of advanced cooling system - you can get crazy power to weight ratios (by ion standards) out of MPD thrusters if you could somehow supply them many megawatts of power and dissipate all the waste heat - they manage it in pulsed mode, at least. But Kerbal's solar panel area-to-thrust ratios at the given ISP are not even close to being compliant with the laws of physics)
I found the commenter who posed this as a response to RISC-V interesting. The University of California at Berkeley has a completely public implementation, under the BSD license, without patents filed, which your effort appears to be positioned against.
It is a time-limit on damages, which is not the same thing as a time limit on lawsuits. There is still the potential to restrain an infringer who started 6 or more years ago from further infringement through the courts - and totally kill their business - even though damages for the infringement can not be recovered. And you can sue any other infringer.
I love how true that all is. You have Musk making Kerbal references in his tweets. I've seen engineers from SpaceX doing likewise. I was once chatting with a researcher working on a Titan probe concept and he responded at one point with something like, "Well, like what one experiences on Eve in Kerbal Space Program...."
The development team really should be proud.
It's not clear what version of the MIPS ISA they're implementing (the article I read just said MIPS32, which covers a whole range of things). It sounds like it's MIPS32r6, which is not backwards compatible with any previous MIPS version. The only value of MIPS over something like RISC V (which is increasingly the standard ISA for computer architecture research) is that there's a large body of existing software for it, so you can do real evaluation.
We've done a clean-room reimplementation of MIPS III (R4K compatible) implementation in BlueSpec, which is a high-level HDL. MIPS III and the R4K are over 20 years old, so any architecture-specific patents will have expired. In comparison, this core is only 32-bit (really not interesting for research) and is written in a low-level HDL (making the kind of invasive changes that you want to do in research difficult), and is an ISA that has very little software support.
Any suggestions on that FPGA board?
We use the Terasic DE4 for most things, but it's insanely expensive - definitely only a board to use if someone else is paying. The SoCKit is quite nice - much cheaper and has a dual-core ARM board. We've ported FreeBSD to the ARM (adding devices for programming the FPGA) and our MIPS-compatible softcore to the FPGA, with virtio communicating between the two, which makes it easy to play with heterogeneous multicore. It's mainly intended for prototyping accelerator cores and there's a fast cache-coherent interconnect between the ARM cores and the FPGA so it's quite a nice platform to play with if you want to try and offload computation to the FPGA. It's a fairly small FPGA by modern standards, but still big enough for our CPU, which is a 6-stage in-order pipeline with caches, TLB, branch predictor and so on.