> 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.
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...
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.)
Not me, apparently. (No, seriously! I'm seeing the page I expect to see when I click that link in that comment. If I'd known jwz was doing what you claim he is, I'd have wrapped it with a referrer stripping bouncer or something. Sorry!)
Btw, @dang: Can't you just automatically turn every jzw.org link into one redirecting through href.li or donotlink? Or maybe even to the archive.org version?
Startup API cases also often have a chicken & egg situation: you can't know what a good API is until you've had several clients use it, but then you have several clients who will be broken if you change it.
I would think that the first rule of API design is to use it yourself whilst wearing the customers' shoes, and with that approach a large proportion of cases like that would become apparent. Or one could look at some of the longest-standing APIs (WindowS API is one) out there and observe how they evolve it to cope this requirements changes. There's still some chicken-and-egg situation in there but much of the ambiguity can be resolved with the right technique.
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
+1 for startup api. It is a bit sad but the same goes for code. It rots really quick and it might not be worth building solid foundations because in next year it will be out of buisness and building solid foundation takes 6 months...
In this case, it's much less responsible to do so. You have people who rely on their software to get things done. Making them jump through hoops like this just leads to frustration, or them abandoning using your program.
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...
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).
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.
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.
Its a Qt app. Why would you ever want to edit its UI with CSS? Its UI is controlled by the Qt widget and color themes. While its not a Qt specific feature, KDE applications let you drag and drop pretty much every element of every applications interface wherever you want and however you want.
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.
Well, because I want Firefox addons, because I want to be able to add tab previews just with an addon, or redesign the entire UI with an addon, or have tree style tabs.
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.
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.
The Chrome team wrote their own UI ticket called Aura, they use that now. It is OK, but has had rendering artifact problems and has mildly broken multitouch support.
More like The Qt Company has business commitments which means they cannot do dumb shit. 5.7 just open sourced the vast majority of their proprietary extensions, and the whole thing is now available under LGPLv3 or GPLv2 or later, which is about as free as it gets.
Qt was really stable for last years, indeed Qt 3.x -> Qt 4.x was a painful migration, but they learned their lesson and Qt 4.x -> 5.x was pretty much as smooth as it gets. For simple apps you can mostly migrate from 5.0 all the way up to 5.6 without changing any lines of code.
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).
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.
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.
> 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.
Or if they really need so many minor version numbers before the first stable release, they could do the odd-even thing, where odd major versions are devel and even major versions are stable. So skip to 5.x for the next development cycle, then bump to 6.0 when the API becomes stable. Then 7.x for devel, 8.0 for stable, etc.
The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others. Of course semver is progress in the sense that it has a specification that means you can assign meaning to the versions, but hey, so does the proposed versioning scheme for GTK. It is just not semver.
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.
> The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others.[...]it can be confusing if you think that semver is the only game in town
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.
The right way to do version numbers is that the client/caller says "I am complying with version N of the API spec", and the server/callee says "I understand spec versions X through Y at this endpoint". If N < X or N > Y, the transaction is rejected. This applies on a per-endpoint or even a per-function basis, not to the whole system.
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'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.
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.
> 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.
A couple years back I managed to get Open Genera talking to a reasonably modern (ca. 2013) X server, which has to count for something. In fact, getting it talking to the X server was practically the only aspect of the project in which I didn't have problems.
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.
I think the Linux kernel is a bit of a special case. Processors have become boring[1]. What we've mainly wanted out of the Linux kernel is a stable server platform. But that stability is not without cost; a lot of innovation has happened by working around the kernel. E.g., virtualization, containerization.
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.
I had a name conflict in an ios project... found out the header it conflicted with was from apple lisa era, meant to allow gui draw calls to work with quickdraw
As someone who went through the the 68k -> PPC -> x86 transitions with shockingly minimal fuss (also even the MacOS -> OS X + Classic transitions) I wish I could upvote this comment a thousand times.
Sure. But they're also the people who recently decided a whole new programming language was necessary. And they're on, what, their 10th major iOS release?
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.
I could well believe that. But assuming that GTK really should be at a simmer, I'd want to see an argument not for generic stability, but for areas of stability vs change. E.g., "Foo is now well understood, so that should be a stable core API. Bar, though, is an area that will keep evolving, so GTK should do A, B, and C."
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.
Qt maintained binary compatibility from 4.0 in 2005 to 4.8 in 2011, and has from 5.0 in 2012 to 5.7 in 2016. Providing a stable platform is not some impossible ideal. It's a real thing that GTK's competition provides.
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/ 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.
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.
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.
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.
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.
The main benefit of not exposing private structures in public API is that it lets you avoid breaking the ABI every version; if you're going to do that anyway, well. And no, I'm not exaggerating how long it's taking projects to move to gtk+ 3.x - Mozilla has been working on this since 2011, with lots of fun issues around widget styling and drawing (which is apparently poorly documented and keeps changing in ways that break applications). The removal of public structure access was the least of their problems. Even after all that effort, new gtk+ 3.x releases are still breaking stuff in Firefox and other apps. For example, scrollbars and check/radio buttons don't show up in Firefox with gtk+ 3.20 due to major changes in how widget drawing and styling works: https://bugzilla.mozilla.org/show_bug.cgi?id=1234158
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?
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..."
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.
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.
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.
You can have backward compatibility while fixing the foundations. The trick is to add a "compatibility layer" that works well enough for existing clients, then slowly phase it out. Apple in particular is very good at this. They've gone from 68k to PPC, PPC to Intel, "Classic" Mac OS to Carbon to Cocoa, 32-bit to 64-bit, Obj-C to Swift, and so on by maintaining compatibility for old programs on top of new foundations. Unfortunately, these compatibility layers aren't very fun to write and can be difficult to test and maintain, so people (in open source projects especially) tend not to be very interested in the concept.
You do not have to phase out any kind of compatibility layer, if your implementation is forwards compatible. Implementing protocol negotiation and extensibility serves this purpose. Examples for forwards compatible systems are HTTP (upgrade header), XML (namespaces), X11 (extensions).
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!)
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
104 comments
[ 4.1 ms ] story [ 186 ms ] threadOh, 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.
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.)
Trolling level A+
Such a beautiful inadvertency. Anyway, it should be solved now. Sorry!
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.
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.
[0] https://news.ycombinator.com/item?id=11031074
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
If they could just use Qt instead... but nooo...
If push comes to shove i am pondering moving to Seamonkey.
I believe webrtc and even widevine works with it.
[1]http://www.qupzilla.com/
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.
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.
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.
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.
(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.
But as for shipping -alpha, -beta, etc, it would also look very weird if GNOME shipped -alpha as a dependency.
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.
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 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.
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.
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.
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.
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.
[1] https://www.youtube.com/watch?v=lecHdtywAAU
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.
As it stands, GTK more closely resembles the "Microsoft C++ Redistributable" situation in Windows -- an awkward hybrid of library and API.
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.
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)