Here is one in less than 200 lines of python: https://github.com/s-holst/tinyrv .
It uses machine-readable specs from https://github.com/riscv/riscv-opcodes ; yet I needed to extract immediate bit scrambling from their LaTeX sources :). I wonder if there is an easier way. Anyways, the opcode semantics are hand-coded and it simulates enough to boot linux.
If you only want to simulate the core instruction, and perhaps the Multiply extension or so, and only plan to support single threaded operation, then the natural language spec ain't so bad.
Green cards are effectively entry-only passports (from the perspective of the US).
You can enter the country by land with just the GC with no passport. Additionally, if you arrive by air and you have global entry they don't look at your passport at all, just the GC.
They already dropped the MGU-H from the 2026 V6 engines in order to convince Audi and GM to enter as engine manufacturers since that component addend extra cost and had no applications in road vehicles so we can assume that they wouldn't have been thrilled to enter if they had to developed V10s now.
Yeah, maybe Ferrari had unlimited moneys for V10 development, but for Mercedes Daimler already is skeptical about the benefits of the F1 program, and Renault's engines just suck this season, and Honda left the F1 program in 2020 then decided to not leave just for Aston Martin but would have probably nto been the case had they needed to switch to V10s.
it's not trivial to do if you have multiple build targets and features
i.e. you would need to vendor one version for each features x target tripple combination combined with cfg expansion and (proc) macro expansion inlining and then a static reachability analysis to prune all unused code (and dependencies). That would likely not be good enough so you probably need to have some runtime code coverage analysis to find "likely dead code" (but not statically provable dead code) and then manual choices to keep/remove combined with some bisecting/testing to make sure the choices are sane.
You can get that info from code coverage, via `cargo llvm-cov` etc, though that would require exercising all code paths into the deps or else you might underestimate how much of the deps you need to vendor. But at least if you underestimate in this way, you'll probably just get a compiler error rather than anything breaking at runtime.
I have been spitballing about this recently too [1]. The way I'd imagine it would work is the toolchain takes one pass over your crate, compiles everything, then takes another pass to trim all the dead code from your vendored deps. Then your git diff basically has your code + all the lines of all your deps that didn't get trimmed.
There would probably need to be some more work to make it more user friendly, but I think it's really important that all the code which ultimately ends up in your binary goes in the diff otherwise reviewers won't actually look at it.
Disclaimer: I don't know enough about compilers, or the Rust toolchain specifically, to know if this is even possible or whether it would actually help anyone in the real world. But it seems "naively reasonable" for some definition.
This is commonly called the "tree shaking" [1] which is a particular mode of the general dead code elimination. One of main challenges would be the reproduction of somehow readable source code after the tree shaking.
I'm not expert on it, but I suspect that two of them might somehow be related to the Transmit and Receive stations for Australia's JORN (over the horizon radar) that are located in Western Australia near Laverton.
Though if that were the case, I'd probably guess there should be more areas at the other site locations around northern Australia - so that might invalidate my guess.
Ok, but let's acknowledge the difference between no data (depicted as no colored cell in the map) and data which reports high interference (depicted as a red cell). In remote western Aus we see a few red cells to the west of a large area of empty cells. So they do have ADS-B receivers there, and at least some of them are reporting a troublesome NIC, and there are enough reports for FR24 to place a colored cell there rather than an empty cell. Why exactly do you think that a red cell comes from no data or very limited data, when the article does not indicate that no data / limited data results in a red cell?
> Erm mate, have you tried looking at different days ? Those cells you find so suspicious in Australia are not there on other days !
That kind of disproves the "no data" hypothesis though, no?
One explanation could be they have a simplistic algorithm like "if uncertainty > (something indicating more than 5 minutes of GNSS-to-INS fallback) on more than 50% of all flights of a day", and there's only one flight per day in that region.
> Seriously, given the largely community-based nature of FR24 data I would not expect too much in term of accuracy.
Flightradar24 data is accurate enough for some commercial entities to rely on it. Also, in case of a lack of ADS-B receiver data we'd also expect a grey square, not a red one, right?
If green or "no data" areas randomly turn red sometimes, I'd expect to see them elsewhere in the world sometimes on different days as well. But I've checked every day that's available and I never see them appear in e.g. that big empty space in eastern Russia.
I don't really see any other evidence that low data areas can turn into red areas when there's no actual interference.
If I could get a really well sound-insulated 3 or 4 bedroom apartment, awesome, but it's either just too hard to find, or too hard to verify that it'll actually be quiet without some certification/guarantee.
With a SFH you can control your own destiny to some extent.
It's more effective volume wise. I did the math, some time ago here are the rough numbers.
Sand has way less heat capacity then water per kg (about half).
Water can be heated to 95C with standard unpressurized vessel. Sand in this application is heated to 600C.
Sand is denser then water (kg/m3).
For the same heat energy stored this comes out to about 2.5x more volume of water(95C) compared to sand(600C).
Water and Sand are both dirt-cheap.
Hot water can be managed with standard plumbing equipment.
Sand needs some high temperature piping (hot air to water heat-exchanger, resistive heat tho heat up the sand).
How well both contain the heat is primarily dependent on the isolation. Which favors the smaller footprint of sand, but needs to isolate a higher temperature difference...
One advantage of heating water over sand is that you can heat it up with high temperature heat pumps which currently have CoPs ranging between 2.4 to 5.8 [1]. So for every kW of electrical energy you put in you get at least 2.4kW of thermal energy out.
So yes, the volume of 95C water would be much greater than that of 600C sand, but if volume wasn't an issue you could do it much more efficiently. Alternatively, you could use battery storage for just the electrical capacity required and not the (much higher) thermal capacity which may be more cost effective when you look at the conversion.
The temperature also matters. If you need at least 50 C water to run district heating, about half of the energy stored in near boiling water cannot be utilized. This is much less with 600 C sand.
And 50C is too low. That is minimum temperature of the heated tap water(Legionella and other diseases). And preferably you want some higher. And then as distance increases there are losses and other people using the heat. So temperature you need is actually quite high and in very cold days can be over 100C...
Probably not relevant to the specific problem at hand because sand that's getting heated to 600 degrees is going to quickly boil off any residual moisture. As a warning, though, so that people don't experience the pain I got to experience, a pile of sand is really good at holding onto water internally and freezing when it gets cold. We had to replace our sewer line a while back and for various reasons were taking care of filling the hole and redoing the concrete ourselves. The sand guys left a big pile in the driveway for us and as soon as winter came the whole pile turned into a single giant rock despite having been out in the hot sun previously.
Exactly to your point, though, one of the great things about using sand for this application instead of water is that you can probably just shut the thing off for maintenance without having to worry about draining all of the sand out. If it freezes up due a bit of residual moisture content it's not going to expand nearly the same way that a silo full of water would, and it should be easy enough to thaw out just by putting some heat into it.
A quick caveat/clarification: It's only true if you're pushing the system over the 100°C mark. Otherwise a volume of liquid water--with its greater latent heat-capacity--will outclass the same volume of sand.
Water's heat-capacity is 4.186 J/g°C, while estimates for sand run towards ~0.830 J/g°C. If we also assume the sand is 1.6x denser, then our below-boiling water still comes out ahead at ~3.15x the joules per volume.
There are hints [0] this system tops out around 600°C.
I think the original plan was to convert the heat back into electricity with a turbine. So the higher temperature of sand would greatly improve thermodynamic efficiency.
>I think the original plan was to convert the heat back into electricity with a turbine.
Is that just speculation or did you read it somewhere? IIRC the original motivation of PNE was a bunch of engineers at uni speculating on how to build the perfect building for engineers, and making it self-sufficient would require handling its own heating, which they originally thought would be best done with a big hot-water tank to store the heat. No turbine was suggested, IIRC.
In addition to what others have said, isn't one of the weird properties of water that it tends to take in energy easily, but not give it back so easily? I've never really understood how that works, but I think I've leqrned that at some stage. Hence why it's used in cooling so much. Somebody jump in and tell me how wrong I am, or if I'm on a track that doesn't lead completely nowhere.
Water vaporizes, and at that point blows up just about every container you can build around it. As will ice when it cools down. Sand is just sand, very little difference, very unreactive from way under freezing temps to about 1300 degrees.
And you might vent steam, but you should probably take into account that while water < 45 degrees or so is pretty innocent, steam will strip flesh from bone starting at 180 degrees or so, it won't "just" burn you.
That’s the other bizarre thing about water/ice: most things expand as you heat them, but very few things expand as you cool them. Water has maximum density at 4C, so even before you freeze it it’s already starting to expand as you cool it.
ah OK, I get your point :) It doesn't really matter though because water when liquid doesn't cause any problem when expanding or contracting, its level in a vessel will just slightly change. It's only the ice that can fuck up pipes etc
Note here is also that district heating uses water that is heated to 65-115C.
Which means that you have rather little of delta to work with. And at upper end it becomes somewhat risky to have large container of water that is beyond boiling in normal pressure...
With sand you can use very simple heat-exchangers. No need to use exotic heat pumps that require extra energy...
> Why would anyone review a design/ architecture after it's already been built?
Many reasons. They might not have known it was being built, or they might disapprove of how it's turned out compared to initial presentation, or there might have been a shift in priority making the current project not a good fit.
Or in my world, "We skated around the security/risk review by claiming it is a low-risk application [no PII data, not customer facing, only a PoC, etc], but now we're doing all of those things. The auditors caught on to us and are saying we have to have a review by security. It's already in production so we're not changing a thing. You guys figure out how to make the auditors happy since we won't be held accountable.". Good times.
