[cirno]

Can we talk about why projects need to be actively maintained and extended indefinitely? Cairo paints things. It does a good job of it. What's wrong with it? Leave it on Git, accept pull requests, check it once a week/month, you're good.

[necubi]

Something as foundational and important as a 2d canvas library is never going to be "finished" and can't just be abandoned aside from the occasional security fix.

Examples of things you would need to have added in the past few years to stay competitive:

* Vulkan support

* Emoji support (although I'm not familiar enough with Cairo to know if shaping is part of the library)

* Rendering in compute shaders

* New platform support (like MacOS arm or Android)

Already many users have switched to Skia which continues to make progress in all of these areas (and which is much faster).

[Lammy]

> (although I'm not familiar enough with Cairo to know if shaping is part of the library)

That would be its sister project Pango:

https://blogs.gnome.org/mclasen/2019/05/25/pango-future-dire...

https://bugzilla.redhat.com/show_bug.cgi?id=1753295

[jolmg]

Why does it need development of new features to not be dead?

Calling it dead implies that projects that are currently using it shouldn't use it anymore, but projects for which cairo as-is suffices will continue to work with the features that cairo already has, so why would they need to migrate?

[necubi]

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.

[toast0]

On the other hand, your competition may be using a dead rendering library and have a UI that is twice as fast as a result.

Recent commits doesn't indicate much in terms of security, fit for use, or quality. All it indicates is recent commits, and hints at reachability of the authors if you need to ask them about their intent (if code is unclear) or for license alternatives (if the license is unsuitable).

[inbx0]

> that is twice as fast as a result.

Yeah, or it could be the opposite. The newer, shinier alternative could also be faster, less buggy alternative.

[pessimizer]

Then (in the hypothetical) you should use what your competition uses and not use Cairo; Cairo wouldn't be vying for your attention, and Cairo doesn't make money when you use it so wouldn't care what you use. If there's a FOSS competitor worth leaving for, that means the environment is healthy.

[zepto]

It doesn’t really in this case.

The only alternative is maintained by Google and is much harder to use.

[boudewijnrempt]

skia isn't the only alternative. Qt includes a pretty complete 2D painting engine as well.

[noobermin]

The js programmers and their ilk form our opinions these days and they certainly don't care about needs in more than a year because they hope to sell their wares by then and move on.

[conductr]

Isn’t that the purpose of flagging something as depreciated? It’s a warning for you and a warning for people currently using it that it may/will go away in the future.

[bjourne]

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.

[binarycodedhex]

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.

[Ologn]

Yes. Oh my goodness, look through the open issues. Look at the pull requests.

What is the big O run time of the various functions? Sometimes someone pops in from a university and knows how to improve an algorithm and shrink its runtime, perhaps based on the latest graphics research, perhaps based on old research which was somehow missed.

[LukeShu]

> Leave it on Git, accept pull requests, check it once a week/month, you're good.

That's exactly it, this is essentially a contributor saying "hey, there are a bunch of contributions, can a maintainer please check in this month?" If you don't check in once a week/month, then you're not good.

[danilocesar]

This reminds me those managers who use to say "It's just a little 'IF' here and there" and you find out a lot of hidden/broken corner cases.

[accurrent]

Uhhhh.... Not at this scale. Thats what I thought about one of my previous open source projects. I was a naive highschool kid back then I thought open source is great. Let anyone use it. Yay! The one fine day someone raised a PR (this was back in 2012 when CI was not very common). It looked OK and I merged it. The following weeks had me battling issues with people using the library. Eventually I abandoned the project cause I didn't have the time/funds/motivation to continue working on it and there were better solutions available on the market.

[yxhuvud]

Perhaps it is a sign the project is too large and need to be broken up in more manageable parts?

[accurrent]

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.

[adamjb]

Sounds like we've got a volunteer!

[indolering]

Exactly. For all of the wailing and gnashing of teeth around replacing X windows with Wayland, no one has stepped up to maintain X.org since Red Hat stopped funding its development. Old code isn't bad because its old, its bad because engineers decided it wasn't worth the minimal effort required to accept and release security fixes.

[orra]

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.

[indolering]

I mean, agreed! But in my mind X windows itself is a major security hole: every application can snoop on keyboard and mouse input of every other application. Beyond simple bug fixes, Wayland is the next step in fixing the more fundamental issues with X.org's architecture.

[jolmg]

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.

[saalweachter]

I think the problem is that metaphors have legs.

We like to talk about software as architecture. You design a thing. You build a thing. It is built.

Except, real architecture doesn't work that way, and it turns out metaphoric architecture doesn't either.

If you walk down the street long enough you will eventually see a house that is unmaintained. It wasn't broken to begin with, and no one broke it outright, but over time the paint (and shingles) have peeled, rot has set in, and now the foundation is cracked and the frame is starting to sag.

Even maintenance isn't always safe. Sometimes you're up on the cathedral, fixing the roof, someone flicks a cigarette butt the wrong way and it doesn't matter how well it was architected 800 years ago, it's on fire now.

We thought our digital creations were free from the decay or physical ones are subject to, but it turns out we were wrong, because even if the bits themselves don't actually rot, the digital environment they are living in constantly changes, and it amounts to the same thing.

[nwah1]

Even that kind of minimal effort is probably not worth it and provides a false sense of an active project capable of patching security vulnerabilities and so on.

[jolmg]

> false sense of an active project capable of patching security vulnerabilities and so on

Development seems active. Last MR/PR merged in was 2 days ago[1]. Isn't all that's lacking is someone to pack changes into a tarball and call it a release?

[1] https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests?...

[qwerty456127]

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

Can't this be automated?

[nl]

Please go right ahead...

[qwerty456127]

I would, but I have zero skills in bash and in make and rather low skills in C. Aren't these the technologies used here?

I doubt people would appreciate if I wrote them build scripts in Scala ;-)

[ncmncm]

As the Brits say, "Good man!".

Meaning, you just volunteered.

[tln]

You missed "release new versions". Which apparently this project can't do anymore...

[qwerty456127]

Why would anybody even need releases anyway? Why not just clone and build the repo as it is? Most of the AUR repository packages seem to do just that.