Hacker Newsnew | past | comments | ask | show | jobs | submit | jabl's commentslogin

Some years ago I tried to learn CAD by doing some FreeCAD tutorials, and failed. But I hear 1.0 was a big step forward, and the recently released 1.1 is also a big step, and it should be somewhat decent nowadays. Maybe I need to try again one day.

Yeah it's vastly better in 1.0 than it used to be. I still think you might be a bit lost if you aren't familiar with parametric CAD, but it's no harder than Blender for example.

Because the grifters are running the show. The point is not to fly to orbit/moon/mars/whatever, but shovel taxpayer money to politically well connected large aerospace contractors.

Didn't they fire most of Solaris devs some time ago? Incidentally, Solaris been stuck on 11.4.x for, well, forever and a half..

I know nothing about IT project management for healthcare, but just the other day over here in the local news there was a mention that the all-singing-all-dancing healthcare application that the region (with ~1M inhabitants) has been spending years and around 800 million euros to get into production has been so poorly received that they're considering starting over from scratch. I'm so happy seeing my tax money well spent...

This is an implementation of something called MUMPS, which is apparently some US system that is very arcane but widely used.

Again, I'm not an expert on this topic, but it indeed seems like standards, API's, file formats and whatnot would be keys to a system where decoupled components can be evolved step-by-step over time instead of the current system which seems to be a humongous monolith.


Which sounds crazy to me considering how much involvement the US has with FHIR.

http://hl7.org/fhir/

Even if you don't care about this stuff, FHIR is definitely worth investigating.


OoO is a surprisingly old idea, first used in the IBM System/360 Model 91 released all the way back in 1966.

https://en.wikipedia.org/wiki/Tomasulo's_algorithm

Took a while until transistor budgets allowed it to be implemented in consumer microprocessors.


Also for the gap between CPU speed and memory speed to matter enough for it to be worthwhile.

If you read more carefully it says fsync needs some enhancements to the futex API, called futex2. The original patch that fsync needed called the syscall futex_wait_multiple. Eventually futex2 made it into the mainline kernel, but the syscall is called futex_waitv. Not sure if the wine fsync implementation was updated to support the mainline kernel futex2 implementation.

x86 has decades of knowhow and a zillion transistors to spend on making the memory pipeline, TLB caching & prefetching etc. etc. really really good. They work as well as they do despite the 4k base page size, not because of it.

If you'd start from a clean sheet today you'd probably end up with a somewhat bigger base page size. Not hugely larger though, as that wastes a lot of memory for most applications. Maybe 16k like some ARM chips use?


Not sure about this argument, do you have any references?

In a LWR, if the coolant/moderator boils away, sure, the reactivity goes down. But there is plenty enough decay heat left to melt all the fuel that can then flow into a puddle of suitable geometry and go boom. Hypothetically speaking, at least.

I suppose in practice most LWR's use lightly enriched fuel so it's very hard to get enough material close enough together to make it critical, let alone supercritical, without a moderator of some sort. Of course, plenty of research reactors, naval reactors etc. have operated with very highly enriched fuel (90+%?), but even these have AFAIU so far managed without accidentally turning themselves into nuclear bombs.

Seems most contemporary civilian fast reactor designs are designed to operate with HALEU fuel, where the limit is (somewhat arbitrarily) set at 20%. A lot higher enrichment than your typical LWR, but still much lower than you see in weapons, and you still need quite a lot of it before it can go boom.


It's straightforward. Consider what would happen (for example) if all the fuel in a reactor is compressed into a more compact configuration.

In a thermal reactor, there's no problem, as there's now no moderator. There was massive rearrangement and compaction of melted fuel at the TMI accident, but criticality was not going to be a serious issue for the fundamental reasons I gave above.

In a fast reactor? It can only become more reactive. Anything else there was only absorbing neutrons, not helping, and the geometric change reduces neutron leakage.

Edward Teller somewhat famously warned about the issue in 1967, in a trade magazine named "Nuclear News":

“For the fast breeder to work in its steady state breeding condition, you probably need half a ton of plutonium. In order that it should work economically in a sufficiently big power producing unit, it probably needs more than one ton of plutonium. I do not like the hazard involved. I suggested that nuclear reactors are a blessing because they are clean. They are clean as long as they function as planned, but if they malfunction in a massive manner, which can happen in principle, they can release enough fission products to kill a tremendous number of people.

… But if you put together two tons of plutonium in a breeder, one tenth of one percent of this material could become critical. I have listened to hundreds of analyses of what course a nuclear accident could take. Although I believe it is possible to analyze the immediate consequences of an accident, I do not believe it is possible to analyze and foresee the secondary consequences. In an accident involving plutonium, a couple of tons of plutonium can melt. I don’t think anyone can foresee where one or two or five percent of this plutonium will find itself and how it will get mixed with other material. A small fraction of the original charge can become a great hazard."

(Natrium is not a breeder but the same argument holds.)

That no fast reactors have yet exploded is of course no great argument. How many fast reactors have been built, particularly large ones? Not many. And we've already seen a commercial fast reactor suffer fuel melting (Fermi 1).


There have been some sodium cooled designs that have used a closed cycle gas turbine using nitrogen as the working fluid for the secondary circuit, in order to avoid any issues with sodium-water reactions with a traditional steam Rankine secondary circuit.

There are also fast reactor designs using lead as the coolant rather than sodium. These are interesting, but less mature than sodium cooling. Sodium is better from a cooling and pumping perspective though.


Lead-bismuth eutectic.

A eutectic is an alloy that has a lower melting point than any of its components.

Lead-bismuth eutectic or LBE is a eutectic alloy of lead (44.5 at%) and bismuth (55.5 at%) used as a coolant in some nuclear reactors, and is a proposed coolant for the lead-cooled fast reactor, part of the Generation IV reactor initiative. It has a melting point of 123.5 °C/254.3 °F (pure lead melts at 327 °C/621 °F, pure bismuth at 271 °C/520 °F) and a boiling point of 1,670 °C/3,038 °F.

https://en.wikipedia.org/wiki/Lead-bismuth_eutectic


Bismuth leads to the production of polonium, which is extraordinarily dangerous.


Yes, some lead cooled reactor designs have used LBE, others pure lead. Though AFAIU so far the only lead cooled reactors that have actually been built and operated in production have used LBE. There is a pure lead cooled reactor under construction that should be started up in a few years if the current schedule holds.


I have a small benchmark program doing tight binding calculations of carbon nanostructures that I have implemented in C++ with Eigen, C++ with Armadillo, Fortran, Python/numpy, and Julia. It's been a while since I've tested it but IIRC all the other implementations were about on par, except for python which was about half the speed of the others. Haven't tried with numba.

To bring Julia performance on par with the compiled languages I had to do a little bit of profiling and tweaking using @views.

https://gitlab.com/jabl/tb


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: