Just recently there was an editorial from a tech author who prefers OpenOffice precisely because it isn't changing. It is stable and works, and the UI won't get redone.

That is great if you want a desktop client that just works. Not as great for the EuroOffice folks who want it in a web browser.

LibreOffice only just recently restarted their online version, though they only provide the software and not a hosting mechanism. Perhaps that software could've been a base for EuroOffice, but it isn't in production state yet. OnlyOffice is quite a bit ahead there.

I think one of the reasons LibreOffice hadn't been working on their online version before is that Collabora is a major contributor to LibreOffice and they already have a product that does what LibreOffice online will do.

They will soon have console hardware too (Steam Machine), though the current silliness with component pricing and availability is going to disrupt their launch. They already have handheld hardware.

The move fast and break stuff mantra of many web developers has left us with a lot of broken stuff.

I've seen it used as a sign that some effort was put into it (as long as it wasn't a form letter). It is nice to know that an applicant spent a few minutes looking into the company.

Jobs can get a flood of applicants nowadays. A tailored cover letter can be a way to differentiate. However, I also get why someone wouldn't bother as they probably will need to put in 100 resumes to even get an interview somewhere. The process really is breaking down, in part thanks to how much automation is happening at both ends of it.

That wasn't as terrible of an idea as this though. A browser based phone OS that works much like ChromeOS would be useful for budget phones, and also a good thing for the open web. Existing phones and phone makers try to funnel everything into their app ecosystem instead of the web, and all of those phones come with a proprietary browser bundled with them. Trying to keep the mobile space more open and keep Firefox relevant in that space wasn't a terrible move for a browser company to make.

But much like the browser wars themselves, it meant going up against giants like Google, Apple, and Microsoft. They may be able to do that on the desktop where a person can just download a new browser, but in the mobile space it meant competing with those companies for contracts with phone manufacturers. That is a whole different proposition.

If they are comments meant to help people understand or reproduce the code using AI, they might even be useful.

If they're comments that were there to help the AI write the code, the fact they weren't removed afterwards shows a lack of attention from the "developer". It is probably good practice to not accept code written by an AI that a coder hasn't really looked at.

I suspect you're right about why the policy is in place. They're getting flooded with AI slop submissions. It is easier to say no to all of the easily identifiable ones than to try to filter through them. Even then, it takes time to go through and identify them, so what they'll really be hoping to do is stop these submissions altogether. If they never get accepted, maybe people won't bother.

Except this isn't prohibiting code generated from an LLM. This is prohibiting code from someone who doesn't understand coding well enough to clean it up enough so it looks like a real person developed and reviewed it.

If the code is calling non-existent APIs or has AI prompts left in the comments, it is garbage code that shouldn't be accepted. What they're actually saying is they won't accept crappy and careless code.

This is one of the rare times that the answer to the headline question is yes rather than no.

Absolutely high speed trains *could* do that. But it wont happen.

I'm honestly not sure it is a great idea. When it comes to non-phone form factors, I've had both Android and ChromeOS tablets and laptops, and ChromeOS is far better for the task. You can add the Google Play store to it, so it can run Android apps just fine if needed. You can also enable Linux apps. It is smart enough to switch between tablet and laptop mode depending on if the keyboard is there. It isn't a jarring difference, but it does shift a few things to work better with a touchscreen vs keyboard.

It seems to me the convergence would work better when you get mobile stuff to run in a desktop environment rather than trying to get desktop stuff to run inside of Android.

It is all powered by Linux so in theory it should all work together, but in practice they've announced these operating systems are merging many times already. It only ever happens as an internal project, and never sees the light of day.

The CEO has been given all sorts of impressive demos where it works well, so his view of the technology is skewed.

Add in that he's financially motivated to believe that they've created something amazing with all of their investment, and you have a recipe for someone to be very detached from reality.

In Canada it was a large anti-vax movement in religious communities in southern Alberta that caused their issues. Most of the far right stuff in Alberta is imported from the USA.

The anti-vax movement predates Trump, but his choice to pick an anti-vaxer to lead US public health certainly hasn't helped.

The lack of the one cross platform UI framework to rule them all can be a downside, as has Microsoft's adventures with creating and abandoning modern UI frameworks. But on the flip side this has led to a proliferation of third party options.

Avalonia works everywhere, and they recently made MAUI run on top of Avalonia to give it Linux and WebASM support. They also have a commercial product to run WPF cross platform using Avalonia. So not only do they provide a good option, they have made two of Microsoft's frameworks work cross platform as well.

Then there is Uno Platform, which is basically a cross platform WinUI implementation. There is also Eto.Forms if you want a simple desktop focused toolkit that wraps the native platform's widgets. There are also a lot of ways to bring Blazor to native applications. You can even use QT with QML.NET, though that isn't actively maintained.

It was simpler to choose a UI for C# in the early days. All you had was WinForms. Then for a while you had Winforms or WPF. Now this decade there is a pile of options.

It is surprising how common this is. I see complaints that CompanyX doesn't have an app, but when asked about what that app would do that the mobile friendly companyX.com website doesn't do they're not able to answer.

The one benefit to that is that it is easier to make it cross platform, but there are other ways to be cross platform without writing a web app. Unfortunately the largest (and often least expensive) set of developers know how to make websites and nothing else, so they make what they know.

You can't really blame application developers for not targeting native Windows anymore when even Microsoft doesn't use their own native frameworks to build applications. Outlook is now just a website inside a webview control, rather than a native app. Since they were already spending effort developing a web version of Outlook, this allowed them to converge the codebase and maintain just one Outlook rather a Windows app and a web app. It also means that it doesn't feel like a native application a lot of the time.

The same person who designed TypeScript also designed C#, so they have a lot of similarities. The main difference is that C# is compiled for its own runtime rather than being turned into Javascript and run by a web browser.