For Zulip, I’ve only used it on the web. Apparently they have iOS, Android, Desktop, and Terminal clients.
For Matrix, there are many clients on all platforms, but none have ever stood out to me. Element is the official client, and it’s… fine I guess.
I love this, especially the criticism of the FSF.
For coms, Zulip seems OK. I would really like Matrix to take off, but I honestly don’t really like any of the clients.
How does Kodi compare to Jellyfin?
I use Android TV and Chrome on macOS as my primary clients, and Arch on my server with an Nvidia 1080Ti for transcoding.
After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs. One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today.
Why does Google Slides only get 4/5 for compatibility?
It literally works on everything. I’m surprised LaTeX scored higher on compatibility, because the install process is heavy (8 GB or more, as you said) and you still have to configure afterwards (e.g. change to XeLaTeX for Unicode support.) IMO, Slides is a 5/5 and LaTeX is a 4/5, for compatibility.
EDIT: Also Google Slides works offline, and you can install it as a PWA by clicking a button in Chrome.
It was not Electron’s problem.
The problem was the extension architecture, that they leaned into heavily. It encouraged basically every part of the system to interact with every other part of the system, like having free reign over the whole DOM. That’s what the creators meant by a “hackable” editor.
VS Code is much faster, largely because of its much more sane extension architecture. Extensions are much better isolated, with a much smaller API surface by which they can interact with the editor. And the LSP design means core IDE-like features can be lifted into a privileged part of the system, and implemented once with performance in mind, while the actual analysis is done asynchronously in subprocesses.
If you actually use both Atom and VS Code configured to feature parity, you would notice that VS Code is miles ahead of Atom. Microsoft did an amazing job proving that you can build complex performant software on Electron.
Yes, Electron 2.0.0 was a great update, but it’s not the reason for performance. The reason was better software architecture.
Exactly.
Atom being open source was why I switched to it from Sublime.
Atom’s shitty performance was why I switched away to VS Code.
What’s the difference in bookmark management versus read-it-later? Do you need compatibility with a specific browser?
Do low tech solutions work? Like passing a JSON or something around with rsync?
Neat.
So this is like Last.fm, but run by the MusicBrainz folks?
To be clear, when I say “corporate support,” I don’t mean the company pays you.
I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.
That’s how all of the projects I listed operate.
If you don’t care about interfacing with the industry like this, that’s totally fine, and the AGPL works. But if your goal is to write a piece of software that is used by the industry, then it can’t be AGPL without a strong and exceptional business model.
And I’m not trying to make a statement about whether you should write this kind of software. It’s only a statement about what to expect if you write this kind of software.
Linux, coreutils, LLVM, GCC, Chromium, Firefox, V8, Python, Postgres, Java, systemd, kubernetes, Docker, Bazel, Buck, Abseil, Guice, Fedora, Ubuntu, Android, Hadoop, Apache, Nginx, Spark, TensorFlow, PyTorch…
Yeah, companies never contributed to open source.
AGPL is a sure-fire way to steer off corporate support.
GPL is usually fine for corporate use.
For example, Google and Meta actively contribute to Linux (GPL) but neither would ever touch an AGPL project for fear of infecting their other IP.
Well, to follow version 3 of the GPL, you do actually need to provide effective root access.
Specifically, version 3 of the GPL adds language to prevent Tivoization.
It’s not enough to just provide the user with the code. The user is entitled to the freedom to modify that code and to use their modifications.
In other words, in addition to providing access to the source code, you must actually provide a mechanism to allow the user to change the code on the device.
The name “Tivoization” comes from the practice of the company TiVo, which sold set-top boxes based on GPL code, but employed DRM to prevent the user from applying custom patches. V3 of the GPL remedies this bug.