Hacker News Reader

Comment by cromka | Hacker News Reader

If only they switched to vcpkg from the abomination which Craft manager is... I used to do some dev work in KDE but after realizing I spent 70% of my time with that project on managing the Craft anti-pattern hell, I gave up.

KDE is still extremely anal about not touching anything remotely related to Microsoft, even if it's a properly licensed open source, is way better and even some GNU projects have no issue with it. Any reasonable suggestions to switch to vcpkg have been met with serious hostility, only because it's Microsoft's.

Had they used the more common, recognized tools and processes, they'd see more developer contributions, especially the one-offs, vastly speeding up bugfixing. Because nothing makes you want NOT to fix that annoying bug like spending 3-4 hours setting up your dev environment in the first place.

Oh, and do they have macOS runners available yet in their on-premises Gitlab instance?

View on HN

> KDE is still extremely anal about not touching anything remotely related to Microsoft [...] only because it's Microsoft's.

And I thank them for it. Microsoft has zero regards for the FOSS community, and forcing people to use FOSS tooling made by the FOSS ecosystem to develop FOSS makes a lot of sense to me, at the very least for the dog-feeding argument, but also because it wouldn't make sense to use tooling from a for-profit company that tried time and time to eradicate your community. I understand the avoidance by developers who been around the space for two decades or more, because we remember what Microsoft has done.

Sometimes you have to bite the sour apple in order to actually stand for your ideals, and this particular choice seems like a no brainer, at least to me.

As I explained in response to other commenters, it wouldn't have to be vcpkg. Maybe I didn't articulate it best, but the inherent issue is not just Anti Microsoft stance, but more of not-invented-here paradigm. They go against the grain too much and it tangibly makes things worse for devs and users. They could have gone with other package manager instead on insisting on Craft. They hardly ever have any good arguments for it, feels like sunken cost fallacy all over.

> not touching anything remotely related to Microsoft, even if it's a properly licensed open source, is way better and even some GNU projects have no issue with it.

For sure those are important but what actually drivers a project are accepted COMMITS and GOVERNANCE. If Microsoft puts the right license sure anybody can fork it if somehow the project goes in the wrong direction... but if most contributors are Microsoft employees doing those commits, or refusing others, what will happen? The license or how "better" the project is won't help. If KDE does not trust Microsoft (one of the largest corporations who is selling proprietary software since its inception and still do this day) then even if the "better" solution is from Microsoft then strategically KDE is right to avoid it.

You're not wrong, but even then forking a well established, well designed and not anti-pattern-ridden project with a massive library of build recipes for your own purposes is still better than maintaining some bespoke code used by two projects that forces developers to go mad, give up and quit.

My point was maybe not articulated well: it wouldn't have to be vcpkg. Could be Conan or something else, as long as it's not making you waste your free time and actually help producing reproducible builds and distributables on each platform supported (Linux, BSD, Mac, Windows).

To put this in perspective: KDE is in this situation Qt, they were lucky to negotiate a good contract to keep Qt licensed to KDE favorably, and most importantly, open source on their terms.

Without that deal, KDE would be at Qt's behest as they changed licensing, pricing, etc over time.

Getting into that situation again with Microsoft as a non-profit would be foolish.

I swear I've been through three or four cycles of this now, at least. Microsoft woos some noobs, who wonder why everybody is acting on edge around Microsoft. Become dependent on Microsoft, then get burned. Then new noobs come into the scene and the cycle repeats.

Did Microsoft woo some noobs with GitHub? How come everyone is fear mongering like you do yet somehow fine with GitHub? You have plenty of GNU projects hosted there. That's my point, some things just need to be accepted and we need to move on. Reinventing the wheel like KDE does massively harms the progress.

> How come everyone is fear mongering like you do yet somehow fine with GitHub?

People do regularly object to hosting things on GitHub, doubly so for community FOSS projects.

> You have plenty of GNU projects hosted there.

What GNU projects are hosted on GitHub? (Hosted, not mirrored)

Gnucash is.

They're using GitHub quite actively, but https://wiki.gnucash.org/wiki/Git#Introduction says

> code.gnucash.org is the server that hosts the canonical git repository

and

> Our public repositories are mirrored on GitHub.

You're grasping onto outdated wiki information. All development, including PRs, the release builds (.github folder workflows in repo) and many bug reports are on GitHub. You click Browse Source Code on main website and it takes you to GitHub. You click contribute and wiki lists GitHub for PRs. Seriously, what more do you need?

The wiki says github is just a mirror. That's not "grasping", that's pointing at the most authoritative looking source.

OK, dude.

Let's take a step back and unpack what we're actually trying to say here:

> The gnucash developers use github, therefore...

There's no therefore which changes this discussion. If you want to follow the lead of gnucash developers, none of us can stop you but you and they are still making a mistake. Microsoft is not to be trusted. It's only been what, a week or so since Microsoft shut down the ability to install Windows without a Microsoft account? Something Microsoft fanboys said they'd never do, even as all the evidence pointed towards Microsoft slow boiling that frog. If you still need to learn the hard way, have fun with that. Don't expect anybody else to cheer you on though, we've seen where this goes too many times.

Can you give an example of a mainstream project that uses vcpkg? I've never run across it anywhere.

Who needs vcpkg when you already have a built in package manager?

If it’s not in the distro, it’s not in the tree, then it’s built by another tool like genie or whatever. vcpkg was because windows had no such capability.

It’s decent but it’s not the best.

Because distros usually ship only one specific version of a library. And different distros ship different versions of libraries. If you develop your software on Arch Linux targeting a specific version of an API of the library you're using, and another developer tries to build the same software on Debian, and another on Fedora, it's basically a gamble if your software is going to build or not. With vcpkg, you can pin libraries to their specific versions, to ensure that your project builds regardless of the environment.

Then when distros go to actually package your software for users it'll break. I'm not sure moving the pain downstream is worse, but I'm also not sure it's better.

KDE releases all their apps on Windows and amcOS. In fact most of their users are in Windows. Krita makes most money off of Windows Store.

This is why nobody can rely on distro managers. Not to mention FlatPaks and so on.

Lastly, KDE maintains their own Qt fork for packaging purposes.

That has nothing to do with it. While both relate to KDE, we are talking about two very different things. You are talking about release channels, we are talking about development headers.

KDE releases all their apps on Windows and amcOS. In fact most of their users are in Windows. Krita makes most money off of Windows Store. This is why nobody can rely on distro managers. Not to mention FlatPaks and so on.

And have you ever had to work on different version of libraries for development and LTS branches of software? Because it doesn't sound like you had? Lastly, KDE maintains their own Qt fork for packaging purposes.

Everything you just said was irrelevant and followed by a personal attack.

>”Because it doesn’t sound like you had?” was unnecessary and you have no idea who I am.

I was merely stating that most distros have those headers, most distros care about being up to date with stable releases. Yes KDE releases software on Mac and windows, that has nothing to do with vcpkg. If anything, it’s more work.

I’m sick of the “mansplaining” in these comments like I was born yesterday. I wasn’t, and I know how to write C.

I mean that's C++ development in general.. even among package managers you had to deal with conan, vcpkg, hunter, and a dozen more ..

And then add to that the complexities of build systems and cross platform, cross complication headaches...

That being said, for most of kde end user applications, fixing quick little bugs is usually just installing the devel packages from your distro, git cloning the application, a couple of compile debug cycles and then sending the patch on their gitlab..

Not on Windows or macOS, though. Brew is seriously bad for KDE development.

Out of curiosity, which KDE applications do you use on macOS?

vcpkg is generally indifferent to linux.

It's kind of a two way street there though.. Linux is also very indifferent to applications just statically compiling and linking their dependencies.. On top of that, Each distro has it's own story of what licences they'd permit for libraries in their repositories..

That's why a lot of open source c++ devs / applications had to publish build instructions for half a dozen Linux distros.

Reply on news.ycombinator.com