This might be easier to understand with some context. This is the GTK maintainer, who is about to release GTK 4 in a few weeks, and GTK 4 needs some unreleased fixes in Cairo. He requested a release earlier this year.[1]
The last stable release of Cairo was in October 2018. A very simple merge request[2] submitted by Nikolaus Waxweiler two years ago has not been merged even though everyone agrees it is good because nobody has been willing to take the responsibility to approve it.
The test suite is broken and tests were failing CI for all commits for a year (until the tests were disabled) because there was nobody who knew how the test suite worked who had time to fix it. There has been a proposal by a Google intern to add fuzzers for OSS-Fuzz to find security issues—but no maintainer has the time to review it.
Yes, there are a few commits and merge requests getting merged here and there, thanks to Uli Schlachter who is still active, but this is a large graphics library with many, many features, used by thousands of applications. It is not finished and not in a good state. Web browsers and other applications that have resources to move to Skia have done so already; GTK probably will not have spare resources to do this.
> The last stable release of Cairo was in October 2018
Looking at the release history, as far as I can tell, every release since 2013 was rolled by Bryce Harrington, who at the time was employed with Samsung Open Source Group. Samsung shut the group down in... October 2018 [1].
A related question I've asked myself a few times already, with no good answer yet: is it good for the long-term health of an OSS project if it has sponsored developer(s) from a single company?
If Cairo didn't have that support, it might have fizzled out much earlier. Or a more heterogeneous community might have emerged, which would be more resilient to a single sponsor dropping out.
If anybody has data (not just anecdotes) regarding this question, I would be very grateful!
Wow, not seen that rant before! I remember the OpenMoko devs went all-in on GTK (there was a lot of hype at GUADEC, around the same time as Moblin too), but the OS they shipped was very basic, and the actual phone functionality (calls, texts, contacts, etc.) was taken from QtMobile (later renamed Qtopia, then QtExtended). Later, OpenMoko decided to ditch GTK in favour of Enlightenment, which was certainly prettier, but again the actual phone functionality was QtMobile.
According to Wikipedia Moblin became MeeGo, and MeeGo got replaced by Tizen. So it looks like the same GTK-to-Enlightenment switch was made at least twice (possibly FOMO?).
I've only played with programming Enlightement a little; so never had to encounter the horrors described in that link. As a user I really like E16 (it's my go-to non-tiling WM; but I prefer tiling these days). I never got into E17 on the desktop (it's usable on OpenMoko, but I tend to use QtExtended). I like the fact they're pushing what can be done with 2D raster graphics, since everyone else seems to be vector-based (e.g. Cairo) or 3D (e.g. Compiz); but I never found E17 appealing as a WM or desktop from a productivity perspective.
Lol I never saw that before, thanks. In the late 1990's, Englightenment was the WM that was used as the prime example of why Linux was so cool. Its terminal emulator had transparent backgrounds! (I suspect the separate 'background' element you need, mentioned in the link, has something to do with that?) Of course most of us didn't have the hardware required to run Englightenment and its advanced (for the time) graphics capabilities, but that never stopped anyone from using its screenshots as propaganda. Ah, how naive we were. Well certainly I was.
Enlightenment is what got my to try linux (Redhat hurricane I think it was) way back when.
It was very pretty and _very_ broken then, but e-term, which required a tonne of E libs, was the terminal everyone used to show off their desktop so you kind of lived with it.
I never did manage to get it running. I spent a long time trying to compile it on yellow dog linux. I gave up and used fvwm2 instead. Ah, the halcyon days of college when I had more time to waste trying to get things running.
I kinda like Tizen, but Samsung is really shockingly bad at open source. They assimilate and then try appropriate without building a community around it. Joyent public is kinda dead. There is a fork of SmartOS (Danube Cloud), which has far better documentation is much easier to run and actually runs in cheap DC environments like OVH and Hetzner and they have 2.5 active developers.
Tizen is much better in terms of battery than Android Wearable and most other wearables, has pretty decent features, but is a complete mess to get applications on and there is hardly any third party using Tizen, let alone write documentation/tutorials on its development.
All I know about Tizen is from reverse engineering my shitty Galaxy Active 2 with all the on launch promised features disabled if you don't use a Samsung phone and most of them released over a year after the original announcement.
Most people on xda-developers say that it will be their last Samsung wearable. And if you look at the numbers Samsung wearables has crashed in sales.
> I kinda like Tizen, but Samsung is really shockingly bad at open source.
I'd say the biggest advantage of opensource is that it allows "shockingly bad" code to gradually turn good, rather than being thrown into the garbage bin right away 99% of the time despite of potential for improvement.
But you negate that if you don't actually get less bad people into the project, which is the case with most projects that say "send patches, and we may not throw it away after you concede all rights to your code"
Bryce Harrington is the founder / board member of inkscape if memory serves. As far as the Samsung Open Source Group is concerned Carsten Haitzler was heavily involved with that. Carsten is also the founder of Enlightenment. I'd be surprised if there is no one on HN who couldn't get a hold of one or either of them.
I haven't played ADOM since 1.1.1 (almost 2 decades ago) but I always found it more approachable compared to the alternatives I tried.
It starts you off in an overworld and the initial progression is less linear than the traditional dungeon-delving approach of eg. Nethack and DCSS, so in that sense it feels more RPG-like.
I never really got into Nethack much because it's just so punishing, and while ADOM is definitely far from an easy game, it felt better. DCSS is also similar to ADOM in the sense that the development community tries really hard to make it an enjoyable experience.
I have played ADOM on and off for at least a decade now and have looked at the various guides you find online. Despite that I never even made it to midgame without getting killed by something. It's still a fun game though.
It was fun back in the day. I wish that the developer hadn't backed out of the promise to make it Open Source.
Mechanically, it has moderate (though polished) depth. But it has more story and unique events than most roguelikes. It benefits far more than most from playing entirely unspoiled; there's enough information in-game to solve all its puzzles.
As far open sourcing the code is concerned, I remember the author said that it would open-up some secrets which players would otherwise will have to discover. E.g existence of "inn of the red rooster"
> As far open sourcing the code is concerned, I remember the author said that it would open-up some secrets which players would otherwise will have to discover. E.g existence of "inn of the red rooster"
I've heard that argument, but people have figured out the various mysteries anyway through reverse engineering. I don't think anything would be lost by opening it up.
I find ADOM to have more intriguing story-line + multiple endings. Also I find few quirks endearing. E.g your first kill matters. If you have killed 50 goblins then you will have to descend that many levels in infinite dungeon for some other questline.
We need to get better at finding ways to pay people to develop foss. Micro transactions, Patreons, and industry groups are all good ideas. What else is there?
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.
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.
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.
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.
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.
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:
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.
On Debian one must install "bluetooth" and "pulseaudio-module-bluetooth" that for some reason are not installed by default. After that it's a matter of synchronizing things on the bluetooth GUI and if you don't want the obvious setup, deciding where the sound goes to on the mixer GUI.
But well, when I brought my current earplugs the mic didn't look like it was working on my (Android) phone and searched the web for it, I discovered that many lines of JBL plugs aren't supported on Windows by default. There are devices that only fail to work on Teams, or Skype, some only work on those applications, some reproduce anything except audio from videos (all issues confirmed by the manufacturer).
As of late this summer I was unable to get my BT headphones to work on Fedora in a 2-way transmission mode. The speakers would work but not the microphone. I don't remember the details but when I dug deep into the issue, there seemed to be a fight about merging a PR that would allow it.
There are no longer many things keeping me from going all-Linux but I am not going to sit through every meeting chained to my desktop with a little earbud wire.
Hopefully pipewire will resolve this, and I don't think any of us realized in advance what meetings were going to look like in 2020.
If it isn’t working, you might need to switch your headphones to the HSP profile. You can do this in Pavucontrol, the last tab with the devices. I prefer using wired headphones or at least a wired setup for this because HSP is piss-poor quality. But the quality issue, at least, is nothing especially new for BT devices on calls.
Most Bluetooth devices work fine for me with Fedora, but I still haven't been able to get my Bose quietcontrol headphones to work correctly - they pair but then start playing random noises and telling me there's an incoming call.
I have some wired headphones I prefer in general so haven't messed around with it too much, but it's been a source of frustration when I've been away from home and needed to do a call with only the Bose ones on me
>start playing random noises and telling me there's an incoming call.
Open your bluetooth settings and change the mode from HSP/HFP to A2DP mode. That incoming call issue happens in HSP mode because something has tried to access a microphone which has defaulted to your headphones mic which causes the bluetooth mode to switch.
While I agree that Bluetooth audio on Windows is crap, its saving grace is that when it works, it's stellar. I have the same headphones as you, and audio quality is consistently significantly better on Windows than on Linux (most notably when I'm also using the microphone).
I think with standard Bluetooth, recording will necessarily kick you to HSP with terrible phone quality. This happens to me on Windows and Linux, with my Sony WH1000XM3s. If there is a workaround please let me know. I am sure there are some non-standard extensions but I don't think my headphones support them.
If you are experiencing "bad" quality on Linux, you probably would benefit significantly from installing the additional codecs. Linux is the only desktop operating system that supports basically all of the Bluetooth audio codecs! But of course, they're patent-encumbered (except Sony LDAC) and thus not typically included by default.
Disclosure: I am a Snowdrift.coop cofounder. I have no financial stake in the project (we're a non-profit cooperative and currently a fully volunteer team), although I hope in the future we'll have the income to hire me, for a modest salary.
> 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.
Public infrastructure gets financed through taxes and is performed via executive departments or government contracts, sometimes as academic research.
Software may need to adopt this model.
It's ocurred to me that ancient symbolic megaprojects (e.g., pyramid-building) may have played roles in developing and maintaining technical skills, supply chains, and generaal interest. All the cool hard problems, great minds, and stable funding.
There is already implicit political control. If the US wants to ban X, or forbid encryption, it will impact almost everyone on the planet. Much less so if it were Afghanistan, of course.
The EU has a funs that donates money and runs bug bounty programs for critical FOSS software it uses. It should be expanded to include more underlying libraries and lower-level projects, but it's a pretty good start and doesn't come with strings attached.
I've always liked the idea of getting companies to sign up to second staff members for a month or two to full or part time open source work. They could get a nice friendly looking "open source supporter" badge for it, like the Fair Tax Mark. It'd take a small organisation being clever to do it but I think it'd work and free up lots and lots of hours of work to be done on valuable stuff.
FOSS purists object, leading to the libre vs gratis rabbit hole.
I'm now revisiting Hintjens' (ZeroMQ) advice around trademarks and licensing.
Maybe there's an angle around trademarks. Like maybe you can call your fork "SuperWidget™ compatible", for a fee.
Dual licensing seems obvious. But maybe we need some new revenue sharing licenses better suited for cloud providers and SAAS. (A life time ago, I used libraries in my shrink-wrap. So negotiating price feels familiar to me.)
Libraries kinda "feel" like music sampling. So I've been skim reading how that world handles royalties. I like that they have boilerplate for all the most common scenarios.
I'm also alert to case studies and financial reports about existing efforts, successful, failed, or otherwise. This solution to funding might just be as simple as mimicking success.
Writing to standards, such that when one implementation is in trouble, there's a migration path to use another one, and a motivation for multiple implementations to exist in the first place, via a layered and contained API that can be implemented from scratch (unlike browsers and over-reaching desktop and system frameworks). Of course, this doesn't work with our ADHD-driven development scene longing for fresh programming languages all the time which gets you half-finished implementations until the next thing comes along.
We need money being able to be transfered to the once doing open source. Still many of them hack voluntarily and out of pure altruism.
What should be transparent is the amount of money they receive. It should be the oss project leaders responsibility to further distribute the donations. Using bitcoin for transparency. Nobody is going to work for an oss project where the leader gets all the money and doesn't redistribute.
Many intermediaries, institutions and paperwork will ruin that. My 2c.
Why not fork it? The usual reason to upstream patches (aside from charity) is to offload the work of integrating them with future upstream changes. If upstream is not making changes anymore, what’s the problem?
Perhaps the concern in forking it would be that the group that creates the fork now has the responsibility of maintaining another project, on top of the project(s) they already maintain.
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.
I've been anticipating a new cairo release for some time. The same Mathias Clasen who wrote this email has done amazing work at getting Pango font rendering a lot closer to what is possible on Windows and macOS. The killer feature for me is subpixel positioning of glyphs [2]. He made these changes over a year ago. The result would be all GTK apps being able to perform much finer grained glyph positioning, potentially fixing a lot weird font positioning issues that bother me in GTK apps.
But for any distro to make use them this needs a cairo release with his patches built in. I found myself periodically visiting cairographics.org just to see if there was an update ready for the next Ubuntu or Fedora. Never done that before for a "boring system package"...
[2]: The topic of font rendering always evokes responses like "Fonts look fine to me" - good for you, but this actually bothers quite some people. See also: https://pandasauce.org/post/linux-fonts/
You wrote that with such passion that I read the articles.
As a caution to people think the font rendering is fine - DON'T read the articles! You cannot unsee it.
Note that just updating Cairo will not automatically bring subpixel positioning to Gtk. Pango still defaults to rounding glyph positions to full pixels (rightly so, as there's no released version of Cairo that would render it correctly otherwise), and there's absolutely no code in Gtk that would allow disabling this rounding. I reminded Matthias about this half a year ago: https://gitlab.gnome.org/GNOME/gtk/-/issues/7#note_795665 but it still hasn't been resolved (the issue is marked as closed but that, I believe, is a mistake). I suspect they're not going to enable this in Gtk until Cairo with support for subpixel positioning is released.
Which made every single glyph on my laptop a blank rectangle. I guess there's a reason people don't want to take on the responsibility for these critical packages; who knows what horrible workflows you'll break!
I couldn't even begin to understand why the changes required the removal of this feature. But I won't complain, at least someone's doing the hard work.
This is such sad news. I remember playing with Cairo a few years ago and the library (and documentation, especially) felt lovingly put together.
Few projects ascend to the astral planes of immortality. Even Xorg is on the way out. Computer look and feel is very nostalgic and I hope to visit an API museum when I am older, to e.g. look back on fond memories of using repl.it so much in 2020.
(Tip to any young people who read this far: take lots of full desktop screenshots as you work. You’ll enjoy looking at them in 20 years time.)
Yes, this is sad. I remember integrating Cairo into a project I worked on a number of years ago.
At the time, pulling in an open source project was a big ordeal. You had to figure out how to build it, getting all the configuration options correct, pulling in all the dependencies, configuring them, etc. I set aside a whole afternoon to get it working.
Anyway, I pulled it down, built it, and was writing simple drawing programs in about 15 minutes. It was amazing.
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.
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).
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?
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.
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).
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.
Says the one who made the best/most_complex open source one rather than use QPainter ;)
But really, QPainter suffers from a lot of the same issues as Cairo (and then some). The main "problem" with them is that they are CPU bound. Both of them have OpenGL backends, but they are not "really" faster. There is also the fact that the Qt Company doesn't invest in it anymore since QtQuick2 was released. Because of that, it doesn't get some of the newer Skia features. So Cairo/QPainter are pretty good at server side rendering. Qt was never popular for that use case. Cairo used to own that market, but it's usage is declining due to the maintenance inactivity issues. Also, once upon a time Cairo was used in Firefox and Chrome, so it's SVGs tend to be rendered more accurately in modern browsers than Qt ones.
Skia itself is an unsustainable library to depend on. Its API and behaviour isn't stable. Google doesn't really care about non-Google use cases, so the CMake is broken 90%+ of the time. It adds a large maintenance burden on projects trying to use it. Distributions also hate it for being impossible to package reliably. In turn, it makes hard for smaller projects to migrate away from Cairo because users have an easier time getting their hands on Cairo than Skia.
(bias disclaimer: I worked with both as a KDE dev and as the AwesomeWM co-maintainer, a Cairo based project. A lot of the recent unreleased Cairo commits originates from the AwesomeWM community, but not from me)
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
Hi dang, i don't know where else to contact you. I see you posting comments about there being multiple comment pages. Is there anything that could be done to avoid that, like allowing more comments per page (e.g. up to 10 of the current pages?), infinite scrolling, having a more visible "more pages" button, having the button not only at the bottom but also at the top, etc. ?
If there’s nothing else clickable around the graphical element then making a larger but invisible touch target around it would be an approach to consider. No visual changes, easy to do with css etc.
We changed the title from "Cairo Is Dead", which is a phrase from the email, to a perhaps more representative phrase from the email. (shortened to fit HN's 80 char limit)
Have you ever considered increasing the title character limit slightly? The current limit can have quite a constraining effect on some titles, sometimes to the detriment of the thread.
It's true, but any limit will have a constraining effect on some titles. We have to weigh that against other concerns like the visual proportions of the front page and the site value of economy of expression.
Having worked with thousands of HN titles over the years, it's amazing how rarely the 80 char limit really gets in the way. It's nearly always possible to make a good title fit, without resorting to weird abbreviations or other gimmicks. So I see it as one of those constraints that serves creativity.
You can see this in the OP actually. The direct quote is:
Is there still somebody around in the cairo community who is willing and able to make a release?
...which is 96 chars. The shortened version seems clearly better as a title, and all I did was take out some redundancies (or, if you prefer, some subtleties that are superfluous in a title).
Edit: if anyone's wondering why so much attention on a mere title - I used to wonder that too, but titles turn out to be a much deeper issue for the site than they at first seem:
Okay, my question is: if a project is really in maintenance, what should be the duties of its maintainer?
The problem is: there are contributions, there are pull requests, they even get merged. The code gets reviewed, and it’s not an easy feat.
And while it’s all being done, whenever there’s a question of making a tarball, attaching a number to it, making sure the changelog has all it needs to say, people who do code reviews and merge requests suddenly all start feeling tired and bored. Too bored to slap a tag on a repository, too bored to roll a tarball, too proud of being a bottleneck.
Maybe a robot could do releases? It could even build GTK against the newly minted release and run its test suite too...
The reason I didn't use Cairo in the past is that it wasn't dealing with color correctly[1]. Which kinda makes everything you draw in it with antialiasing or transparency ... wrong.
At least if you care about these things which I do for the use cases I have for a vector graphics lib.
Did this get fixed in the meantime? Last time I checked this[2] was still open.
Hey how about we all stop treating open-source software like a startup company? An open-source project doesn't "die" just because it stops getting updates. If people want updates, they can go download the Cairo source and contribute. Or fork it. But no, it's dead. It's all over. By that logic, humans are "dead" because we haven't evolved extra appendages or more eyes recently.
I agree with you, but that doesn't seem to be what's happening here. It looks like people are contributing, but that the contributors are realizing that the maintainers/leaders have all vanished.
So really there are 3 possible outcomes here:
1. the contributors pressure one of the maintainers to come back,
2. the contributors get in touch with one of the maintainers and convince them to promote some contributors to maintainers, or
3. the contributors fork Cairo, because they can't get a maintainer involved.
The email comes from a contributor, who is effectively saying "last call for (1) or (2), and then I'm doing (3)".
Forking is the ideal solution here. Leave Cairo what it is and continue development in the direction you want. In time those changes can be merged back in if the orginal project continues.
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.
I remember a linuxconf from around 2000 or so where they announced cairo. It was pretty exciting stuff, and over the years I have used it for various projects. The latest is this one
https://github.com/punkdit/huygens
I feel like the post title should be something closer to the email, like one of the first lines "Is there still somebody around in the cairo community who is willing and able to make a release".
Not just what 'aaronbrethorst said; Cairo isn't just a 2D graphics library, but it is the foundational 2D graphics library that underpins most of the modern GNU/Linux desktop: It's what's used by gstreamer, GTK+ 2, GTK+ 3, Java... and if an app manages to avoid using any infrastructure that uses Cairo (Qt doesn't), if the app does 2D graphics things then it's likely that the app uses Cairo directly.
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.
Um, no it doesn't. JavaFX/OpenJFX doesn't use Cairo anywhere. Some references appear in the codebase but only via the WebKit import.
Neither JavaFX nor OpenJDK use Cairo for drawing and AFAIK never have. I don't know where this idea comes from. They use a pure Java 2D engine called Marlin when doing CPU based rendering. JavaFX is normally hardware accelerated though, in which case all drawing is handled using shaders and its own graphics engine.
>First of all, when I say "Java", I mean OpenJDK; things might be different in the Oracle side of the world.
OpenJDK is the Oracle implementation under a different license. When the Oracle Java team makes code changes, they do so to the OpenJDK code base.
There are very minor differences that are part of the packaging work Oracle does, such as slightly different wording in the copyright statement that's printed with the -v CLI option.
I know that they share code, and that the Oracle Java team commits to the OpenJDK code. If they're actually the same right now, idk, bit it's often been the case that they aren't. It's often been the case that the OpenJDK JRE and the Oracle JRE have different performance characteristics. Oracle JRE 8-10 bundled JavaFX, while there was no JavaFX for OpenJDK (in JRE 11 Oracle open-source JavaFX as OpenJFX).
Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output. Experimental backends include OpenGL, BeOS, OS/2, and DirectFB.
I'm only aware of Cairo from 3b1b manim, where it's one of very few named dependencies (cairo, ffmpeg, sox, latex). https://github.com/3b1b/manim .. Maybe he'll rewrite it in Julia :)
AFAIK one issue with Skia is that its API is not stable (and it is written in C++ which makes stability kinda hard) whereas Cairo's API has been stable for a long time.
Side note: Skia can't render SVGs directly. You need a separate library to do the parsing and issue commands to Skia. I think they might have experimental support for simple svgs committed in the repo, though.
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.
https://blend2d.com/performance.html
The official benchmarcks show that blend2d isn't significantly faster than QT or Cairo renderers and it is common wisdom that Skia often order of magnitudes faster than them.
I talked to the blend2d author ~ a year ago and he will not publish skia benchmarck until it's new "more parallel" version of blend2d is ready which imply he is skeptic that current blend2d is competitive with Skia.
Fastuidraw is the only renderer to have shown benchmarcks outperforming skia but it is mostly unmaintainef today and the benchmarks weren't representative
Do you think it's right to state something because of "common wisdom"? Claims like "order of magnitudes faster" should be supported by a reference, because from my own experience making something order of magnitude faster is really difficult and sometimes impossible. This is btw why Blend2D provides a benchmarking tool, to not claim something that cannot be verified.
I'm the author of Blend2D and I have never stated what you claim I did. I just gave up trying to compile SKIA. The benchmarking tool Blend2D uses is open source, maybe you can contribute SKIA backend to the tool and use it as an evidence? Otherwise all you say is just unfounded, sorry.
BTW SKIA team was positively impressed by the performance of Blend2D when it came out and we are in contact. I would not be surprised if SKIA started using similar techniques like Blend2D - for example JIT compiler. They are exploring new territories like Blend2D does.
OK so it's not common wisdom but expert wisdom:
Quoting Pcwalton (working on a next generation 2D renderer: pathfinder)
How do Skia and Cairo compare?Skia is way ahead in terms of performance and GPU support.
A lot of major projects like Firefox and libreoffice switched from Cairo to Skia and got significant performance gains.
How much faster in average is skia vs Cairo? A lot but precisely I don't know and it doesn't matter much.
I just gave up trying to compile SKIA. Come on, don't make it sound like it's a hard task, on the github issue from blend2d someone gave to you a repository that include a Cmake for skia which should be straight-forward.
Claim:
he will not publish skia benchmarck until it's new "more parallel" version of blend2d is ready which imply he is skeptic that current blend2d is competitive with Skia.
Claim denial:
I'm the author of Blend2D and I have never stated what you claim I did.
What you actually said:
I think comparing with GPU implementations would make sense after multithreaded renderer lands, because competing GPU implementations use the whole GPU hardware whereas the current Blend2D software-based renderer only uses a single thread.
Would make sense easily translate to I'm not interested in doing it until there is a point in doing it which is: a fair comparison.
Source: https://github.com/blend2d/blend2d/issues/36
Otherwise all you say is just unfounded, sorry.
Original statement:
Blend2d is still slower than skia
Backed by expert wisdom comparing skia with cairo showing huge performance gap.
Blend2d own benchmarcks not having a that huge performance gap with cairo (but it has kinda with the multithreaded mode I give you that)
Then the logical reasoning become basic transitivity/equivalence relation
To state that what I said is unfounded is a low effort refutation because it is too categorical. In all honesty my reasoning has weakness: I don't have precise quantification of the lead that Skia has over cairo (maybe there was some benchs on the NVpath paper?) and multithreaded blend2d do have a quite significant gap with cairo.
So optimistically, current blend2d might actually come into the ballpark of Skia, it could even outperform it but probably not by a huge margin.
And keep in my that the baseline performance I expect from skia (very old benchmarcks and expert wisdom based on old benchmarcks) has probably improved since recent years (e.g one could think about more AVX512 use, the Vulkan backend, etc)
So I'll transform my original statement in an equivalent one consequence wise:
Blend2d is still slower than skia to: Blend2d has not shown evidence of being faster than skia, nobody should use it until this evidence become available.
I'm not going to contribute, sorry.
Your last paragraph is interesting and that would be quite of an achievement of you if Skia tried a JIT compiler.
Ok, so you cannot prove it, which means that I must prove otherwise?
I wrote exactly what you cited in May 2019, but it was not about SKIA. And if you continued reading you would have noticed that multi-threaded rendering context implementation is already provided. So, I don't really understand what is your point here.
There are Blend2D users that started using the library based on their own benchmarks that compared Blend2D, SKIA, and also AGG. So there are already users that use Blend2D instead of SKIA based on their own benchmarks, and I think that's a much saner approach than following your "expert wisdom".
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.
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).
No release for a few years now. So a lot of bugs in the last release.
Theoretically there is a maintainer but they haven't done any releases. Some bug fixes have been merged into the git repository, but most distros seem to use the last release.
Make sure to read the hint here: "Someday ImageMagick will finally break for good and we'll have a long period of scrambling as we try to reassemble civilization from the rubble."
Politics is a realm the average person has no power in, yet many adhere to tribal, cargo cult fashions and canards that divide-and-conquer people into atomized groups of one. Is that political or apolitical? ¯\_(ツ)_/¯
Throw politics out the window and get behind policies individually.
nanovg has nowhere near the same depth of features as Cairo though. I for one have been using Cairo's software renderer and any GPU-only library is a no-go for my project.
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 :)
Well what I'm saying is quite obvious, I'd even say it is a truism, yet hn readers often downvote even the most basic statements (probably by lack of understanding the topic).
But here you ask constructively so I'm gonna answer pedagogically:
Skia and Cairo are two of the most used 2D renderers.
A 2D renderer is an angular piece of software used by every GUI software. It has a key role in 1) rendering correctness (anti aliasing, no bug, no tearing) and 2) rendering performance.
2D renderer performance is key for all graphical workloads, from the scrolling/animation performance of your browser to the smoothness of any non cli software.
As humans we strive for progress, we want tomorrow to be better than now, therefore we want more correctness and more performance by 1) improving 2D renderers where it matters the most and 2) making sure that the right 2D renderer is used by softwares.
For example a big reason of slowness of Firefox a few years ago was because they used Cairo, by switching to Skia they got "free" significant performance gains for the pleasure of all users and even for the pleasure of HN readers currently scrolling this thread.
Skia is the only renderer to have a lot of human resources allocated to it (thanks to Google) and this translate by it being the most performant 2D rendering, sometimes by order of magnitudes.
But skia can become even better by integrating new optimizations, Vulkan, NVpath, AVX, etc
So now you can understand the original statements:
Everybody should switch to Skia
This means that new and existing software would significantly benefit from switching from Cairo to Skia (this argument was sufficient before the news but is even more important now that Cairo is unmaintained)
As an end users you will probably get more FPS, accuracy and lower power consumption (which is ecological btw).
This thread about Cairo being unmaintained could attract potential new contributors.
Instead I'm saying to those new contributors:
New human resources if not allocated on Skia should go on next gen renderers like fastuidraw
Because their work if on Skia would benefit order of magnitude more people.
Else they could work on next gen renderers, having talked to the devs of blend2d, fastuidraw, etc I have big doubts they'll ever one day be able to replace skia (too many missing features e.g full SVG compliance) but their performance paradigm shifts could be backported into skia once proved, so contributors could have a huge impact here too.
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?
Sorry, but general sweeping statements about what everyone should do or not do are annoying to no end.
But rest assured I don’t intend to pursue more of the kind of responses like the one I’ve posted above, because it has already brought me joy and made me feel good.
The last stable release of Cairo was in October 2018. A very simple merge request[2] submitted by Nikolaus Waxweiler two years ago has not been merged even though everyone agrees it is good because nobody has been willing to take the responsibility to approve it.
The test suite is broken and tests were failing CI for all commits for a year (until the tests were disabled) because there was nobody who knew how the test suite worked who had time to fix it. There has been a proposal by a Google intern to add fuzzers for OSS-Fuzz to find security issues—but no maintainer has the time to review it.
Yes, there are a few commits and merge requests getting merged here and there, thanks to Uli Schlachter who is still active, but this is a large graphics library with many, many features, used by thousands of applications. It is not finished and not in a good state. Web browsers and other applications that have resources to move to Skia have done so already; GTK probably will not have spare resources to do this.
[1]: https://gitlab.freedesktop.org/cairo/cairo/-/issues/422
[2]: https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/...