Is there still somebody in the Cairo community who is able to make a release?

> is it good for the long-term health of an OSS project if it has sponsored developer(s) from a single company?

Surely, the answer is "no" in absolute terms. In relative terms, however, the answer is "better than none" most of the time.

Having anything you care about being in a single failure domain is a bad idea.

- A single company is a bad idea. - A single maintainer is a bad idea. - Maintainers from a single country is a bad idea.

So yes, having all of your maintainers in one company is bad for long-term health.

But 1 is better than 0!

Ah, I'd forgotten about Enlightenment. Did Samsung give up on it? I am reminded of this wonderful post on thedailywtf:

https://what.thedailywtf.com/topic/15001/enlightened

How would you compare ADOM to other rougelikes? (Nethack, DCSS, Angbad, etc.)

"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.

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.

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.

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.

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.

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

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

> Snowdrift.coop, a non-profit cooperative platform for funding freely-licensed works everyone can use and share without limitations.

>Our core feature is a new fundraising approach we call crowdmatching. Patrons donate together by all agreeing to match one another instead of donating unilaterally.

Edit: so, everybody donates the minimum donation of all donations? The "How it works" page is not clear enough.

This is a big part of Kurt Mendelssohn's thesis in The Riddle of the Pyramids, which is a very enjoyable read: https://en.wikipedia.org/wiki/Kurt_Mendelssohn#The_Pyramid_T...

Also, I am pleased that this discussion is in a thread about Cairo.

Do you want political control over key internet infrastructure? Because that's how you get political control over key internet infrastructure...

If it were tax donation incentives I bet people/companies would do it.

A part of me thinks that sounds like a fun retirement project, to become the primary maintainer of a useful but unglamorous OSS project; another part of me, looking at how my predecessors (already-retired programmers) apparently disagree, suspect that by the time I retire I'll either not want to deal with the burden, or have more fun things to spend my time on.

If I'm deciding what library to use, I'm not only concerned with whether it meets my needs today, but also whether it will meet my needs in a year or two. I don't necessarily know what those will be but I want to know that the core libraries I'm relying on will keep up with the industry so that my application isn't left behind without a costly rewrite.

Just as a simple example, if my competition is using a non-dead rendering library and their UI is twice as fast as mine as a result, I'm not going to be happy.

Because Cairo was an attempt to abstract drawing operations over multiple heterogeneous drawing devices. In theory, Cairo should give you accelerated OpenGL rendering, PDF rendering, GDK rendering, PNG rendering, Win32 rendering, etc behind a "convenient" PostScript-like interface. Thus, when these devices gets new features Cairo must also be updated to exploit these new features.

That was the theory behind Cairo. In practice it never worked out and Cairo wasn't able to fully exploit hardware accelerated rendering. Cairo was very complex so it wasn't easy for the maintainers to keep all the various backends up to date.

Consumer-oriented novelty obsession (new == better + secure) and code churn "job security." If something works and is quality for what it does, it works. Does "ls" really need to be perpetually maintained with minor, inconsequential refactorings if it already works perfectly?

If something has bugs or lacks features, then it needs maintenance. "Maintenance" for pushing out versions to fulfill expectations of "maintained" is pointless.

In my case the problem was: High school kid who is good at coding != software engineer (there are many other nuances to SE, including team management/planning/etc.)

In Cairo's case: Waaaaay too many projects depend on Cairo as a dependency either through GTK+ or otherwise. You will be breaking heaps of backwards compatibility.

Accepting security fixes isn't sufficient to keep software secure.

In the past few years X.org had some major ancient holes discovered. If the authors of the fixes hadn't bothered writing the fixes, I doubt many other people would have stepped up.

Exactly? Their comment doesn't follow at all. cirno asks why continued development is necessary. That isn't addressed at all by telling them to volunteer. They're asking why anyone at all needs to do that. The point being that cairo should be very mature and stable by now.

> someone to pack changes into a tarball and call it a release

Can't this be automated?

As the Brits say, "Good man!".

Meaning, you just volunteered.

I submitted the link and it's been pointing to this email since the beginning.

The issue with forking is that you take on a lot more responsibility than you did by submitting a PR.

Many of the people submitting PRs probably already contribute to projects that depend on Cairo. They may even maintain those projects. They may not have spare bandwidth to take on the maintenance of Cairo too.

> Pressuring maintainers to come back is foolish.

Unless that pressure has some impact on the maintainer's boss(es).

First of all, when I say "Java", I mean OpenJDK; things might be different in the Oracle side of the world.

My naive answer was going to be that, from Java's perspective libcairo is part of the underlying OS. But when I wrote my original post, I was taking the fact that libawt_xawt (the awt implementation for X11) links against Cairo at face-value. But looking a little closer at that, it only uses Cairo in its integration with GTK+ (as GTK+ uses Cairo).

Now, OpenJFX (which you could quibble about whether it's "part of" Java) uses Cairo extensively in its implementation of using HTML/CSS for Java UIs.

Skia has been around for 15 years (open source for 12) and is used in a number of high priority projects for Google (e.g. Android, Chrome). It's incredibly unlikely it will be killed any time soon.

It's used by Chrome, Blink, and a lot of other projects, so unlikely to be killed any time soon.

Can you post a link to any benchmark that would prove that?

It's not the most fun project to build, but not that hard following the directions here: https://skia.org/user/build.

I've even been able to get it to build on a Pi (although that took more elbow-grease).

Also, if you're using Rust, the rust-skia [0] project provides prebuilt binaries for a bunch of platforms and using it is as simple as putting it in your Cargo.toml.

[0] https://github.com/rust-skia/rust-skia

It used to be really hard, though I believe there's now experimental cmake support. Vcpkg has it, so if you're using that, it's much easier.

Argh! Package dependency hell of the second kind: mandatory requirements. It could be A Good Thing™ parts are being rewritten in Rust, but the costs, performance, and modularity of maintaining vs. ditching cairo needs to be weighed. Having two SVG rendering engines would have advantages (choices) and disadvantages (compatibility, security, code bloat).

Weird, I guess the first comment on your HN account isn't allowed to be political.

Well the software rasterizer is the most important to me, but lack of dashed strokes are a problem too. I'm also potentially going to use Cairo's recording and Postscript/PDF surfaces, but it's understandable if those go beyond the scope of your project :)

Yep, that makes a lot of sense. Skia appears to be BSD licensed which is good. Not having used either, are the capabilities of Skia a superset of Cairo?