awrmc

Are you suggesting "political correctness" is the only reason someone might be discouraged from installing a program named after toilet humor and juvenile references to specific parts of the anatomy? I've let my kids watch plenty of children's movies with fart jokes in them, but I still don't want to hear more of that when I'm trying to use a tool to access a banking service. It seems there's even still a banking module with a crude poop icon: https://woob.tech/applications/bank.html

Doesn't really inspire confidence in their professionalism or trustworthiness with handling financial transactions, if you ask me.

In my opinion, you're wasting your time with layer shell. The design of it is very X11-like and flawed. Panels setting their own position is problematic and prevents the shell from doing layout updates in one pass. You'll want to drop it eventually and use a private shell similar to the way it's done in weston.

>Not sure why you'd knock the way GIMP and Inkscape LAF on other systems; they both look perfectly native on Windows, and much better than the majority of cruddy MacOS desktop app wrappers

In my experience Qt apps behave much better on Windows and Mac because they're designed to be native first. GTK was never designed to do that, it started out as a clone of Motif and it only ran on Unix, the cross-platform support was added later when some Windows developers wanted to port GIMP to Windows. To me GIMP and Inkscape always had some weird GTK widgets that don't look or act anything like Win32 widgets. I'd say use Qt if you want a better native experience on mac and windows.

>The GNOME team never opened libadwaita for public comment, or held any forums where I could voice concerns with the direction they were headed. I can understand how this all sounds accusatory, but I really do recommend that you research it.

I've researched it. This isn't how open source works, projects are not driven by public comments on forums. They're driven by people showing up to work together on a shared goal. Those who show up and write the code, get to be the decision makers.

>The community has been completely locked out of the GNOME decision-making process.

It doesn't make much sense to say this, the whole point here is the community makes the decisions for itself and nobody else. Every single contributor past the original founders are from the community.

>They won't accept contributions that allow cross-platform stylesheets

>the GNOME team pretty much doesn't care about anything the community has to say. It's a bad direction for the project to be heading in, and it definitely makes it harder for regular people to write good-looking, system-agnostic GTK apps

I've no idea where you got this. I've never seen any comments from libadwaita developers to suggest that. This doesn't need to be contributed either, if you have a stylesheet you want to work on you can just ship it as part of your app, or create another add-on library for platform extensions similar to this: https://github.com/GNOME/gtk-mac-integration

Regardless of where it ends up, the styles for GIMP on Win32 is just a theme, if that's not available in newer versions then somebody needs to port it to the new theming system. You could wait for a GIMP contributor to do it but that might take a long time.

>It was a really good library until it hit v14, when the developers lobbed off support for Glade files

I might still be misunderstanding, but the break was caused by GTK4. The GTK3 bindings are a separate crate. You can use those until the GTK4 gui designer is released. Breaking glade wasn't done on purpose.

>v9.0.0 allowed you to build programs functionally and register their various interfaces as closures. This made it fairly simple to not only separate UI code from function code, but was also really comfortable to write "like a normal app". v14 eliminated this workflow though

I can't really figure out what you mean for sure but I did some searches. Closure support is still there but it appears to have been moved to another crate called gtk-rs-core.

https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/closure...

https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/macro.c...

But that's the whole thing. Redhat and the foundation don't have any leadership over a decentralized group of open source developers. Gnome is not like the Linux kernel where there's one giant repository with one lead maintainer serving as a bottleneck. There are individuals who hold more influence but that's more because a lot of other volunteers chose to follow them, not because they seized power from anybody.

The only one out of those that's a intentional design is multiple monitors. The other ones are known shortcomings that are just really hard to fix. The memory leak was fixed a few years ago: https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...

That isn't how gnome works, being decentralized and all. The foundation pays for very little of the development and has little to no influence over what developers actually do. If you wanted the community to have more influence over development, the way to do that would actually be to get more money for the foundation so they can afford to hire more developers from the community. Right now, they don't employ any. The funding they have now is actually shockingly small for a nonprofit based in the USA, and almost unnoticeable compared to what a tech company based in the USA would have.

Removal of features would still happen though because that's a natural part of any software project responding to the ever-shifting priorities of a large group of users.

That's not a counterpoint, the rest of your comment doesn't follow either. Check the most recent comment for suggestions on how to help out with changing the functionality: https://gitlab.gnome.org/GNOME/gtk/-/issues/233#note_1106706

If you've got some code to contribute to that, ping the developers on IRC. Adding more comments to that issue isn't helpful. These issues aren't suffering from a lack of comments, they're missing someone to step up and do the work. The original comment was that they were hostile to this, which isn't true.

That's categorically false, there are issues to fix both of those in the gnome settings:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...

It's not easy for me to take this comment seriously because gnome doesn't actually have anything anyone could define as leadership. It's a decentralized open source thing. You might be incorrectly assuming bad faith.

Iced looks pretty cool but it's focused on being a cross-platform toolkit and will probably not ever be the best choice for making programs native to Linux, like a desktop environment. If you thought there were enough problems between GTK and Qt with skinning, fonts, keybindings, and all that stuff, adding another toolkit to the mix just makes it worse.

That seems like a lot of revisionist history. From what I've seen GTK never had good cross-platform development support. Programs like GIMP and Inkscape always looked and behaved very oddly to me on other platforms. The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it.

If you do not want to use Rust, you can always use another language like Python or Javascript. I might be misunderstanding because the rest of your complaints are jumping around a lot, it would be easier to understand what you're talking about if you shared some code illustrating what the problem is.

>Also gnome is so flawed in so many ways from leaking memory due to unfixable mismatch between js and compiled code, to nonsensical handling of multiple desktops, to add-ons that both rely on monkey patching your desktop due to lack of addon api and can with a single crash kill your whole session, to hostility towards themeing, to ugly header bars, to hostility towards support for non gnome desktops.

Most of these issues are just bugs, not issues with some vision. The gnome people I've talked to want them fixed and want help with fixing them. But I get that it's lot easier to complain on hacker news than it is to fix architectural issues in a large codebase.

That question is a non-sequitur. But to give you a type of answer, most of libadwaita came out of Purism.

Checking the response from the maintainer shows another different story: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12

>Implementing keyboard selection inside vte means that every terminal based on vte benefits; adding only hooks for you means that all the other terminals get no benefit.

The patch being pushed wasn't going to help other projects. The developer of that project was working on a fork of the library but it appears it didn't get much use and was abandoned: https://github.com/thestinger/vte-ng

I don't see much more that anyone from GNOME could have done there.

You've decided the best way forward for you is to write sysvinit and openrc scripts. That's an opinion completely focused around writing some additional code. You don't have to write it all from scratch to be expressing that opinion, you can express it a lot of different ways but that's all it encompasses. Unless we're talking about something else that I missed? Suggesting that something is better than something else is really meaningless without that.

I think you've got some things mixed up. The word "woke" usually means being aware of issues with discrimination in the workplace. I'd have to agree with the grandparent comment, if you're suggesting that being aware of discrimination makes it a toxic workplace then you probably need to do some kind of diversity training, not necessarily in the workplace but just generally considering why it's not a good idea to dismiss employee concerns offhand as "woke upheavals". It's not so fun being on the receiving end, if you end up as the one making the harassment complaint and the boss dismisses it by telling you to shut up and stop being woke. Similar things have happened to people I've known.

>If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me.

That's not true. You can do as you would with the shell script and patch it in your local copy. If this is too much hassle then that shell script workflow shouldn't be broken by systemd and you can always fall back to it. It's still possible to run shell scripts as systemd units. You could also run another service manager as a systemd unit as another workaround.

Also, in my experience, if you're fixing an actual crash, those patches are really likely to get accepted. Upstream appreciates that, I haven't seen them fight anyone over an easily verified issue. If you're submitting giant 10,000 line patches that change the public interfaces and cause regressions, that's a different story.

That's just re-stating the grandparent comment! If you think everyone is entitled to their opinion then the only tangible way to express that opinion would be to produce new code. What use is the opinion if nobody ever implements it?

I haven't seen any of these supposed Red Hat projects that have dependencies for political reasons. If that were really true then it would be trivial for anyone to remove those dependencies, and there wouldn't be anything for anyone to complain about. Any way you slice it doesn't seem like a cause for alarm.

I think it's fair to say that Linux isn't Unix and goes well beyond the design constraints of Unix that were imposed when it was originally started in 1969. That's the era you stick to when you insist on only doing things the Unix way, but there are a lot of other ways to know what your system does and have reliable tools. In current times the most common usage of Linux is Android, which is ostensibly not Unix-like at all regarding its userspace. If you're talking about GNU, that quite literally means "GNU is not Unix".

The ticket that quote came from is pretty old and turned out to be a non-issue. I've addressed that in another comment: https://news.ycombinator.com/item?id=29865759

If you're trying to prove a point, you could at least mention something that actually caused a real problem instead of taking this one out of context. I have no idea why anyone would keep mentioning this quote or find it memorable, it seems completely insignificant to me. You also seem to be ignoring all the positive interactions this engineer (or any other Red Hat engineer) might have had. I can personally name a lot of instances where Red Hat engineers have fixed upstream bugs that were affecting me. And just to make it clear I'm not saying this to single them out for praise, a lot of other companies fix upstream bugs too. That's how open source is supposed to work.

And you actually could go and search around on old mailing lists to find similarly questionable 11-year-old quotes from Qt developers if you really were interested in digging up more old drama. These things happen everywhere that people go because people don't agree on everything. I suspect you also think that's ultimately futile though, so why keep flogging this particular dead horse? This is still way, way outside the scope of discussion for systemd anyway.

>I heard that Gnome is dependent on systemd now.

Under some circumstances (not all), GNOME has a dependency on logind. If you're in one of those circumstances, you can use elogind as a drop-in replacement. That's far from having a dependency on systemd.

>Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Both package managers deprive me of control over my system.

I don't think snap lets you deploy your own repository, but for Flatpak this is very very wrong. Check here: https://docs.flatpak.org/en/latest/hosting-a-repository.html

>That was mostly feature expansion. I meant improvement of existing workflows

For desktop app developers? There were a lot of API refinements and enhancements to the widgets too, I didn't mention them all because there's far too many.

>4000 files and 1.6 million lines of systemd C

Just FYI these figures are incorrect, you're likely including the tests, documentation and data files. Running cloc on the current systemd code base I get around 2100 .c and .h files and 520,000 lines of C. That also includes all the other components too, not just the service manager. The service manager is a small fraction of that, it's only around 150 files including the headers.

>There is an obvious cost/benefit factor here.

From the perspective of a distribution I think it's much more cost effective for them to fix this once in C. To you what looks like just 30 shell scripts can quickly multiply into the thousands when you have to consider this is across all users of that distribution who might all have the same buggy set of 30 shell scripts but with different ad-hoc fixes applied.

>If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational.

I think if you actually look at it, you'll find this is already what it does. That's what I saw when I actually took a few hours to familiarize myself with the code.

I disagree with this, in my experience D-Bus is very similar to other IDLs like DCOM, protobuf or ASN.1. If you're familiar with those, D-Bus should actually be easy in comparison.

If you're asking for Red Hat to stop creating integrations between different parts of their distribution, that isn't going to happen. That's one of the benefits you get from being a distribution vendor. Every Linux distribution that grows past a certain size does that eventually, that's how you create a cohesive system. They make money from this because customers actually ask them to do it. You're essentially asking them to kill their core product.

>If they just designed their software how they want to and otherwise let it be

In my experience, that is what they're doing. Their software just happens to be adopted by more users because in a lot of cases it is better and does represent the future. You have that advantage when you support a lot of commercial users over a long period of time. Red Hat also has a policy of contributing a lot to upstream so that also adds to why they have success with other projects.

>If various Red Hat projects didn't find a way to create dependencies on systemd to encourage it's adoption

I think this is an exaggeration. I haven't seen any projects that have anything more than a trivial dependency on systemd to enable some optional functionality.

It's difficult to understand what your complaint is, that describes every software project I've ever seen. You pick a target set of users and then develop for those users. Is there some other way to develop software?

D-Bus is the established IPC on desktop Linux. The libdbus library is pretty old and not great, you'll have better luck using one of the other implementations. I can recommend a few:

- GDBus, if you're developing for GNOME

- QtDBus, if you're developing for KDE

- sd_bus, if you're writing low-level C

- zbus, if you're using Rust

For other languages, you'll want to look for bindings to one of those libraries, instead of bindings to libdbus.

I had to look up the quote but I think you have that pretty wrong. You're getting the GNOME shell and GTK mixed up.

https://trac.transmissionbt.com/ticket/3685

The ticket is about GNOME 3 removing support for status icons from the GNOME panel. GTK3 still has the status icon API, although they're deprecated and don't work on Wayland. That shouldn't have any effect on XFCE or any other shell with an old panel that supports the old X11 status icons. I think you can also restore the functionality to GNOME with an extension.

Also, if you check further down the issue you'll see this clarification:

>There should be no change in behavior for non-GNOME platforms.

There aren't actually any projects dependent on systemd in any significant capacity. I don't know where that myth comes from but it's not true.

Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.