Why do we keep building rotten foundations?
davmac.wordpress.com
davmac.wordpress.com
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).
Perhaps this makes more sense in a world where software never needs to be finished.
(warning, rant follows)
I think this hits the core of the matter. This kind of release cycle - and API design - reflects a way of thinking where the complete ecosystem is expected to be constantly change. Why bother to keep a stable API if "everyone" has automated updates and all programs that could potentially use your API have a full-time development team behind them, ready to instantly react to every announcement you do.
Backwards compatibility? Not-for-profit one-man projects? Long-lived software? Naaah, were in the era of the cloud now.
Updates are important and at least security-critical software should obviously be maintained. However I think this shift currently goes a lot further than necessary, making constant flux the new normal and articles like this show why this is a bad idea.
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.
If the server gets more functionality, Y can increase. Increasing X breaks some existing programs, but callers which still speak an old version can drop back to that.
I think it is interesting to think about what the versioning scheme says about the development model and methodology of the project:
Linux currently uses even-odd versioning, but regardless tries to never break APIs or ABIs https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering After much debate, Linux switched from a model where the major number never changed, which is kinda inline with semver. But since this seemed increasingly silly, to have a 3 there forever, they decided to just throw this overboard and start incrementing the version number more often. (This discussion was much more interesting in reality, read LKML for details).
Android uses an interesting brand-version and actually-useful-version scheme (API level) https://en.wikipedia.org/wiki/Android_version_history This very much reflects how versioning and releasing a new version has become a PR event. It is really funny how this distinction is even reflected in code.
And then of course there are the funky oddballs: https://en.wikipedia.org/wiki/TeX This asymptotically more precise number is suitable for a project that has the idea that it is approaching perfection without changing much. Not sure if every TeX user out there would agree, but it indeed says something about the author =).
There are plenty others, and of course it can be confusing if you think that semver is the only game in town. Perhaps the ideas expressed in the semver spec simple does not suit everyone.
I certainly don't think semver is the only game in town but the vast majority of versioning techniques out there are very, very similar to semver where major updates are the only ones that can affect the API. I wouldn't expect semver to suit everyone (honestly I prefer a slightly different version that was more common in the .Net universe) but at the same time most versioning techniques behave similarly.
The Gtk way is fine if it works for them but it certainly isn't common. Versioning is one of the very few things that I would be willing to give up what I think is ideal to settle for something most commonly used (why I use semver when working in JavaScript). I'm not sure what the most common versioning scheme there is but at least anecdotally it seems fairly similar to semver or at least a subset of semver.
But as for shipping -alpha, -beta, etc, it would also look very weird if GNOME shipped -alpha as a dependency.
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...
Thirteen years ago: 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.)
Such a beautiful inadvertency. Anyway, it should be solved now. Sorry!
Haha JWZ has done that to me before [0], as well. I think his method is to see an HN Referer, and then pounce with his Tinder profile pic.
Trolling level A+
If you want to see the original article you have to copy and paste the URL into a browser yourself, and not click the link from this site.
The REAL problem is we have all these startup turds churning out ideas faster than they can think about them, and the HN crowd has built an entire ecosystem to facilitate that churn
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.
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.
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!)
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.
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.
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.
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.
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.
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.
> 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.
Too, when I decided in a (thankfully transient) fit of madness to write my own window manager targeting whatever x.org package you got with Debian jessie around Q4 2015, I managed to do so based almost entirely on what I gleaned from a partial set of ancient X manuals which were already yellowing and musty when I picked them up at my city's free book exchange years ago, plus the manual and info pages that came with the system and the Emacs build I put on it.
Not what you'd call an exhaustive evaluation, and maybe things have changed, but I'd say there is at least anecdotal reason for hope with regard to backward compatibility in X.org.
But "virtual server" is like "radio with pictures" or "horseless carriage". It's a sign that something new is coming, but we don't know quite what yet.
[1] http://preshing.com/20120208/a-look-back-at-single-threaded-...
It really feels like IT is just reinventing wheels at this point, because nobody involved seems to care at all about history of computing.
Twice.
Which seems to fit with my point, which is that no matter how smart you are, you won't be able to "sit down" and design something perfect.
And unlike Apple, most of us can't spin up large teams to try to hide the cost of change from our users. It would be nice if open source projects had $200 billion in cash sitting around, but that's not the world we live in.
That's again not to say that GTK is doing anything right; I wouldn't know. My only point is that holding open source projects to impossible standards won't help anything.
Gtk has been around long enough that the boiling should have at least been reduced to a simmer by now.
I'm not opposed to providing stable APIs. I just don't like the myth that if perfect people sit and think really hard, perfect software results.
If they could just use Qt instead... but nooo...
If push comes to shove i am pondering moving to Seamonkey.
I actually like GTK+ 3 applications, but honestly Chromium should just use ozone on X11; they only actually use GTK for text boxes, buttons, and context menus. The only tricky bit would be getting input methods working correctly.
I believe webrtc and even widevine works with it.
Its basically just pretty Chrome through Qt.
Sadly, it looks like Firefox will soon not do either of those things anymore.
While it doesn't have an app ecosystem, it has an extensions API and they have already ported adblock and greasemonkey over.
The amount of insane work required to make it work with either Firefox or Chrome extensions, none of which were meant to operate outside the UI architecture of their host environments, cannot be reasonably considered a major flaw. A disadvantage, but it is the cost of using a native UI toolkit instead of writing your own from scratch like Firefox / Chromium do.
I want to be able to write an addon integrating with a custom server for storage of browser history, or an addon that allows me to tag history entries.
I want to be able to add entire websites in iframes to the UI – for example, as small windows floating in the bottom containing an audio player widget.
That’s why I use Firefox in the first place.
Sadly, half of its UI is unusable thanks to GTK.
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.
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?
As it stands, GTK more closely resembles the "Microsoft C++ Redistributable" situation in Windows -- an awkward hybrid of library and API.
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.
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)
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.
I don't want the world to be composed of people that are only there to make the world easy for themselves.