[ddtaylor]

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole.

Unity, Bazaar, Mir, Upstart, Snap, etc.

All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

[popcornricecake]

Ubuntu Touch... I was so excited about it that I bought one of the phones with it preloaded. I even used it as my sole daily driver for months, until I learned that I was not receiving all calls made to me. Even after that I kept hoping it would keep developing so that I could pick it up again one day. But then Canonical abandoned it instead. That's when they became as good as dead to me.

[ddtaylor]

Sadly, KDE and Gnome each spent a lot of time on the same things. Plasma Mobile has ate more time that could have went into making Plasma a better desktop.

[kombine]

That's a strange argument. Open source software including Plasma Mobile is developed by volunteers who choose to spend their time on a given project. I am quite happy with the pace of Plasma Desktop and the progress made in the past 3 years on its 6th iteration.

[ddtaylor]

As a KDE developer I can say that there are times that we have done things differently or taken the long road because we wanted to support Plasma Mobile.

It would have just been better to continue doing the desktop specific things and let the Plasma Mobile enthusiasts make those changes.

[loloquwowndueo]

The project bzr was trying to uproot may not be the one you’re thinking of. First release of Bzr predates git by about a month.

[ddtaylor]

Correct, and I used bzr quite a bit during that time. It was interesting in some ways, but Canonical pushed it for many years after git was obviously the better choice.

Even to this day there is a complex and archaic process of using Launchpad where git is tacked on because they stuck with Bazaar for so long.

[stubish]

Similarly upstart, from 2006, widely deployed before Redhat brought in systemd. And got dropped when Debian decided to go with systemd. Surprising how this gets misremembered given the hate systemd initially received.

[loloquwowndueo]

I remember it well. At least Canonical also jumped on the systemd bandwagon when upstream (Debian) made a choice, instead of dragging upstart on, like it has done with countless other projects that are past their time (juju looking at you)

[antod]

People also forget or don't realize that before systemd Redhat shipped and supported upstart in RHEL too.

[justinclift]

Also LXD → Incus: https://linuxcontainers.org/lxd/

[duskwuff]

Or ansible/chef/etc -> Juju. There's a lot of NIH to pick from at Canonical.

[goodpoint]

Or Debian -> Ubuntu

[unethical_ban]

Not sure on the timelines, but snap, upstart and Mir were all attempts at evolving Linux ecosystem that lost to RedHat-backed systems. Unity was legit abandoned, and bazaar... Not sure what they were trying to solve there with git and forges already existing.

[foresto]

> bazaar... Not sure what they were trying to solve there with git and forges already existing.

You are mistaken here. Bazaar, Mercurial, and Git appeared at about the same time, and I think Bazaar was released first.

IIRC, Bazaar tried to distinguish itself by handling renames better than other version control systems. In practice, this turned out not to be very important to most people.

(Tangent: It wasn't clear at the time whether Mercurial or Git was the better pick. Their internal design was very similar. Mercurial offered a more pleasant user interface, superior cross-platform support, and a third advantage that I'm forgetting at the moment. Git had unbeatable author recognition. Eventually, Git's improved Windows support and the arrival of GitHub sealed its victory in the popularity contest. But all of that came to pass well after Bazaar was released.)

[omcnoe]

Lightweight branch model of git mapped so much better to the way that actual development processes of medium to large projects really work(ed).

Named branches vs bookmarks in hg just means bike shedding about branching strategy. Bookmarks ultimately work more like lightweight git style branches, but they came later, and originally couldn't even be shared (literally just local bookmarks). Named branches on the other hand permanently accumulate as part of the repository history.

Git came out with 1 cohesive branch design from day 1.

[foresto]

That's a fair criticism for some workflows, and I like the lightweight model, but we should keep in mind the context of the time:

When these DVCS appeared, Git's branch design departed from what "branch" meant practically everywhere else. That added to its already significant learning curve, creating more friction for people trying (or being asked) to adopt it.

Meanwhile, Mercurial's "branch" was closer to well-established norms. This was one of several factors that made it the easier of the two to learn, which was was important when already asking people to uproot from their familiar centralized systems and learn the ins and outs of distributed version control. I suspect it also made repository migrations more straightforward, avoiding the impedance mismatch presented by Git's branches.

[nottorp]

I work on a mercurial hosted project right now. What ticks me off is all those unnamed heads you need to handle every time you pull other people's changes. Yes they're more flexible. Most of the time that just means extra operations for no good reason.

[jurip]

Yeah, agreed. I liked the idea of Mercurial branches better than git's — in principle I prefer more rather than less metadata in history — but they genuinely had a scaling problem. I can't recall the numbers, this being more than a decade ago, but I tested with a realistic number of branches for a team of developers using short-lived branches for a while and you could easily see Mercurial slowing down.

Back when I was testing bookmarks were available, but Bitbucket was pretty much the only forge that supported Mercurial and their tooling didn't support bookmarks, so that made them a non-starter for many users.

[usrnm]

That is very different from my experience with git. I know that the kernel uses branches a lot, but that's probably because of git's history with the project. At every company I worked git is used exactly the same way as CVS or SVN was used many years ago: you make some local changes, you push these local changes to the central store, you forget about it. Branches make local switching between tasks easier, but apart from that nobody cares about branches and they're definitely not treated as an important part of the repo. In fact, they're usually deleted immediately after the change is merged.

[omcnoe]

I think you have it swapped around. This is exactly the kind of workflow that git provided better support for - lightweight branches, not integral part of master history, deleted after merge.

[ddtaylor]

Wayland was created in 2008. Mir was created in 2013.

Bazaar and Git were created around the exact same time.

Unity was abandoned after a failed attempt to circumvent Gnome 3. I was actually involved with the development of Compiz and they hired Sam to work on Unity, as he was one of the masterminds behind Compiz, but again they just didn't have the vision or execution to make it work.

[zeroc8]

Mir worked in 2014? Wayland took until 2025.

[pjmlp]

Unity was great, after it was abandoned I tried yet again GNOME 3, me that in the past have collaborated with Gtkmm, ended up moving into XFCE, and nowadays I am fully on macOS/Windows anyway.

If I ever go back to GNU/Linux full time, GNOME certainly won't be it.

[ddtaylor]

Things improved a lot with Gnome over the years, but as a fellow Gnome 2 user the initial release of 3 and the following years were a real kick in the teeth.

Things have improved, but the overall Gnome Foundation attitude hasn't improved. They are still very stubborn and remove basic features. This seemed to start when they did their infamous "focus groups" where they claim users can't understand basic things.

I get the desire to provide a cohesive experience, but I think you can do that while also giving people control.

KDE is shaping up to be much better and it's likely because Valve is providing commercial support and exposing it to a larger audience.

Cosmic is the new kid backed by system76 and its pretty nice too and may rescue Gnome in some ways in due time.

[loloquwowndueo]

> Not sure what they were trying to solve there with git and forges already existing.

What?

Bzr predates git (by a few days but still). Launchpad predated GitHub by a lot. canonical just played those cards horribly and lost.

[ddtaylor]

I still maintain some Launchpad packages and recipes. It's an insanely archaic system and borderline non-functional. I wouldn't wish it upon most.

[loloquwowndueo]

It was deprioritized for years, the team gutted to staff other shinier projects you likely haven’t even heard of.

[Redoubts]

In a way it's really sad how many swings and misses Canonical has taken in its history.

[ddtaylor]

I'm fine with a company getting things wrong from time to time. What I don't like is the attitude where they walk into the room and start moving the furniture around while smugly dismissing or ignoring talented and established people. Then after a bit of milling around they just give up and leave the room and everyone has to clean up the mess.

[unmole]

I miss Ubuntu One, their Dropbox alternative which came with a wee integrated Linux client. IIRC, their free tier was also more generous in comparison.

[maxloh]

Snap is definitely not abandoned.

[esperent]

Sadly

[ur-whale]

> Snap is definitely not abandoned.

You seem to be say it like it's a good thing?

Can't wait for that thing to explode and die.

[ddtaylor]

Snap is a terrible. It's the reason why I stopped using Debian based distros after decades for desktop usage.

Lying to users and turning apt install commands into shims for a barely functional replacement was disrespectful. Flatpak was and still is better, but even then if I say I want a system package you give me a system package. If you have infrastructural reasons why you cannot continue to provide that package then remove it, Debian based systems have many ways to provide such things.

Canonical did it because they wanted to boost Snap usage and if failed while sending a clear message they don't respect their user base.

[lukaslalinsky]

I was honestly wishing Ubuntu would keep upstart alive. I preferred it as init system.

[ddtaylor]

That is half the problem. They often introduce neat ideas, but then fail or refuse to integrate them with he rest of the FOSS ecosystem. Then anyone who subscribes to their experiment is left cleaning up the mess and trying to migrate the features or ideas they like to the remaining projects that should have been extended in the first place.

[stubish]

Not sure how you can say that about upstart. It was pretty much the accepted successor to shell scripts for an init system, for a few years until Redhat started pushing systemd. You would probably be using it now if Debian hadn't gone with the Redhat systemd over OpenRC and upstart.

[sharts]

It’s canonically fucked