jabl

AFAIU EuroOffice is a fork of OnlyOffice, which is a project with a codebase completely separate from LibreOffice.

Can you name a specific example of a trade secret revealed in the article?

Unfortunate naming. I thought this was about https://libxc.gitlab.io/ but there's an extra '0' in the name here.

The Linux kernel is another example. The 2.5 development cycle (which led to the stable 2.6 series) was brutally long, and distros resorted to back-porting new features into their own kernels based on the stable 2.4 series that they provided to their users, creating all kinds of excitement. After 2.6.0 was released, Linus basically went nope, not gonna do that again.

$50M? Pfft. The regional health service provider over here has spent close to a billion € migrating to Epic over the past decade. The feedback has been so devastating they're apparently now considering starting over from scratch. Love seeing the consultants lighting my tax money on fire like that.

Perhaps they should use OpenAI models to figure out how to rollout IPv6.

For comparison, latest commercial turbofans approach 6000h (they don't have a strict TBO limit AFAIU, overhauls are decided based on various inspections and measurements). At a typical airliner speed that's something like 3,000,000 miles.

> IMHO, electric is going to revolutionize farming. Diesel is expensive (a lot more lately). And farmers burn a lot of it. Electric motors are small, reliable, quiet, etc. They have loads of torque. And if you are a farmer, you have plenty of space to harvest your own electricity with solar panels and maybe a wind mill and some batteries. There is a growing amount of high end stuff available in this space but also very affordable low end stuff. And this technology can be very simple and tinker friendly. Buy some old EV batteries wire them up and you can make anything with wheels move. Including really old tractors, pickup trucks, etc. Anything from the largest mining trucks to the smallest lawn mower can already be powered by batteries. And everything in between. With battery cost dropping, there are very few obstacles that prevent adoption left. Mostly import tariffs in the US.

Yes. But maybe not a 1:1 of current petroleum-powered equipment with an equivalent electric one? Say, crop dusting aircraft are not being replaced by electric powered crop dusting aircraft, but by (electric powered) crop dusting drones.

Could something similar happen for, say, tractors? A tractor is of course an extremely versatile tool, and as long as there's a human driving it there's a tendency towards ever bigger tractors in order to minimize labor/ha. But big tractors are already a bit too big and expensive for many not-huge farms, ground compaction is a problem with large weight etc. Could we see these replaced by a fleet of electrical drones (drones as in autonomous, not necessarily flying) rather than "just" an electrical tractor? Of course, there's a certain minimum power required to pull a plow etc., so maybe not? Of course, autonomous fleets etc. goes a bit against the idea of DIY-fixable. Or does it? A different skill-set than wrenching on an old tractor, sure.

I'm intrigued by this, but waiting for the MNT Reform Next.. https://www.crowdsupply.com/mnt/mnt-reform-next

See also Kingsmill Bond's slidedeck at https://ember-energy.org/latest-insights/the-electrotech-rev...

Unfortunately my ISP here in Europe is not one of those offering IPv6.

Are any ISP's or corp intranets doing IPv6-mostly style networks yet: https://www.ietf.org/archive/id/draft-link-v6ops-6mops-00.ht...

That seems to be a promising approach.

My understanding the rail share of freight is relatively low in Japan compared to many other developed countries. Most freight moves by truck or coastal shipping. Looking at a map of Japan, most of the cities are by the coast, so I guess coastal shipping makes a lot of sense.

Most EU countries have adopted the approach of putting the infrastructure company and the public train company under the same holding company, which is sort-of the minimum that EU regulations demand. In practice, in many countries the previous national rail company (under whatever conglomerate structure it may be operating under today) is fiercely protective of its own turf and tries to prevent new entrants, and digging their heels in implementing EU railway competition regulations. So complying with the letter of the law, but does everything in its powers to not comply with the spirit.

Then again, given the UK experience of going all-in on the "vertical separation" and privatization path, perhaps one shouldn't blame them.

The interesting thing is how the EU railway policy just keeps plowing ahead trying to impose the "vertical separation" approach in the EU, despite the disastrous results from the UK experience (and some EU countries to a somewhat lesser extent, so far the UK seems to be the only example of going all-in on that approach).

> China also has nationalized rail systems. The major reason for the failure in the US is that the rail lines are not publicly owned.

The article we're discussing explains that Japan has the best passenger rail system in the world, and which happens to be privatized, along with privately owned track. So which one is it? Go figure.

There's https://currentos.org/ working on it.

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.

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.

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.

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.

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.

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.

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

I don't think the situation is that comparable to python, since in python the library has to be present at runtime. And with the dysfunctional python packaging there's potentially a lot of grey hairs saved by not requiring anything beyond the stdlib.

With Rust, it's an issue at compile-time only. You can then copy the binary around without having to worry about which crates were needed to build it.

Of course, there is the question of trust and discoverability. Maybe Rust would be served by a larger stdlib, or some other mechanism of saying this is a collection of high-quality well maintained libraries, prefer these if applicable. Perhaps the thing the blog post author hints at would be a solution without having to bundle everything into the stdlib, we'll see.

But I'd be somewhat vary of shoveling a lot of stuff into stdlib, it's very hard to get rid of deprecated functionality. E.g. how many command-line argument parsers are there in the python stdlib? 3?

> You can look to Swift for prior art on how this can be done: https://faultlore.com/blah/swift-abi/

> It would be very hard to accomplish.

Since Rust cares very much about zero-overhead abstractions and performance, I would guess if something like this were to be implemented, it would have to be via some optional (crate/module/function?) attributes, and the default would remain the existing monomorphization style of code generation.