11 ms·

Why do we keep building rotten foundations?

216 points by nkurz 10y ago

rurban 10y ago
Now I understand the new attraction for KDE with its new plasma release. They script in javascript. I already quit GNOME with its GNOME 3 iteration desaster. So the fish doesn't only stink at the head, also at its tail. Didn't know that, thanks. Liked this comment: Well, in the words of my two favorite software dev related quotes: > ‘How could the wise man build his house on the sand? How could the wise man build his house, where there is no foundation?’ — Eek a Mouse, Noah’s Ark > ‘The only way a wise man would build his house on the sand is if it was just a hut and he was really high and really enjoyed building new huts.’ — random youtube comment on the above song (sadly I forget who the sage was that wrote that)
gato1313 10y ago
Interesting thread: thanks. I have a gtk2 app I built over many years (gtkmm2.4 to be precise) that I have not ported to gtk3. It is a sophisticated app that uses pulgins (webkit, mplayer, custom, etc). I was thinking maybe I shouldn't spend effort in porting to gtk3. I'm considering going UI free like mpv dose with their video player. Does anyone here have experience in this area and develops plgins for browsers. What are the interesting technologies in this area?
kazinator 10y ago
> Since when does “X.0” not designate a stable release? Oh, approximately since Microsoft gained a lead in personal computing in late 1980-something, and decreed that henceforth, systems shall be expected to be a broken mess until version 3.x.
jwatte 10y ago
In this case: Because it's more fun and personally rewarding to do new stuff, than fight the hard compatibility fight. In startup API cases: Because it takes 10x longer to build a solid foundation, and you don't yet know whether that's worth it -- time to proof is more important. And once you have proof, well, you can't change it easily...
- throwanem 10y ago
  > it's more fun and personally rewarding to do new stuff, than fight the hard compatibility fight Thirteen years ago: https://href.li/?https://www.jwz.org/doc/cadt.html https://href.li/?https://www.jwz.org/doc/cadt.html And we're still complaining about the very same problems in the very same project. Edit: God dammit, jwz. Sorry, everybody. Should be safe now, I hope. (I can't see the troll for myself, so I don't know for sure, but if this thing strips the header like it claims to do, that should solve it.)
  - xeromal 10y ago
    NSFW: Picture of a testicle
    - throwanem 10y ago
      What?
      - omnibrain 10y ago
        jwz doesn't like Hacker News so he redirects traffic from Hacker News to a picture of a testicle.
        therestisgone 10y ago
        static hosting is hard
      - kuschku 10y ago
        JWZ redirects all accesses with Referer: news.ycombinator.com to this image [NSFW] http://imgur.com/32R3qLv http://imgur.com/32R3qLv
        mosselman 10y ago
        Haha, some might argue that he has a point.
mosselman 10y ago
Ironically written on/in Wordpress.
- throwanem 10y ago
  Why not? The mashed potatoes have settled into something that's shaped vaguely like a bookshelf and less likely to collapse into a pile of mush than most of the alternatives. If it's that or pile books on the floor...
- jordanlev 10y ago
  For all of wordpress's problems, backwards compatibility and API stability definitely isn't one of them! Their dedication to backwards compatibility is very impressive (and probably the biggest factor as to why the technical underpinnings are still such a mess after all these years).
jkot 10y ago
Use QT if you want stable API. GTK3 breaks compatibility even at minor releases.
- kuschku 10y ago
  Sadly, both Firefox and Chromium still run on GTK3. Especially Firefox is annoying, as their recent update to Gtk 3.20 broke a lot of things for me. If they could just use Qt instead... but nooo...
  - digi_owl 10y ago
    I jumped to the extended support channel, knowing it would come. Ironically this means that Firefox on Windows have better backwards compatibility (XP) than Firefox on Linux. If push comes to shove i am pondering moving to Seamonkey.
    - qu4z-2 10y ago
      Why is that ironic? Windows makes backwards compatibility a priority, Linux... doesn't. Well, Linux does, but the userspace not so much.
      - kuschku 10y ago
        Well, the userspace actually isn’t that bad either – if you stay away from Gnome and Gtk. The KDE and Qt side of userland tends to be a lot more stable – I’ve got a version of Skype here using a Qt version from several years ago – which still runs nicely, and without issues, and with the old version even automatically using the theme I’ve set in Qt5.6.
  - zanny 10y ago
    There is always Qupzilla[1], which is just Qt Web Engine with good Qt UI wrappings. I believe webrtc and even widevine works with it. [1]http://www.qupzilla.com/ http://www.qupzilla.com/ Its basically just pretty Chrome through Qt.
BinaryIdiot 10y ago
As someone who follows Semantic Versioning like the bible when my API changes I find it incredibly interesting that there is an open source community willing to go about it in such a backwards way. Why wouldn't it be GTK 4.0-ALPHA, GTK 4.0-BETA, GTK 4.0-RTM in which case RTM is the final release that's stable? Why would you release an API as an X.0 that is unstable? Maybe I'm not as "with it" as I thought with open source communities but I've just never seen this (and I'm sure there are edge cases but GTK is big; seems like something important you'd want to be more stable than not that adheres strictly to semver).
- wvenable 10y ago
  I think I understand it. The X.0 is basically the start of a new technology branch -- it's radically different than what came before which is why it's a new major release. And of course any new radically different piece of software will not be stable, so X.0 represents the most unstable version of this new technology and theoretically X.Y where Y is the latest point release is then likely the most bug free and stable. Perhaps this makes more sense in a world where software never needs to be finished.
  - zanny 10y ago
    This is, strangely? The release cycle that KDE Plasma uses. 5.7 just came out, and is the most stable and feature complete 5.x. You should always upgrade your Plasma 5.x, because newer versions are not revolutionary like 5.0 was, they are incrementally better. 4.12 vs 5.0 at release were not even comparable - 5.0 was completely broken. The difference is, that is KDE Plasma. KDE Frameworks, the libraries, are abut to release version 5.24, where they have been getting monthly releases but upon Frameworks 5.0 release they were stable and better than the already existent KDE Libs 4.12 to start out. They are also always backwards compatible, but have incrementally added new features and frameworks between releases. You know, like a real toolkit. And the same applies to Qt upstream, except it does better than Plasma. Qt 5.0 was flat out better than 4.8 right out of the gate, and only gets better. It is also mostly backwards compatible, insofar as it does depreciate and remove features but only over the course of multiple releases. Qt Script only just got removed in 5.7 after being depreciated in 5.0? I believe. The real takeaway should just be that GTK is not a real product, and nobody who wants to make real usable maintainable software should touch it with a ten foot pole. Qt has been great for ~5+ years, and is only getting better (and its getting a lot better every year) so I have no idea why anyone is still even looking at GTK. If you don't like C++, you can do Qt with pure Python or Javascript as well.
wpietri 10y ago
I'm not a GTK user, so maybe I'm missing something here. And I certainly agree with the version number complaints. But these quotes trouble me: "what GTK really needs to do is sit down and flesh out a decent API" and "And if you’re having to mess with your API on a continual basis, you’re doing it wrong. Like, the whole software development thing, all wrong." I think there's an conceptual error here. There are a lot of bad reasons to change software, but I think there are two really good reasons: 1) circumstances change, and 2) we have learned something. Or conversely, I think the only time software can have a static design is when circumstances are static and you never learn anything. There's this common notion that if people just sit down and think really hard, they will design the perfect thing. That's a mirage. The iPod went through more than a hundred physical revisions before launch. And it has changed a great deal in the 15 years since. Is that because Apple didn't just sit down and think enough? Nope. Even the humble paperclip evolved over decades. If perfect software ever happens, that belongs to a future age.
- digi_owl 10y ago
  Here is the rub, if you take a look at the Linux kernel you will see that they have managed, for the most part, to maintain backwards compatibility for a decade or more. You can probably still run ELF binaries today that you compiled back when they move to the format. Heck, you can even compile the kernel to support a.out of you are so inclined.
  - qznc 10y ago
    Alan Cox https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk https://plus.google.com/115250422803614415116/posts/hMT5kW8L... > However it's not an Open Source disease its certain projects like Gnome disease - my 3.6rc kernel will still run a Rogue binary built in 1992. X is back compatible to apps far older than Linux.
    - digi_owl 10y ago
      Do wonder if that claimed X compatibility holds up with recent Xorg versions, as they seem to enjoy ripping out code these days...
scotchmi_st 10y ago
There is a partial solution to this problem- API schemas. Define a schema for your API and make it public, then have API methods auto-generated directly from that. For example, for web APIs, there's jsonschema- http://json-schema.org/ http://json-schema.org/ from which you can auto-gen functions in a given language. That way, the parameters around the API such as the URI of an endpoint can be changed from version to version without completely destroying the logic on top of it. It doesn't always solve the problem completely, but it can make it much more tractable.
- Sanddancer 10y ago
  Include headers /are/ API schemas. The big problem being discussed here is ABI compatibility. Needing to recompile one's software every six months, or have .so.hell is not fun at all.
digi_owl 10y ago
Between this and GTK3 i really wish someone would take GTK2 and run far far away from the Gnome gang.
- whacker 10y ago
  I can imagine some of the complaints with gnome, although I feel its gotten far better, what exactly are the problems with gtk3 vs 2+?
appleflaxen 10y ago
The GTK project is hard to understand. They develop with a philosophy that is almost the antithesis of the kernel (which basically says "changes that break programs are bugs"). It would be fine for an application being used directly by end users, but for a library and gui system it is bonkers. I have tried to compile a gtk-based app from source, and had no end of difficulty just because my library release varied by a point-version. It left a really crummy taste in my mouth. I really like GTK, and once it's compiled it's great, but these aspects are really painful.
- makomk 10y ago
  The GTK project basically got taken over by a bunch of Gnome developers who care less and less about non-Gnome users. Many major non-Gnome projects haven't even managed to make the jump to GTK 3 yet (which also seems to be roughly where the project jumped the shark); Firefox only switched a few months ago and GIMP is still thinking about it.
  - audidude 10y ago
    Every sentence here is inaccurate, so you might want to check your sources. 1) (It's GNOME in upper case) 2) gtk+ was not "taken over" by a bunch of GNOME developers. gtk+ always was largely shouldered by the GNOME project. Those that show up to play are at an advantage. 3) Switching to gtk+ 3.x was hard precisely due to the longevity of gtk+ 2.x. It managed to stick around for 10 years and exposed all private structures in public API. So people got used to doing bad things that following PIMPL helps avoid. So they did, making the transition harder. 4) Firefox's has very little incentive to change a working code-base. The ultimate incentive was HiDPI and Wayland support. Thing's that couldn't just be shoe-horned into gtk+ 2.x. 5) GIMP is not "still thinking about it". The sad state is that GIMP is being mostly worked on by one person (with some occasional help). It's a very large code-base which was very entrenched in gtk+ 2'isms that we moved away from (like public structure access). There is a nightly flatpak for 3.x if you'd like to test it and file bugs.
    - OneNoteIsFree 10y ago
erikb 10y ago
I would laugh about it if I wouldn't have done the same stuff the first time I built something for other people. Do they have a completely new team at gtk dev?
__jal 10y ago
Breaking news: the five of the seven remaining GTK developers collectively committed suicide this morning. The remaining two were found clutching each other behind a dumpster muttering, "no more themes, no more themes, no more themes..."
moptar 10y ago
For all the complaints, this sounds like a great deal for the Gtk developers. They don't have to plan ahead of time which version is going to be the stable one. If one ends up working well and they want to start on new ideas, they can just leave it unchanged, declare it to be the stable one and move on. Developers are people too and they would want a system that makes it easy for them. Is it really a problem for application developers either? When you start your project, just pick the latest stable version and stay with that throughout. You can ignore all the subsequent updates and be sure that your stable version's API won't change. The unstable versions are surely just for people who want to play with the new features early, not people who are worried about compatibility.
- tremon 10y ago
  Developers are people too and they would want a system that makes it easy for them. I don't want the world to be composed of people that are only there to make the world easy for themselves.
whack 10y ago
After reading the headline, I was actually expecting the article to go in a totally different direction. Most of the time, when I see software with rotten foundations, it's there to preserve backward compatibility. The maintainers all see the rot, they want to fix it, they want to clean it all up, they want to do things right. But they can't do anything that would change the API or break user space in any way, and so, they continue supporting the rot indefinitely. The alternative of course, is to fix the rot and prioritize long term benefits over short-term pain. The downside is that this could break backwards compatibility. This is the path Python chose when they went from Python 2 -> Python 3, and the resulting schism was so great, that they have promised to never do this again. More often than not, this is the same experience that every software project goes through. Breaking backwards compatibility is so disruptive, that even living with a rotten foundation seems preferable. Given the blog title, I would have expected that author to argue that fixing the rot is preferable over almost anything else. Instead, he seems to be making the exact opposite argument. He's making the argument that breaking backwards compatibility is so bad, that we should never do it, no matter how rotten the existing API might be. Of course, he wouldn't actually frame it that way. If you asked the author, he would simply ask "Why can't you just build the API right the first time?" One might as well ask the question: "Why can't you just build a software without any bugs?" Let's see... 1) To err is human and people will make mistakes. Both in implementation (bugs), and in design (bad APIs). 2) Building safeguards against mistakes is expensive, in time and effort. Building 100% robust safeguards against mistakes, is extremely expensive. 3) There's only so much you can learn in a lab, or from a beta. If you don't have any regrets from 2 years of live data, then you haven't learned anything at all. Every project strikes its own balance along the speed vs stability, and improvement vs backwards-compatibility axis. And there is no intrinsically wrong answer. Just because what your ideal balance differs from the balance that the project chose, is no reason to insult and condescend to them. And yelling at someone for being human and making mistakes, just sounds childish more than anything.
- xg15 10y ago
  So apparently you often see the two extremes: Either absolute backwards compatibility with the struggle to preserve every quirk and wrinkle lest clients could break - or "my way or the highway" where you "iterate" the API whenever you feel like it and expect everyone to update. Is it not possible to find a solid middle ground? E.g. provide different versions of your API in parallel and internally map the old API on the new one. Where that is not possible, iterate the API using a sane timeframe.
tomc1985 10y ago
I am so sick of this mentality that seems to raise aesthetic distractions, "new features!!!111", and pointless, frequent version changes over code quality and reusability. It is a sign that this area of commercial software dev has been almost completely subsumed by marketeers and business hacks; while they may not control GTK (though I honestly don't know/care who does), it is clear that their influence (gotta have the latest new and shiny!) has crowded out other, more prosaic concerns (like stability and compatibility). A lot can be said about Microsoft's code, but I have always admired just how much effort they go through to preserve API compatibility. (Going so far as to version specific functions and including older versions so as to not break stuff -- TwiddleBit1(), TwiddleBit2(), and so on. But on another note it's a problem with we programmers as well. We're so distractable... you can see it everyday here on HN... "Show HN" is virtually a graveyard of half-baked, re-hashed ideas implemented in shiny new frameworks. Unicorns trying to take over the world write long-form blog-posts describing their tech (but leaving out enough details to let you try it yourself or duplicate it!) to keep us programmer-types distracted and submissive ('it's better they gawk at code than question our motives') with their pointless show-and-tells. Also... I am god damn sick and tired of dealing with updates! Stop updating your damn code so much!!!!!!!!! Or even better... get it right the first time! (It can be done!)
- ourmandave 10y ago
  I'm going to fork your comments and add new features!!!111 =D
- paavokoya 10y ago
  >has been almost completely subsumed by marketeers and business hacks Welcome to the least common denominator. These business practices serve the masses and raise shareholder value. If we as a society want to change, we should begin to question monetary inflation which openly encourages "shiny and new" investing and "better invest in anything before inflation destroys my life savings". This brand of economics actively pushes people to buy the "brand new" item and invest in the "brand new" startup with no concern for stability or reliability because the hype will raise stockholder value at least in the short term. This mentality is seeping into every aspect of our society. Without constant updates or new and shiny objects coming out, stock prices plummet. Our entire economy is built on a rotten foundation (unsound monetary policy) which is manipulated to enforce "buy now, ask questions later" economics.
Animats 10y ago
This is why: [1] [1] https://www.youtube.com/watch?v=lecHdtywAAU https://www.youtube.com/watch?v=lecHdtywAAU
onli 10y ago
I really like that. We are getting closer and closer to having Qt as being the dominating user interface toolkit anyway, and GTK self-destructing can only further this along.
- davidgerard 10y ago
  Yes, my first thought at those blog posts was "From the Qt Marketing Department at GNOME".
microcolonel 10y ago
I like GTK+, but this release schedule horrifies and disgusts me. If you're going to break the ABI, just increment the number. I get that they want to break the ABI incrementally so that they don't end up with what has become of GTK+ 2.x; where half the applications people use are still on 2.x and so don't have smooth scrolling or new windowing system support.... but I just don't think this is the way to fix that.
Sir_Cmpwn 10y ago
I'd like to take a moment to mention that the GNOME developers (who run the Gtk project) are literally insane. They're pushing this new batshit crazy Gtk versioning scheme, for one, but there's more. They're pushing around the Wayland scene with crazy design choices for Wayland compositors that affects the entire Wayland ecosystem and disrupts other projects hoping for cross compatability. The GNOME developers honestly and sincerely do not see a point to having any non-Gtk3 software work on the GNOME desktop. I'm not kidding, ask one of them and they will concur. They also broke everything with GNOME 3, and though they've managed to produce a pretty nice DE by 2014 or so they've spent the last couple of years removing features that people actually use once they deem them "obsolete". They also don't see any point in having any Gtk3 software work on systems without systemd or dbus, which I think is nuts even though I use systemd. GNOME is legitimately insane.
- im_down_w_otp 10y ago
  I think you literally mean figuratively.
  - Sir_Cmpwn 10y ago
    No, I mean literally at this point. I've talked with them a lot and they are honestly convinced that awful choices are good choices and don't understand how anyone would feel otherwise. I don't know anyone who doesn't work on the GNOME project that thinks any of their ideas are good ones.
deleted 10y ago
[deleted]
Filter 10y ago
If GTK had the same status in Linux distributions as the Win16/Win32/etc API does in Windows then Linux distributions would carry every API-incompatible version of the library necessary (and maintain old ones). As it stands, GTK more closely resembles the "Microsoft C++ Redistributable" situation in Windows -- an awkward hybrid of library and API.
jlundborg 10y ago
I am actually very excited about this direction for Gtk. If Qt is the stable and serious cross-platform UI library for corporate stuff, why not let GTK be the awesome experimental UI library that breaks everything every 6 months, and keeps pushing the limits on what a free software UI can be? I'm a very happy Gnome 3 user, and I hope they keep pushing to build a usable, simple and pretty user experience, despite the endless stream of this kind of grumpy know-it-all attacks. Hey, if it was so easy to design an API that is "thought through properly", show us the spec already - there are plenty of hackers around to build it. If it actually worked like that.
- xg15 10y ago
  Having a more "experimental" project seems like a good idea. But if the API breaks all 6 months, I think it's hard to use such a library unlike your project is a "show HN" style experiment as well that is expected to live only a few months.
shmerl 10y ago
I was very annoyed by GTK 3.20 wreaking havoc. Firefox scrollbars went missing, until fixed much later (in 48 beta)... I wish they'd just switch to Qt already.
jdub 10y ago
Much as I disliked the proposal in the original post (which was later clarified by the GTK+ developers), it is telling that the respondent did not bother to research the reasons behind GTK+'s two API/ABI breaks in its 18 year history.
kr0 10y ago
That's what semantic versioning is all about

216 points by nkurz 10y ago

Now I understand the new attraction for KDE with its new plasma release. They script in javascript. I already quit GNOME with its GNOME 3 iteration desaster. So the fish doesn't only stink at the head, also at its tail. Didn't know that, thanks. Liked this comment: Well, in the words of my two favorite software dev related quotes: > ‘How could the wise man build his house on the sand? How could the wise man build his house, where there is no foundation?’ — Eek a Mouse, Noah’s Ark > ‘The only way a wise man would build his house on the sand is if it was just a hut and he was really high and really enjoyed building new huts.’ — random youtube comment on the above song (sadly I forget who the sage was that wrote that)

gato1313 10y ago

Interesting thread: thanks. I have a gtk2 app I built over many years (gtkmm2.4 to be precise) that I have not ported to gtk3. It is a sophisticated app that uses pulgins (webkit, mplayer, custom, etc). I was thinking maybe I shouldn't spend effort in porting to gtk3. I'm considering going UI free like mpv dose with their video player. Does anyone here have experience in this area and develops plgins for browsers. What are the interesting technologies in this area?

kazinator 10y ago

> Since when does “X.0” not designate a stable release? Oh, approximately since Microsoft gained a lead in personal computing in late 1980-something, and decreed that henceforth, systems shall be expected to be a broken mess until version 3.x.

jwatte 10y ago

In this case: Because it's more fun and personally rewarding to do new stuff, than fight the hard compatibility fight. In startup API cases: Because it takes 10x longer to build a solid foundation, and you don't yet know whether that's worth it -- time to proof is more important. And once you have proof, well, you can't change it easily...

throwanem 10y ago
> it's more fun and personally rewarding to do new stuff, than fight the hard compatibility fight Thirteen years ago: https://href.li/?https://www.jwz.org/doc/cadt.html https://href.li/?https://www.jwz.org/doc/cadt.html And we're still complaining about the very same problems in the very same project. Edit: God dammit, jwz. Sorry, everybody. Should be safe now, I hope. (I can't see the troll for myself, so I don't know for sure, but if this thing strips the header like it claims to do, that should solve it.)
- xeromal 10y ago
  NSFW: Picture of a testicle
  - throwanem 10y ago
    What?
    - omnibrain 10y ago
      jwz doesn't like Hacker News so he redirects traffic from Hacker News to a picture of a testicle.
      - therestisgone 10y ago
        static hosting is hard
    - kuschku 10y ago
      JWZ redirects all accesses with Referer: news.ycombinator.com to this image [NSFW] http://imgur.com/32R3qLv http://imgur.com/32R3qLv
      - mosselman 10y ago
        Haha, some might argue that he has a point.

mosselman 10y ago

Ironically written on/in Wordpress.

throwanem 10y ago
Why not? The mashed potatoes have settled into something that's shaped vaguely like a bookshelf and less likely to collapse into a pile of mush than most of the alternatives. If it's that or pile books on the floor...
jordanlev 10y ago
For all of wordpress's problems, backwards compatibility and API stability definitely isn't one of them! Their dedication to backwards compatibility is very impressive (and probably the biggest factor as to why the technical underpinnings are still such a mess after all these years).

jkot 10y ago

Use QT if you want stable API. GTK3 breaks compatibility even at minor releases.

kuschku 10y ago
Sadly, both Firefox and Chromium still run on GTK3. Especially Firefox is annoying, as their recent update to Gtk 3.20 broke a lot of things for me. If they could just use Qt instead... but nooo...
- digi_owl 10y ago
  I jumped to the extended support channel, knowing it would come. Ironically this means that Firefox on Windows have better backwards compatibility (XP) than Firefox on Linux. If push comes to shove i am pondering moving to Seamonkey.
  - qu4z-2 10y ago
    Why is that ironic? Windows makes backwards compatibility a priority, Linux... doesn't. Well, Linux does, but the userspace not so much.
    - kuschku 10y ago
      Well, the userspace actually isn’t that bad either – if you stay away from Gnome and Gtk. The KDE and Qt side of userland tends to be a lot more stable – I’ve got a version of Skype here using a Qt version from several years ago – which still runs nicely, and without issues, and with the old version even automatically using the theme I’ve set in Qt5.6.
- zanny 10y ago
  There is always Qupzilla[1], which is just Qt Web Engine with good Qt UI wrappings. I believe webrtc and even widevine works with it. [1]http://www.qupzilla.com/ http://www.qupzilla.com/ Its basically just pretty Chrome through Qt.

BinaryIdiot 10y ago

As someone who follows Semantic Versioning like the bible when my API changes I find it incredibly interesting that there is an open source community willing to go about it in such a backwards way. Why wouldn't it be GTK 4.0-ALPHA, GTK 4.0-BETA, GTK 4.0-RTM in which case RTM is the final release that's stable? Why would you release an API as an X.0 that is unstable? Maybe I'm not as "with it" as I thought with open source communities but I've just never seen this (and I'm sure there are edge cases but GTK is big; seems like something important you'd want to be more stable than not that adheres strictly to semver).

wvenable 10y ago
I think I understand it. The X.0 is basically the start of a new technology branch -- it's radically different than what came before which is why it's a new major release. And of course any new radically different piece of software will not be stable, so X.0 represents the most unstable version of this new technology and theoretically X.Y where Y is the latest point release is then likely the most bug free and stable. Perhaps this makes more sense in a world where software never needs to be finished.
- zanny 10y ago
  This is, strangely? The release cycle that KDE Plasma uses. 5.7 just came out, and is the most stable and feature complete 5.x. You should always upgrade your Plasma 5.x, because newer versions are not revolutionary like 5.0 was, they are incrementally better. 4.12 vs 5.0 at release were not even comparable - 5.0 was completely broken. The difference is, that is KDE Plasma. KDE Frameworks, the libraries, are abut to release version 5.24, where they have been getting monthly releases but upon Frameworks 5.0 release they were stable and better than the already existent KDE Libs 4.12 to start out. They are also always backwards compatible, but have incrementally added new features and frameworks between releases. You know, like a real toolkit. And the same applies to Qt upstream, except it does better than Plasma. Qt 5.0 was flat out better than 4.8 right out of the gate, and only gets better. It is also mostly backwards compatible, insofar as it does depreciate and remove features but only over the course of multiple releases. Qt Script only just got removed in 5.7 after being depreciated in 5.0? I believe. The real takeaway should just be that GTK is not a real product, and nobody who wants to make real usable maintainable software should touch it with a ten foot pole. Qt has been great for ~5+ years, and is only getting better (and its getting a lot better every year) so I have no idea why anyone is still even looking at GTK. If you don't like C++, you can do Qt with pure Python or Javascript as well.

wpietri 10y ago

I'm not a GTK user, so maybe I'm missing something here. And I certainly agree with the version number complaints. But these quotes trouble me: "what GTK really needs to do is sit down and flesh out a decent API" and "And if you’re having to mess with your API on a continual basis, you’re doing it wrong. Like, the whole software development thing, all wrong." I think there's an conceptual error here. There are a lot of bad reasons to change software, but I think there are two really good reasons: 1) circumstances change, and 2) we have learned something. Or conversely, I think the only time software can have a static design is when circumstances are static and you never learn anything. There's this common notion that if people just sit down and think really hard, they will design the perfect thing. That's a mirage. The iPod went through more than a hundred physical revisions before launch. And it has changed a great deal in the 15 years since. Is that because Apple didn't just sit down and think enough? Nope. Even the humble paperclip evolved over decades. If perfect software ever happens, that belongs to a future age.

digi_owl 10y ago
Here is the rub, if you take a look at the Linux kernel you will see that they have managed, for the most part, to maintain backwards compatibility for a decade or more. You can probably still run ELF binaries today that you compiled back when they move to the format. Heck, you can even compile the kernel to support a.out of you are so inclined.
- qznc 10y ago
  Alan Cox https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk https://plus.google.com/115250422803614415116/posts/hMT5kW8L... > However it's not an Open Source disease its certain projects like Gnome disease - my 3.6rc kernel will still run a Rogue binary built in 1992. X is back compatible to apps far older than Linux.
  - digi_owl 10y ago
    Do wonder if that claimed X compatibility holds up with recent Xorg versions, as they seem to enjoy ripping out code these days...

scotchmi_st 10y ago

There is a partial solution to this problem- API schemas. Define a schema for your API and make it public, then have API methods auto-generated directly from that. For example, for web APIs, there's jsonschema- http://json-schema.org/ http://json-schema.org/ from which you can auto-gen functions in a given language. That way, the parameters around the API such as the URI of an endpoint can be changed from version to version without completely destroying the logic on top of it. It doesn't always solve the problem completely, but it can make it much more tractable.

Sanddancer 10y ago
Include headers /are/ API schemas. The big problem being discussed here is ABI compatibility. Needing to recompile one's software every six months, or have .so.hell is not fun at all.

digi_owl 10y ago

Between this and GTK3 i really wish someone would take GTK2 and run far far away from the Gnome gang.

whacker 10y ago
I can imagine some of the complaints with gnome, although I feel its gotten far better, what exactly are the problems with gtk3 vs 2+?

appleflaxen 10y ago

The GTK project is hard to understand. They develop with a philosophy that is almost the antithesis of the kernel (which basically says "changes that break programs are bugs"). It would be fine for an application being used directly by end users, but for a library and gui system it is bonkers. I have tried to compile a gtk-based app from source, and had no end of difficulty just because my library release varied by a point-version. It left a really crummy taste in my mouth. I really like GTK, and once it's compiled it's great, but these aspects are really painful.

makomk 10y ago
The GTK project basically got taken over by a bunch of Gnome developers who care less and less about non-Gnome users. Many major non-Gnome projects haven't even managed to make the jump to GTK 3 yet (which also seems to be roughly where the project jumped the shark); Firefox only switched a few months ago and GIMP is still thinking about it.
- audidude 10y ago
  Every sentence here is inaccurate, so you might want to check your sources. 1) (It's GNOME in upper case) 2) gtk+ was not "taken over" by a bunch of GNOME developers. gtk+ always was largely shouldered by the GNOME project. Those that show up to play are at an advantage. 3) Switching to gtk+ 3.x was hard precisely due to the longevity of gtk+ 2.x. It managed to stick around for 10 years and exposed all private structures in public API. So people got used to doing bad things that following PIMPL helps avoid. So they did, making the transition harder. 4) Firefox's has very little incentive to change a working code-base. The ultimate incentive was HiDPI and Wayland support. Thing's that couldn't just be shoe-horned into gtk+ 2.x. 5) GIMP is not "still thinking about it". The sad state is that GIMP is being mostly worked on by one person (with some occasional help). It's a very large code-base which was very entrenched in gtk+ 2'isms that we moved away from (like public structure access). There is a nightly flatpak for 3.x if you'd like to test it and file bugs.
  - OneNoteIsFree 10y ago

erikb 10y ago

I would laugh about it if I wouldn't have done the same stuff the first time I built something for other people. Do they have a completely new team at gtk dev?

__jal 10y ago

Breaking news: the five of the seven remaining GTK developers collectively committed suicide this morning. The remaining two were found clutching each other behind a dumpster muttering, "no more themes, no more themes, no more themes..."

moptar 10y ago

For all the complaints, this sounds like a great deal for the Gtk developers. They don't have to plan ahead of time which version is going to be the stable one. If one ends up working well and they want to start on new ideas, they can just leave it unchanged, declare it to be the stable one and move on. Developers are people too and they would want a system that makes it easy for them. Is it really a problem for application developers either? When you start your project, just pick the latest stable version and stay with that throughout. You can ignore all the subsequent updates and be sure that your stable version's API won't change. The unstable versions are surely just for people who want to play with the new features early, not people who are worried about compatibility.

tremon 10y ago
Developers are people too and they would want a system that makes it easy for them. I don't want the world to be composed of people that are only there to make the world easy for themselves.

whack 10y ago

After reading the headline, I was actually expecting the article to go in a totally different direction. Most of the time, when I see software with rotten foundations, it's there to preserve backward compatibility. The maintainers all see the rot, they want to fix it, they want to clean it all up, they want to do things right. But they can't do anything that would change the API or break user space in any way, and so, they continue supporting the rot indefinitely. The alternative of course, is to fix the rot and prioritize long term benefits over short-term pain. The downside is that this could break backwards compatibility. This is the path Python chose when they went from Python 2 -> Python 3, and the resulting schism was so great, that they have promised to never do this again. More often than not, this is the same experience that every software project goes through. Breaking backwards compatibility is so disruptive, that even living with a rotten foundation seems preferable. Given the blog title, I would have expected that author to argue that fixing the rot is preferable over almost anything else. Instead, he seems to be making the exact opposite argument. He's making the argument that breaking backwards compatibility is so bad, that we should never do it, no matter how rotten the existing API might be. Of course, he wouldn't actually frame it that way. If you asked the author, he would simply ask "Why can't you just build the API right the first time?" One might as well ask the question: "Why can't you just build a software without any bugs?" Let's see... 1) To err is human and people will make mistakes. Both in implementation (bugs), and in design (bad APIs). 2) Building safeguards against mistakes is expensive, in time and effort. Building 100% robust safeguards against mistakes, is extremely expensive. 3) There's only so much you can learn in a lab, or from a beta. If you don't have any regrets from 2 years of live data, then you haven't learned anything at all. Every project strikes its own balance along the speed vs stability, and improvement vs backwards-compatibility axis. And there is no intrinsically wrong answer. Just because what your ideal balance differs from the balance that the project chose, is no reason to insult and condescend to them. And yelling at someone for being human and making mistakes, just sounds childish more than anything.

xg15 10y ago
So apparently you often see the two extremes: Either absolute backwards compatibility with the struggle to preserve every quirk and wrinkle lest clients could break - or "my way or the highway" where you "iterate" the API whenever you feel like it and expect everyone to update. Is it not possible to find a solid middle ground? E.g. provide different versions of your API in parallel and internally map the old API on the new one. Where that is not possible, iterate the API using a sane timeframe.

tomc1985 10y ago

I am so sick of this mentality that seems to raise aesthetic distractions, "new features!!!111", and pointless, frequent version changes over code quality and reusability. It is a sign that this area of commercial software dev has been almost completely subsumed by marketeers and business hacks; while they may not control GTK (though I honestly don't know/care who does), it is clear that their influence (gotta have the latest new and shiny!) has crowded out other, more prosaic concerns (like stability and compatibility). A lot can be said about Microsoft's code, but I have always admired just how much effort they go through to preserve API compatibility. (Going so far as to version specific functions and including older versions so as to not break stuff -- TwiddleBit1(), TwiddleBit2(), and so on. But on another note it's a problem with we programmers as well. We're so distractable... you can see it everyday here on HN... "Show HN" is virtually a graveyard of half-baked, re-hashed ideas implemented in shiny new frameworks. Unicorns trying to take over the world write long-form blog-posts describing their tech (but leaving out enough details to let you try it yourself or duplicate it!) to keep us programmer-types distracted and submissive ('it's better they gawk at code than question our motives') with their pointless show-and-tells. Also... I am god damn sick and tired of dealing with updates! Stop updating your damn code so much!!!!!!!!! Or even better... get it right the first time! (It can be done!)

ourmandave 10y ago
I'm going to fork your comments and add new features!!!111 =D
paavokoya 10y ago
>has been almost completely subsumed by marketeers and business hacks Welcome to the least common denominator. These business practices serve the masses and raise shareholder value. If we as a society want to change, we should begin to question monetary inflation which openly encourages "shiny and new" investing and "better invest in anything before inflation destroys my life savings". This brand of economics actively pushes people to buy the "brand new" item and invest in the "brand new" startup with no concern for stability or reliability because the hype will raise stockholder value at least in the short term. This mentality is seeping into every aspect of our society. Without constant updates or new and shiny objects coming out, stock prices plummet. Our entire economy is built on a rotten foundation (unsound monetary policy) which is manipulated to enforce "buy now, ask questions later" economics.

Animats 10y ago

This is why: [1] [1] https://www.youtube.com/watch?v=lecHdtywAAU https://www.youtube.com/watch?v=lecHdtywAAU

onli 10y ago

I really like that. We are getting closer and closer to having Qt as being the dominating user interface toolkit anyway, and GTK self-destructing can only further this along.

davidgerard 10y ago
Yes, my first thought at those blog posts was "From the Qt Marketing Department at GNOME".

microcolonel 10y ago

I like GTK+, but this release schedule horrifies and disgusts me. If you're going to break the ABI, just increment the number. I get that they want to break the ABI incrementally so that they don't end up with what has become of GTK+ 2.x; where half the applications people use are still on 2.x and so don't have smooth scrolling or new windowing system support.... but I just don't think this is the way to fix that.

Sir_Cmpwn 10y ago

I'd like to take a moment to mention that the GNOME developers (who run the Gtk project) are literally insane. They're pushing this new batshit crazy Gtk versioning scheme, for one, but there's more. They're pushing around the Wayland scene with crazy design choices for Wayland compositors that affects the entire Wayland ecosystem and disrupts other projects hoping for cross compatability. The GNOME developers honestly and sincerely do not see a point to having any non-Gtk3 software work on the GNOME desktop. I'm not kidding, ask one of them and they will concur. They also broke everything with GNOME 3, and though they've managed to produce a pretty nice DE by 2014 or so they've spent the last couple of years removing features that people actually use once they deem them "obsolete". They also don't see any point in having any Gtk3 software work on systems without systemd or dbus, which I think is nuts even though I use systemd. GNOME is legitimately insane.

im_down_w_otp 10y ago
I think you literally mean figuratively.
- Sir_Cmpwn 10y ago
  No, I mean literally at this point. I've talked with them a lot and they are honestly convinced that awful choices are good choices and don't understand how anyone would feel otherwise. I don't know anyone who doesn't work on the GNOME project that thinks any of their ideas are good ones.

deleted 10y ago

[deleted]

Filter 10y ago

If GTK had the same status in Linux distributions as the Win16/Win32/etc API does in Windows then Linux distributions would carry every API-incompatible version of the library necessary (and maintain old ones). As it stands, GTK more closely resembles the "Microsoft C++ Redistributable" situation in Windows -- an awkward hybrid of library and API.

jlundborg 10y ago

I am actually very excited about this direction for Gtk. If Qt is the stable and serious cross-platform UI library for corporate stuff, why not let GTK be the awesome experimental UI library that breaks everything every 6 months, and keeps pushing the limits on what a free software UI can be? I'm a very happy Gnome 3 user, and I hope they keep pushing to build a usable, simple and pretty user experience, despite the endless stream of this kind of grumpy know-it-all attacks. Hey, if it was so easy to design an API that is "thought through properly", show us the spec already - there are plenty of hackers around to build it. If it actually worked like that.

xg15 10y ago
Having a more "experimental" project seems like a good idea. But if the API breaks all 6 months, I think it's hard to use such a library unlike your project is a "show HN" style experiment as well that is expected to live only a few months.

shmerl 10y ago

I was very annoyed by GTK 3.20 wreaking havoc. Firefox scrollbars went missing, until fixed much later (in 48 beta)... I wish they'd just switch to Qt already.

jdub 10y ago

Much as I disliked the proposal in the original post (which was later clarified by the GTK+ developers), it is telling that the respondent did not bother to research the reasons behind GTK+'s two API/ABI breaks in its 18 year history.

kr0 10y ago

That's what semantic versioning is all about