4 ms·

The problem is people only pay for the cool and fancy stuff. Thats why projects like blender and krita are killing it while bluetooth audio and gui libraries ar

The problem is people only pay for the cool and fancy stuff. Thats why projects like blender and krita are killing it while bluetooth audio and gui libraries are in such a dire state. Competitors have an advantage where you buy a macbook and the profits go to every single part and not just the eye catching features.

londons_explore 6y ago
The solution here is for authors of the eye-catching features to re-spend some of the rewards on infrastructure they depend on. If a blender dev wants to improve perf and finds that the bottleneck is in some Linux kernel component, they should post a bounty for improving that component.
- ludston 6y ago
  The problem with this is that they could also just pocket the money, and then they have more money.
  - atoav 6y ago
    Yeah, that is not how the blender institute works. The question how to balance spending on Blender features vs dependencies is a legit one though. Blender "is killing it" because for years they never chose the easy fix or the low hanging fruit over sustainable changes. In addition to that the Blender dev community is really goal oriented. Not many holy cows, everybody is just focused on the result. Imagine how Blender's 2.80 changes would've panned out in any typical Open Source project — often they can't strike the balance between old and new users, a lot of bikeshedding, infighting, forks, ... Blender is killing it because there is a great community that is focused on the results. The influx of money could also have derailed the Blender project, but it didn't, which is further proof that they are doing something right.
noobermin 6y ago
May be do it that way, like pay for freedesktop.org and have it filter down.
jsilence 6y ago
Well, if the fancy projects are killing it, they could always give back to the giants shoulders or piles of dwarfs they are standing on.
- kevincox 6y ago
  Exactly. If GNOME or GTK are killing it (although it isn't clear they are) it would be negligent of them not to share with the projects that they depend on. Maybe we need to get better at advertising the status of projects. I hope that funding goals being advertised becomes mainstream.
jchw 6y ago
Sidenote: Bluetooth audio is not in a dire state, at least compared to Windows. Let me compare my experience on Windows 10 2004 to a fairly vanilla NixOS PulseAudio configuration. Same Bluetooth chipset, same headphones (Sony WH1000XM3s.) On Windows: - Obviously, in Windows, you get the Bluetooth stack automatically, as well as drivers. So I did not have to do any setup. It is possible, though, that some alternate drivers would work better than the default ones, which seem to be buggy. - Pairing is fairly straight forward. However, sometimes it doesn't work quite right: the device will connect but not function right, sometimes leading to all Bluetooth devices failing to pair or connecting and disconnecting rapidly. This may be related to the driver, although it is using the default driver. - Playback seems fine when it works. Sometimes it is randomly choppy. My understanding is that Windows 10 supports aptX but not aptX HD, and I can't get it to show up in traces but I suspect aptX is likely the codec being used. SBC is really 'good enough' for most cases though, so it's not a big deal. - Routing leaves something to be desired. Every single time the device is paired, anything that plays audio needs to be moved or explicitly restarted for it to work. For example, Firefox or Edge tabs playing music typically have to be reloaded even if i unpair and repair the headphones during playback. It also interacts ridiculously poorly with my Realtek drivers, also Windows 10 defaults. I typically have to jump into the weird mixer and try to get everything right when switching between the two, and some apps like Discord act a little weird even then. On NixOS: - Not all distros will require this, but NixOS naturally requires configuration by its nature. Here is my audio-related config, in its entirety: hardware.pulseaudio = { enable = true; daemon.config = { flat-volumes = "no"; resample-method = "speex-float-10"; }; extraModules = [ pkgs.pulseaudio-modules-bt ]; package = pkgs.pulseaudioFull; }; hardware.bluetooth = { enable = true; package = pkgs.bluezFull; }; nixpkgs.config.pulseaudio = true; environment.systemPackages = with pkgs; [ pavucontrol pulsemixer broadcom-bt-firmware ]; Most of this is NixOS specific. Some of it is personal: I disable flat-volumes because I do not like flat-volumes. I switch the resampler to a different one to prevent aliasing artifacts. (This may seem like audiophile non-sense, but it actually impacted real-time resampling chibi-tech's album "The Mutual Promise" which has 18-20 kHz sounds in it, designed to sync to some Pripara toys. Pretty interesting stuff.) In any case, it's the whole config. I don't think I ever had to trial-and-error it, I just followed the manual. So not too bad. Honestly, I fully expected it would not work. And for a long time, I never tried the setup. However, a few months ago I tried it. Here is what I found: - Pairing works. I have yet to hit an issue where pairing does not work. - Playback works, and using either Blueman or the PulseAudio mixer it is trivial to switch between A2DP codecs or, if for some reason one would want to do it manually, HSP. Once again, I have not noticed problems. I tend to use the Sony LDAC codec since it seems most appropriate for the headphones. - Routing seems okay too. I do still sometimes run into a situation where I need to switch an app manually, but it's easy to do in the PulseAudio mixer. My verdict is that the Linux Bluetooth Audio situation is not bad. Yes, no ordinary Windows user could stomach the Nix configuration in my Nix setup. However, you can notice the lack of hacks needed here: clearly, Bluez and PulseAudio are now up to the task of handling Bluetooth Audio "correctly". I haven't tried but I suspect Debian or Fedora would, with a couple of packages installed, handle Bluetooth devices just fine so as long as the Bluetooth chipset is supported. Bonus: In the future, Pipewire will take over for Bluetooth audio. For the time being it is limited to SBC and can't handle other codecs yet, but I gave it a shot and it seems to work just fine, too. Hopefully that holds into the future.
zanny 6y ago
"Killing it" is relative. Krita is roughly 500k LOCs of code proper. The KDE ki18n library that is one of its primary dependencies which extends Qts internationalization faculties is... about 7k LOCs. Almost all of Kritas immediate dependencies are small shims except for Qt itself which is produced by an already profitable corporation. So qtbase is about 2.3M LOCs but the Qt Company has ~300 employees with most of them working on it. Krita with its "killing it" manages to employ 4 people full time to work on development. That is on an install base of several millions of active users. The closest competitor to Krita is probably Paint Tool Sai, a proprietary Windows only program that is made by a for profit Japanese corporation as its largely only product that employs around ~10 people. Getting actual employment figures for Systemax Software Development is actually really hard... Point is Krita is likely shuffling along with half the full time paid employees of its principal competitor while also likely having a larger installed and active userbase due to it being free software and cross platform. They aren't "killing it" at all, especially if you compare it to the elephant in the room at Adobe with a hundred man development team at least making insane amounts of revenue off licensing of Photoshop. Its revenue is nothing close to hoist the weight of the entirety of the free software ecosystem upon when it doesn't itself come close to even competing in the field its doing a really good job competing it on a tiny development team.
CarVac 6y ago
I plan on putting up a Patreon/Liberapay for my photo editor that is purely a passthrough for the boring backend stuff that I rely on.
benlumen 6y ago
Such a great point. I feel like this explains the state of Linux desktop in a nutshell, actually.

londons_explore 6y ago

The solution here is for authors of the eye-catching features to re-spend some of the rewards on infrastructure they depend on. If a blender dev wants to improve perf and finds that the bottleneck is in some Linux kernel component, they should post a bounty for improving that component.

ludston 6y ago
The problem with this is that they could also just pocket the money, and then they have more money.
- atoav 6y ago
  Yeah, that is not how the blender institute works. The question how to balance spending on Blender features vs dependencies is a legit one though. Blender "is killing it" because for years they never chose the easy fix or the low hanging fruit over sustainable changes. In addition to that the Blender dev community is really goal oriented. Not many holy cows, everybody is just focused on the result. Imagine how Blender's 2.80 changes would've panned out in any typical Open Source project — often they can't strike the balance between old and new users, a lot of bikeshedding, infighting, forks, ... Blender is killing it because there is a great community that is focused on the results. The influx of money could also have derailed the Blender project, but it didn't, which is further proof that they are doing something right.

noobermin 6y ago

May be do it that way, like pay for freedesktop.org and have it filter down.

jsilence 6y ago

Well, if the fancy projects are killing it, they could always give back to the giants shoulders or piles of dwarfs they are standing on.

kevincox 6y ago
Exactly. If GNOME or GTK are killing it (although it isn't clear they are) it would be negligent of them not to share with the projects that they depend on. Maybe we need to get better at advertising the status of projects. I hope that funding goals being advertised becomes mainstream.

jchw 6y ago

Sidenote: Bluetooth audio is not in a dire state, at least compared to Windows. Let me compare my experience on Windows 10 2004 to a fairly vanilla NixOS PulseAudio configuration. Same Bluetooth chipset, same headphones (Sony WH1000XM3s.) On Windows: - Obviously, in Windows, you get the Bluetooth stack automatically, as well as drivers. So I did not have to do any setup. It is possible, though, that some alternate drivers would work better than the default ones, which seem to be buggy. - Pairing is fairly straight forward. However, sometimes it doesn't work quite right: the device will connect but not function right, sometimes leading to all Bluetooth devices failing to pair or connecting and disconnecting rapidly. This may be related to the driver, although it is using the default driver. - Playback seems fine when it works. Sometimes it is randomly choppy. My understanding is that Windows 10 supports aptX but not aptX HD, and I can't get it to show up in traces but I suspect aptX is likely the codec being used. SBC is really 'good enough' for most cases though, so it's not a big deal. - Routing leaves something to be desired. Every single time the device is paired, anything that plays audio needs to be moved or explicitly restarted for it to work. For example, Firefox or Edge tabs playing music typically have to be reloaded even if i unpair and repair the headphones during playback. It also interacts ridiculously poorly with my Realtek drivers, also Windows 10 defaults. I typically have to jump into the weird mixer and try to get everything right when switching between the two, and some apps like Discord act a little weird even then. On NixOS: - Not all distros will require this, but NixOS naturally requires configuration by its nature. Here is my audio-related config, in its entirety: hardware.pulseaudio = { enable = true; daemon.config = { flat-volumes = "no"; resample-method = "speex-float-10"; }; extraModules = [ pkgs.pulseaudio-modules-bt ]; package = pkgs.pulseaudioFull; }; hardware.bluetooth = { enable = true; package = pkgs.bluezFull; }; nixpkgs.config.pulseaudio = true; environment.systemPackages = with pkgs; [ pavucontrol pulsemixer broadcom-bt-firmware ]; Most of this is NixOS specific. Some of it is personal: I disable flat-volumes because I do not like flat-volumes. I switch the resampler to a different one to prevent aliasing artifacts. (This may seem like audiophile non-sense, but it actually impacted real-time resampling chibi-tech's album "The Mutual Promise" which has 18-20 kHz sounds in it, designed to sync to some Pripara toys. Pretty interesting stuff.) In any case, it's the whole config. I don't think I ever had to trial-and-error it, I just followed the manual. So not too bad. Honestly, I fully expected it would not work. And for a long time, I never tried the setup. However, a few months ago I tried it. Here is what I found: - Pairing works. I have yet to hit an issue where pairing does not work. - Playback works, and using either Blueman or the PulseAudio mixer it is trivial to switch between A2DP codecs or, if for some reason one would want to do it manually, HSP. Once again, I have not noticed problems. I tend to use the Sony LDAC codec since it seems most appropriate for the headphones. - Routing seems okay too. I do still sometimes run into a situation where I need to switch an app manually, but it's easy to do in the PulseAudio mixer. My verdict is that the Linux Bluetooth Audio situation is not bad. Yes, no ordinary Windows user could stomach the Nix configuration in my Nix setup. However, you can notice the lack of hacks needed here: clearly, Bluez and PulseAudio are now up to the task of handling Bluetooth Audio "correctly". I haven't tried but I suspect Debian or Fedora would, with a couple of packages installed, handle Bluetooth devices just fine so as long as the Bluetooth chipset is supported. Bonus: In the future, Pipewire will take over for Bluetooth audio. For the time being it is limited to SBC and can't handle other codecs yet, but I gave it a shot and it seems to work just fine, too. Hopefully that holds into the future.

zanny 6y ago

"Killing it" is relative. Krita is roughly 500k LOCs of code proper. The KDE ki18n library that is one of its primary dependencies which extends Qts internationalization faculties is... about 7k LOCs. Almost all of Kritas immediate dependencies are small shims except for Qt itself which is produced by an already profitable corporation. So qtbase is about 2.3M LOCs but the Qt Company has ~300 employees with most of them working on it. Krita with its "killing it" manages to employ 4 people full time to work on development. That is on an install base of several millions of active users. The closest competitor to Krita is probably Paint Tool Sai, a proprietary Windows only program that is made by a for profit Japanese corporation as its largely only product that employs around ~10 people. Getting actual employment figures for Systemax Software Development is actually really hard... Point is Krita is likely shuffling along with half the full time paid employees of its principal competitor while also likely having a larger installed and active userbase due to it being free software and cross platform. They aren't "killing it" at all, especially if you compare it to the elephant in the room at Adobe with a hundred man development team at least making insane amounts of revenue off licensing of Photoshop. Its revenue is nothing close to hoist the weight of the entirety of the free software ecosystem upon when it doesn't itself come close to even competing in the field its doing a really good job competing it on a tiny development team.

CarVac 6y ago

I plan on putting up a Patreon/Liberapay for my photo editor that is purely a passthrough for the boring backend stuff that I rely on.

benlumen 6y ago

Such a great point. I feel like this explains the state of Linux desktop in a nutshell, actually.