grandinj

Meh? Couple hundred meters of elevation and a hundred acres runs a city for day. Source - the city I live in which has this exact setup.

There are people working on compiling Libreoffice to WASM, but it is a separate effort

Its a ton heavier, because you need a full LibreOffice install effectively, but it does a lot more than Apache POI, so it depends on whether your use-case warrants the extra features.

Companies like Collabora (for general linux stuff) and Igalia (for browser type stuff) exist to do things like this.

They employee a bunch of people who work on open-source stuff, and you can pay that company to get stuff done on various open-source projects.

The stumbling block is that the cost is almost always much much more than you would be willing to pay, because, surprise surprise, our line of work is very very expensive.

It costs money to validate a new processor on an old motherboard, and no corp wants to waste money on a product they have already sold.

Erlang is being sneaky because an Erlang "process" is not the same thing as what the rest of call us a "process". As soon as Erlang needs to talk across real processes is runs into all the same problems. Now, admittedly, Erlang has a nice supervisor toolkit to help with this, but its still a real problem, even for Erlang.

Better to just ban cryptocurrency. Or impose the same controls that other banking systems have to obey. That will cut off the flow of funds.

OOOh, very very nice. I might have to copy this into the H2 database engine. We already use variable-size encoding for numbers, and this would make a nice addition to reducing the size of row data containing text.

Given the size of the company and that this is over 3 years, that seems like a “meh” situation

This is a very good idea

This is generally the same path that LibreOffice followed. Works reasonably well.

We built our own find-dead-code tool, because the extant ones were imprecise, and boy oh boy did they find lots of dead stuff. And more dead stuff. And more dead stuff. Like peeling an onion, it went on for quite a while. But totally worth it in the end, made various improvements much easier.

This.

We use it in LibreOffice, but its a right pain to update versions and debugging it is.... challenging.

The upside is that the Google Skia team is super friendly and willing to help.

One of the main developers of this has been bringing his talents to LibreOffice recently, along with some of the improvements from NeoOffice.

What would you suggest as an alternative basis for eviction?

Yes, that is also a valid backwards compatibility choice, although it is an all-or-nothing choice, clients cannot mix and match wayland and X11 functionality.

But if they had allowed more of the X11 APIs to be supported via that Xwayland, the transition would be a lot easier.

Unfortunately that was shot down, in favour of forcing every new wayland compositor to implement things like remote desktop and screen capture differently.

For starters, it is rather rude to assume how little I know about this.

Leaving that aside, Drew is mis-characterising things a little.

Wayland is fundamentally a different __compositor__ architecture. But the X11 system is about more than that, in fact compositors are a rather late addition to the X11 system.

And the protocol architectures are actually quite similar in shape. Which is not surprising, since good ideas last, and X11 has been around for a long time and has accumulated lots of good things (along with lots of cruft too).

So it would have been quite possible, but a good deal less fun, to do it differently.

Well, normally that would be true.

But Wayland decided to "boil the ocean" and entirely replace a stack of stuff that was working perfectly well for most people.

So perhaps the onus should be on the people who decided to do that, to make sure that things keep working instead of just dumping it?

An alternative design would have been to have built Wayland inside X.org and tunnel the new protocol over the existing protocol, and then migrate chunks of functionality one at a time.

Which is exactly how X11 replaced X10, and X10 replaced X9, etc.

But that would have been careful engineering practice, and not nearly as much fun, so I understand why it did not happen.

Well, yes, what is needed is a solid understanding of why we are here, and what needs to be done to get to a better place.

I like the Wayland devs, and their occasional failures should not overshadow their successes.

Part of the problem is that Wayland looked at several large chunks of functionality that X11 implemented and said "no thanks, those are security holes, we want nothing to do with them, that is the responsibility of the distro/DE/etc"

Which is rather in conflict with earlier promises about maintaining functionality.

This resulted in a whole chunk of work that was either badly done, or not done at all, or needed all sorts of hacks and extra work because it needed to be re-implemented in different ways on different distros.

So I'm really not sympathetic to the Wayland devs, they needlessly created this situation.

A more reasonable answer would have been "we don't like this, it's a security hole, but whatever, just implement a Wayland extension that matches the X11 one, and security conscious people can disable it, and everybody else can move forward productively in the short term"

Hmmm, int[] now being a subtype of Object[] is going to cause some odd bugs in code that does lots of reflection - eg. some of the frameworks that doing Rails style magic in Java.

The right thing to do is to create a new thread safe api and implement that and then standardize it. Hard but very unsexy work.

That sounds like Julia needs some kind of test suite, that lives alongside the major libraries used in Julia, and verifies that things that interact do so in a reasonable manner e.g. things that implement addition obey the rules of addition, etc, etc. With a little reflection and some automation, such a tool could be taught to test new Julia libraries and catch problems early.

i.e. what I am talking about is effectively informally encoding protocols/interfaces and suchlike in a test-suite, rather than seeking to make it a part of the compiler/language.

Not as sexy, no doubt, but flexible and with a short time to get feedback.

Those other lines of business you mention are able to do some degree of negotiation with their customers around what level of service they provide which mitigates a large chunk of the problem.

I'm not saying you're wrong - most hospitals in my country (not the USA), do in fact manage to produce itemised bills, but as someone who has worked close to (but not in) hospital billing, I'm just saying that I have some degree of sympathy for the hospitals.

That is because it is largely a work of fiction. The vast majority of a hospital's costs are fixed, not variable, so when they have to divide it up into individual "items", the amounts allocated are to each "item" or "service" are fairly creatively arranged.

Think about it - most of the stuff has to be there "in reserve" so to speak, with a fair amount of surplus to cater for surges of different kinds of sickness, so there is very little ability to match demand and supply. The actually variable stuff (e.g. drugs, saline, other consumables) is a fairly small part of the overall operating cost.

Let’s call this what it is - a kickback for helping to maintain a monopoly

> share my screen in video meetings in Firefox.

Yeah, in limited ways, the wayland functionality is there. But as soon as you step off the most-popular-path even a teensy bit, it breaks.

I am relying on Teamviewer for remote desktop access because the official RDP support breaks in a different way with every minor release.

h2 dev here. What transaction management issues did you have?

This. The standard is also truly horrible to read. It's not really designed to be read, as much as it is an after-the-fact description of what somebody has already done.

To the point that testing against a very wide variety of base-stations (and the multitudinous variety of configuration options in those base-stations) is mandatory.

What do you use as a build system for Java? We use ant (old, ugly, reliable) and gradle (new, nice looking and absolutely horrible to maintain)

Unfortunately tables are a major weak point in the writer codebase.

Hopefully you will be happy to hear that a company has funded some improvements to that part of the code, and those improvements should roll out over the current and the next release.

ODT files are theoretically human-editable, because once you expand the file (using e.g. unzip) you have a small set of XML files, which can be edited as text and then wrapped up into an ODT again.

Finding "corruption" is not really a thing (at least for writer documents), the spec for writer documents is sufficiently complex that parts of it are in conflict with itself, and compromise solutions must be found in the code.

The writer code to lay the document out is sufficiently complex that it has multiple chunks of guard code specifically designed to make it give up when it cannot make reasonable progress.