This is probably a wrong audience. Most people here are very technical - the kind that would not put up with tiptoeing around a sacred computer from decades ago running some magic software from the DOS era. This crowd will aggressively move it to modernized architecture or at least emulate it using a more modern platform.
The company I worked at in the late nineties, used Managing Your Money (MYM) for bookkeeping - initially on a dedicated DOS machine. My colleague set up a DOSEMU-based emulator and moved the software to it (bye-bye, dedicated DOS machine!). Later, he re-wrote it in STk (Scheme w/ Tk bindings, running natively in Linux) as ageneral-purpose transaction storage. ¯\_(ツ)_/¯
Yeah. Sometimes old hardware forces its hand and causes a big PITA.
I had a job working on VAX/VMS around 2009, but it was actually an emulator running on a PC because they just couldn't find any hardware to fix the VAX. At some point before I joined they had to get a ton of government approvals to use the emulator.
Fortunately they had a project to modernize the whole stack. And it was going to Solaris :-/
I've had a Snapdragon X Elite laptop for 2 years, constantly trying to get Linux off the ground on it. Didn't happen (well, technically, toward the end of that period, there was an unsupported port of Ubuntu but it lacked half the drivers). And yes, when I bought it there was a very similar announcement from Qualcomm promising first-class Linux support. So I wouldn't gamble on it (especially considering that prices are crazy) until there indeed is a supported distro.
Yeah, I've really wanted an ARM Linux laptop. But I've known ARM is a crapshoot because of my dealing with other devices. So I held off on the initial X release. Then I saw the X1P (or whatever it was) and Qualcomm put out the exact same "someday Linux up streamed!" Promise.
A competent FTC would be fining them for these false and misleading statements. Until that happens, nobody should buy these thinking Linux will ever be supported.
Hmm... Is it an experiment? I'm seeing all reviews both on the web and in the app (Android phone).
Having said so, I am not hopeful. Amazon has gone the enshittification route with the gusto few companies have. And they've been actively (and gleefully) making some of the most useful features near useless. This can be seen most pointedly with order history search. Whereas in the past searching for a string brought up the past orders based on string match, now trying to search for a given term brings up gobs of past orders with items having absolutely no relevance to that search term. My cynical theory here is that someone "improved" order search by bolting on "AI."
It pains me a lot. I've been a fiercely loyal Amazon customer since 1994 and for a long time they've been the most customer-obsessed company out there. I can't even describe how different things are now.
Looks like you haven't seen what they've done with Order Search. Being a customer since 1994 (yes, when they just came out as a neat way to buy books online), my order history has been an invaluable reference allowing me to find that thing I bought 5 years ago, its specific and the price I paid. Now, instead of a good old substring search, they do some kind of insane fuzzy search which comes up with hundreds of absolutely irrelevant results. They've made it completely unusable.
But I'm sure a good bunch of people got promoted for "enhancing" the search with AI...
KeepassXC comes with its own share of risks (supply-chain attacks, zero-day vulnerability detections etc). No matter, which 3p software you are using, you are effectively gambling on the chance that none of those risks materialize. The only alternative is to personally audit the code - library by library, script by script and build it yourself. But even that carries risks: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
If I keep a KeepassXC database on a set of devices, sync'd using syncthing, then for a large range of threats I'd need to be a target of interest.
This is in contrast to LastPass which is going to attract a ton of blackhat attention.
Yes, supply chain attacks are possible but they're equally possible for lastpass.
Switching to a self-hosted solution isn't perfect. Nothing is, and pointing that out isn't particularly useful.
What it does do is eliminate whole class of threats: large scale, broad based attacks against a single, high value target.
In fact I'd argue writing passwords down in a notebook or putting them in a naked text file on your computer is better than trusting a centralized service like LP.
Of course, if you are a target of interest, the calculus changes entirely.
I work in quantitative finance. I do the vast vast majority of my algebra and stochastic calculus in Mathematica, and lots of ad hoc data visualization.
You might have missed the memo, but Roku's main business has been advertising for quite a while. It is just shrouded in streaming and platforms. But it is advertising nevertheless.
Being a platform, Roku benefits from advertising 3 ways - by running its own ads in some apps and on home screen; by exercising carriage rights on 3p apps that show ads (getting a cut as a platform); and by building and selling audiences for targeting.
For all I know, Fox has zero interest in platforms or technology. But they are fairly sophisticated when it comes to adtech and this is purely an adtech play.
That's precisely what is wrong with the state of the UI for Linux. Instead of boring, long research into user habits, finger memory, and productivity, resulting in boring standards like IBM CUA or Apple HIG, we got a bunch of opinionated engineers who think that people using computers fall into two categories: wizards, who are happy to spend their life tinkering with config files and making various pieces work together - and a bunch of losers not worth developing software for...
(Until Microsoft had actively started fracking it up, sometime around Windows Vista) just like a Roman citizen landing up in any town of the Empire, one would be able to effectively and consistently navigate around, using both keyboard and mouse across most Windows applications. Everything worked in a boring, predictable way. Everything used standard API that provided the whole spectrum of UI capabilities.
With Linux, unfortunately, this was never considered ideal and instead we have a zoo of different paradigms and technologies (plus intense politicking of UI development). Which means, when something happens to work as expected without excessive ServerFault/ChatGPT trawling and config/gconf/dbus wizardry, it feels like a sheer delight and an exception rather than a rule.
As someone who shipped my fair share of critical production features, I find this plan raising my eyebrows somewhat. Disabling a feature AND simultaneously removing the codebase for that feature almost never ends well. There will always be some use cases that people haven't thought of.
In serious projects (read, your career is at stake) a much better strategy is to first make the feature unavailable by normal means while still allowing a workaround (in this case, for example, PLM could remove X11 option from the menu but still allow X11 sessions when some magic environment variable is set.) That would give people an easy way to get the old functionality if something is critically impaired for them. And only then, once we are confident that no massive unforeseen issue has surfaced, can the codebase be removed.
> a much better strategy is to first make the feature unavailable by normal means
They started doing that in early 2024 with the release of KDE 6.0 by enabling KDE Wayland by default. The Wayland-only change won't happen til 6.8 which will be an early 2027 release.
The problem with that strategy when it comes to desktop software is there's no way for the developer to know what the user has done (unless the software phones home, which is a no-no when it comes to privacy-respecting open source software).
If it's a SaaS API or a web application, the developers can look at access logs or analytics to determine what endpoints and features are being used, and when users need to go back to the deprecated interfaces to get what they want.
There's no way for a KDE developer to learn "$NUMBER users went back to X11 because $FEATURE is missing in the Wayland version".
(Of course they can ask their users, or hope that users file issues on the bug tracker, but things will definitely fall through the cracks via these imperfect communication channels.)
Almost 40 years of software engineering experience - and I hate Gradle more than I would consider reasonable. In fact, I consider Gradle the absolute worst software system out there.
Absolute majority of people I witnessed using Gradle (myself including) approached it with almost religious terror. Making a change - any change - is akin to playing Russian Roulette, except all chambers but one are loaded. Change one directive - and your build breaks in most weird and incomprehensible ways.
And then there is the whole notion of stability (I mean "contract stability.") Almost every single release of Gradle breaks things in some subtle ways. I can take a project from the olden UNIX days with its Makefile and that Makefile will work in gmake in the freshest Linux distro, using gmake release that was produced multiple decades after Stu Feldman's make. It doesn't require a very specific version of libc or kernel. Because it is 1. Written portably and 2. It treats its behavior (jokes about using the Tab character aside) as a contract and it doesn't violate it just because some poorly educated software engineer decided that it would be a good idea to change the behavior in the upcoming release.
Almost 40 years of software development and I think you're overlooking the strength of Gradle. Before Gradle if you wanted any kind of build step that was slightly outside of the norm you had to roll your own maven plugin or god forbid try to script something with ant in xml. Using a DSL in a scripting language was a smart move.
What I hated most about Gradle is that groovy is untyped. You'd make a change and wait for your build to complete only to find out minutes later that you made a typo or some other innocuous mistake. Glad they introduced Kotlin DSL.
I didn't notice the breaking changes much when we heavily used gradle. Gradle also comes with gradlew, which bootstraps your gradle project with the exact gradle version that is needed to build that project, so you can take an old gradle project and build it regardless of all those breaking changes that you mention.
Friction made people think if they really need this custom step, now every single gradle project has a lot of poorly thought out custom stuff, often something which doesn't belong there.
The company I worked at in the late nineties, used Managing Your Money (MYM) for bookkeeping - initially on a dedicated DOS machine. My colleague set up a DOSEMU-based emulator and moved the software to it (bye-bye, dedicated DOS machine!). Later, he re-wrote it in STk (Scheme w/ Tk bindings, running natively in Linux) as ageneral-purpose transaction storage. ¯\_(ツ)_/¯
reply