System76: A Case Study on How Not to Collaborate with Upstream(blogs.gnome.org)
blogs.gnome.org
System76: A Case Study on How Not to Collaborate with Upstream
https://blogs.gnome.org/christopherdavis/2021/11/10/system76-how-not-to-collaborate/
85 comments
> I didn't knew that fwupd collects statistics about which firmwares my laptops download, from where, when, etc.
That's the most alarmist way I've ever seen of referring to an HTTP access log.
That's the most alarmist way I've ever seen of referring to an HTTP access log.
> my take is that System76 had to fight for years to get an option added to fwupd, to avoid their users from getting tracked when downloading system76 firmware through the tool.
Well, no. They didn't 'fight' for that, they complained about it. For a while they decided that LVFS wasn't a right fit and went with their own tool and infrastructure[0].
To quote:
" I then got told that I’d made the LVFS and fwupd more complicated than it needed to be, and that I should have adopted the infrastructure that System76 had built instead. This was all without them actually logging into the LVFS and seeing what features were available or what constraints were being handled." [1]
But they didn't 'fight' for it. Richard Hughes fought for it. And even more than that; he implemented it, which is what counts.
> That... doesn't sound like evil to me?
Well, no. Spreading FUD on the other hand could be considered - if not evil - then at least somewhat mean[2]
> If anything, this actually makes me want to get a System76 laptop.
That's awesome. We need more people buying custom Linux hardware. The more, the merrier, the lower the costs, the better the support.
[0] https://archive.md/VPvhu
[1] https://archive.md/A4ZMS
[2] https://archive.md/UgGxn
Well, no. They didn't 'fight' for that, they complained about it. For a while they decided that LVFS wasn't a right fit and went with their own tool and infrastructure[0].
To quote:
" I then got told that I’d made the LVFS and fwupd more complicated than it needed to be, and that I should have adopted the infrastructure that System76 had built instead. This was all without them actually logging into the LVFS and seeing what features were available or what constraints were being handled." [1]
But they didn't 'fight' for it. Richard Hughes fought for it. And even more than that; he implemented it, which is what counts.
> That... doesn't sound like evil to me?
Well, no. Spreading FUD on the other hand could be considered - if not evil - then at least somewhat mean[2]
> If anything, this actually makes me want to get a System76 laptop.
That's awesome. We need more people buying custom Linux hardware. The more, the merrier, the lower the costs, the better the support.
[0] https://archive.md/VPvhu
[1] https://archive.md/A4ZMS
[2] https://archive.md/UgGxn
> Well, no. They didn't 'fight' for that, they complained about it. For a while they decided that LVFS wasn't a right fit and went with their own tool and infrastructure[0].
So why is this a problem ?
If LVFS isn't a right fit, cause its missing a feature, and they prefer to roll their own system instead of submitting a 100 LOC patch, that's kind of up to them ?
So why is this a problem ?
If LVFS isn't a right fit, cause its missing a feature, and they prefer to roll their own system instead of submitting a 100 LOC patch, that's kind of up to them ?
> So why is this a problem ?
It's not a problem at all. It just demonstrates that they didn't "fight" for the feature. Not using a service that's offered to you gratis is not a problem at all.
Spreading FUD and slandering fellow programmers might be a problem.
> that's kind of up to them ?
It absolutely is. But they still didn't fight for that. Richard Hughes fought for it.
It's not a problem at all. It just demonstrates that they didn't "fight" for the feature. Not using a service that's offered to you gratis is not a problem at all.
Spreading FUD and slandering fellow programmers might be a problem.
> that's kind of up to them ?
It absolutely is. But they still didn't fight for that. Richard Hughes fought for it.
Thanks for clarifying.
I enjoyed your post, and the other issues mentioned were easier to follow and understand what you mean.
I'm sorry that this happened.
I enjoyed your post, and the other issues mentioned were easier to follow and understand what you mean.
I'm sorry that this happened.
No worries!
Communication is hard. We misunderstand each other, even if we talk face to face. Text is even harder to parse and it's way easier to make mistakes, both when sending as well as receiving.
Thanks for your kindness and understanding!
Communication is hard. We misunderstand each other, even if we talk face to face. Text is even harder to parse and it's way easier to make mistakes, both when sending as well as receiving.
Thanks for your kindness and understanding!
So, after reading that exchange, I was left with a question. Richard Hughes:
> The way forward from my point of view would be for System76 to spend a few hours making UpdateCapsule work correctly
System76:
> UpdateCapsule is not supported by over a decade of machines in the field and could not be added without a firmware update.
> [UpdateCapsule] does not allow the reverse engineering and open-sourcing of firmware update components.
This sounds like there are technical reasons not to use UpdateCapsule, unrelated to the whole LVFS thing?
> The way forward from my point of view would be for System76 to spend a few hours making UpdateCapsule work correctly
System76:
> UpdateCapsule is not supported by over a decade of machines in the field and could not be added without a firmware update.
> [UpdateCapsule] does not allow the reverse engineering and open-sourcing of firmware update components.
This sounds like there are technical reasons not to use UpdateCapsule, unrelated to the whole LVFS thing?
I read this expecting to pooh-pooh on System76, but left thinking maybe they have a good case.
At heart are some opinionated changes by the libadwaita team to disable global styling, which align with an anti-theming petition that some of the team members support (stopthemingmy.app). These decisions wouldn't normally be particularly noteworthy, except that libadwaita seems posed to make its way into "core" GNOME software and would thusly affect System76 and their own efforts in customizing Pop_OS!.
Some of the S76 staff responses are brash, but not without merit. I'm left with the impression that distros are not considered a "customer" by these GNOME contributors, so much as the app developers in their immediate circles that shoulder the brunt of support issues caused by the problems they hope to solve.
At heart are some opinionated changes by the libadwaita team to disable global styling, which align with an anti-theming petition that some of the team members support (stopthemingmy.app). These decisions wouldn't normally be particularly noteworthy, except that libadwaita seems posed to make its way into "core" GNOME software and would thusly affect System76 and their own efforts in customizing Pop_OS!.
Some of the S76 staff responses are brash, but not without merit. I'm left with the impression that distros are not considered a "customer" by these GNOME contributors, so much as the app developers in their immediate circles that shoulder the brunt of support issues caused by the problems they hope to solve.
> I'm left with the impression that distros are not considered a "customer" by these GNOME contributors
I think that impression is correct - System76 is not considered a customer but a co-developer.
I think that impression is correct - System76 is not considered a customer but a co-developer.
The amount of misinformation on the net about theming in libadwaita is staggering. Global styling hasn't been disabled. There is nothing there that would really affect them in any significantly worse way than GTK3. That isn't to say they should do it, CSS theming will still be as broken and ill-advised as it is in GTK3, you can see that with the images at the bottom of the article.
"which align with an anti-theming petition that some of the team members support (stopthemingmy.app)"
To me this is a bad way to put it. I don't consider myself to be "anti-theming" and I agree with everything in that petition, except for the title which seems to be inflammatory and has contributed to some of the confusion and upset about theming in GTK. The title could be changed and the petition would be much better, I think. But it is probably too late for that.
"which align with an anti-theming petition that some of the team members support (stopthemingmy.app)"
To me this is a bad way to put it. I don't consider myself to be "anti-theming" and I agree with everything in that petition, except for the title which seems to be inflammatory and has contributed to some of the confusion and upset about theming in GTK. The title could be changed and the petition would be much better, I think. But it is probably too late for that.
> Global styling hasn't been disabled
But that's the plan, while working on a recoloring API leading up to Gnome 42 when libadwaita can be adopted into core apps.
But that's the plan, while working on a recoloring API leading up to Gnome 42 when libadwaita can be adopted into core apps.
It's not the plan though. You can still inject global styles into libadwaita apps. It continues to be as bad an idea as it was before. I'm happy to provide details here.
> You can still inject global styles into libadwaita apps
So a GNOME user with the POP_OS! theme will see those styling elements when opening an app that's using libadwaita, without any special modification to the app or compile process?
So a GNOME user with the POP_OS! theme will see those styling elements when opening an app that's using libadwaita, without any special modification to the app or compile process?
I don't understand the question you are asking. Yes, if you configure GTK to load some CSS, it will do that. However that won't guarantee you see the correct styles, because CSS is technically not able to do that in all cases. If there are bugs in the the Pop_OS theme then it will continue to be broken, see the images at the bottom of the article...
Edit: I kind of alluded to this before but I want to make it clear, if you are trying to make it so the user can safely load themes without "special modifications to the app or compile process", then CSS is probably the wrong choice. It is not suited to do that, CSS is only safe to use when modifying the app itself, or if you are shipping a theme as a build-time dependency in the form of a library (i.e. libadwaita). So that's kind of why your question doesn't really follow to me.
Edit: I kind of alluded to this before but I want to make it clear, if you are trying to make it so the user can safely load themes without "special modifications to the app or compile process", then CSS is probably the wrong choice. It is not suited to do that, CSS is only safe to use when modifying the app itself, or if you are shipping a theme as a build-time dependency in the form of a library (i.e. libadwaita). So that's kind of why your question doesn't really follow to me.
Come on people, it's not like gnome devs are masters of collaboration themselves.
Gnome designers can come up with a new direction that 99% of their users hate and they wouldn't even care.
Most recent releases have basically been "let's remove something everyone love and use every day, because we can". For example, they removed desktop icons and redesigned the dash to be big and ugly and always autohide and made display overview horizontal with no way to change back.
Ubuntu is using old gnome releases because if they upgraded to the last release half their paying customers would leave in anger.
Gnome designers can come up with a new direction that 99% of their users hate and they wouldn't even care.
Most recent releases have basically been "let's remove something everyone love and use every day, because we can". For example, they removed desktop icons and redesigned the dash to be big and ugly and always autohide and made display overview horizontal with no way to change back.
Ubuntu is using old gnome releases because if they upgraded to the last release half their paying customers would leave in anger.
I agree, they've shown a "we're doing it our way" attitude for years. Which is fine - they can do that if they want - just don't complain when people don't want to collaborate with you because you never consider anyone else's opinions.
Btw don't forget removing menu bars entirely and stuffing everything in a hamburger button. Who came up with that madness?
Btw don't forget removing menu bars entirely and stuffing everything in a hamburger button. Who came up with that madness?
That is a misconception. The GNOME designers I have seen are not making decisions at random or removing things because they can, there actually is data and research to back up what they are doing. If you are a designer and are interested to know more then it would benefit to talk to them and ask them for their reasons, and then maybe you could contribute meaningfully from that angle. If there is something you think they missed, and you have the data to back it up (i.e. real usage data over long periods of time from large groups of users), then I think that would be helpful.
How can you do UX design based on data, but without a proper feedback channel and at least some AB testing?
Most gnome users seem to use extensions that let them revert back to the old ways things were working. How about that as "real usage data"??
Most gnome users seem to use extensions that let them revert back to the old ways things were working. How about that as "real usage data"??
Gnome does regular UX testing[0].
There's no 'feedback' channel (other than, you know, the regular feedback channels of matrix, gitlab. They exist.) because that tends to skew the data because of self-selection.
A/B testing is only possible when you can do randomized trials. I do think that randomly switching between competing implementations of a feature could be somewhat confusing for desktop users and create a big kerfuffle. It's easy with constantly-changing websites - people expect a website to change. On the desktop, change is seldomly appreciated.
[0] https://blogs.gnome.org/shell-dev/2021/02/15/shell-ux-change...
There's no 'feedback' channel (other than, you know, the regular feedback channels of matrix, gitlab. They exist.) because that tends to skew the data because of self-selection.
A/B testing is only possible when you can do randomized trials. I do think that randomly switching between competing implementations of a feature could be somewhat confusing for desktop users and create a big kerfuffle. It's easy with constantly-changing websites - people expect a website to change. On the desktop, change is seldomly appreciated.
[0] https://blogs.gnome.org/shell-dev/2021/02/15/shell-ux-change...
I don't think they have quite enough resources to do AB testing, it seems that needs a pretty big group of people doing it over a long period of time. AFAIK they are only able to do smaller targeted studies.
I'm not sure what you mean they don't have a proper feedback channel. They have all the same ones as most other open source projects: an issue tracker, a chat room, a forum, etc.
I'm not sure what you mean they don't have a proper feedback channel. They have all the same ones as most other open source projects: an issue tracker, a chat room, a forum, etc.
Doing targeted studies among themselves is pretty much like developing in a ivory tower.
I've been following GNOME development for years, and recently getting interested in seeing how KDE handles things behind the scenes, and it's hard to miss the fact that the most prolific GNOME developers are the same 3 or 4 faces that have a really hard attitude against any type of discussion around their changes. I won't name names, but most issues on their Gitlab around any major change usually devolve into one of them saying "we're volunteers, send a merge request is you want it different". Ignoring the fact that most of their projects have opened and unanswered merge requests in the dozens. And hundreds of unanswered issues and even more on their old bugzilla.
The "volunteer" excuse is the most common passive aggressive response in the open source community, to hide behind when there's actually no real interest in entertaining different point of views or alternative suggestions.
So yeah, development is done in public, but they are set on their ways, dislike outside input and tend to get really rude and curt if you disagree with their idea. There are countless examples that pretty much anyone in the Linux community knows about.
I actually have no real qualms with the direction GNOME is going, but they are the reason I've never contributed to the project. They are a fickle and hard to please bunch, unless you're part of the internal clique.
I've been following GNOME development for years, and recently getting interested in seeing how KDE handles things behind the scenes, and it's hard to miss the fact that the most prolific GNOME developers are the same 3 or 4 faces that have a really hard attitude against any type of discussion around their changes. I won't name names, but most issues on their Gitlab around any major change usually devolve into one of them saying "we're volunteers, send a merge request is you want it different". Ignoring the fact that most of their projects have opened and unanswered merge requests in the dozens. And hundreds of unanswered issues and even more on their old bugzilla.
The "volunteer" excuse is the most common passive aggressive response in the open source community, to hide behind when there's actually no real interest in entertaining different point of views or alternative suggestions.
So yeah, development is done in public, but they are set on their ways, dislike outside input and tend to get really rude and curt if you disagree with their idea. There are countless examples that pretty much anyone in the Linux community knows about.
I actually have no real qualms with the direction GNOME is going, but they are the reason I've never contributed to the project. They are a fickle and hard to please bunch, unless you're part of the internal clique.
I really don't agree with any of what you said. I have never been part of any internal clique and I've gotten patches in. The "examples" that I have seen posted around are bugs that get posted to hostile places like certain subreddits which then go and brigade the bug tracker which pisses everyone off. If you're having problems influencing people then you may have to get to know them first and learn what motivates them, it doesn't really make sense to skip this step and then sit on the sidelines complaining that nobody is listening to you or spending their time looking at your patch. If you cannot convincingly explain how your patch is going to help upstream then you have already failed, and that's the way it is with every open source project I've ever seen. It's a collaboration, it's not just dumping code over the wall.
I also don't know what you mean "volunteer excuse", it's not an excuse, that is the truth. Those people are unpaid volunteers doing it in their spare time, you deserve to know that so you don't get the wrong expectation. If they lack time or motivation to review a backlog of issues and merge requests then dumping more merge requests on them is probably not going to help. I'm sure you can think of other ways to help out there if you're really motivated.
I also don't know what you mean "volunteer excuse", it's not an excuse, that is the truth. Those people are unpaid volunteers doing it in their spare time, you deserve to know that so you don't get the wrong expectation. If they lack time or motivation to review a backlog of issues and merge requests then dumping more merge requests on them is probably not going to help. I'm sure you can think of other ways to help out there if you're really motivated.
> I also don't know what you mean "volunteer excuse", it's not an excuse, that is the truth. Those people are unpaid volunteers doing it in their spare time, you deserve to know that so you don't get the wrong expectation. If they lack time or motivation to review a backlog of issues and merge requests then dumping more merge requests on them is probably not going to help.
So open discussion is not accepted, changes to the plan are not accepted because they're volunteers and can't accomodate everybody, merge requests are not ideal because they don't have time to review them.
Pray tell me, how does one contribute to GNOME?
And I maintain that hiding behind "I'm just a volunteer, I don't have time for that shit" is an excuse, and a bad one. There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere.
So open discussion is not accepted, changes to the plan are not accepted because they're volunteers and can't accomodate everybody, merge requests are not ideal because they don't have time to review them.
Pray tell me, how does one contribute to GNOME?
And I maintain that hiding behind "I'm just a volunteer, I don't have time for that shit" is an excuse, and a bad one. There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere.
"So open discussion is not accepted, changes to the plan are not accepted because they're volunteers and can't accomodate everybody, merge requests are not ideal because they don't have time to review them."
Please avoid this hyperbole. If you actually look, there are plenty of examples of changes being accepted. But you have to play ball with them, like I said you can't just throw code over the wall and you can't just barge in and start trying to pick a fight with someone about the design.
"There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere."
If you have advice from those projects on how to improve process to make it easier to do it then please mention that. But otherwise I really don't know what you mean, I have had issues and merge requests ignored/declined in basically every open source project I've ever contributed to.
Please avoid this hyperbole. If you actually look, there are plenty of examples of changes being accepted. But you have to play ball with them, like I said you can't just throw code over the wall and you can't just barge in and start trying to pick a fight with someone about the design.
"There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere."
If you have advice from those projects on how to improve process to make it easier to do it then please mention that. But otherwise I really don't know what you mean, I have had issues and merge requests ignored/declined in basically every open source project I've ever contributed to.
> Pray tell me, how does one contribute to GNOME?
The same way you contribute to all other Free/Open Source project:
1) Make yourself useful and demonstrate that you are able. Start by fixing [Newcomers] bugs, participate in the Matrix chat and get to know people
2) Start influencing the direction of Gnome by participating in the design and contribute to larger, architectural issues
3) Get elected to the foundation leaderboard and become a decision maker
That's about it. Three easy steps. You can start here:
https://gitlab.gnome.org/GNOME/evolution/-/issues?label_name...
The same way you contribute to all other Free/Open Source project:
1) Make yourself useful and demonstrate that you are able. Start by fixing [Newcomers] bugs, participate in the Matrix chat and get to know people
2) Start influencing the direction of Gnome by participating in the design and contribute to larger, architectural issues
3) Get elected to the foundation leaderboard and become a decision maker
That's about it. Three easy steps. You can start here:
https://gitlab.gnome.org/GNOME/evolution/-/issues?label_name...
This plan is laughable. The number of people that could actually do this is limited. It’s like saying that participating in government will help change it. No, participation leads to complicity. It won’t change anything.
So your solution would be to not participate at all, ensuring that what you want has a 0% chance of ever getting done? Can't you see how that is strictly worse?
And yeah, of course the number of people who can do it is limited, not everyone is an expert in this stuff or has an interest in becoming one...
And yeah, of course the number of people who can do it is limited, not everyone is an expert in this stuff or has an interest in becoming one...
"Three easy steps". So, if I want to fix X or at least drive the discussion forward, I need to do menial jobs for 5 years, make a name for myself before I'm allowed to tackle X? How are we surprised nobody contributes to Linux desktop software?
> participate in the Matrix chat and get to know people
I'm a software engineer, your plan is teaching me how to get into politics. I understand that knowing people is important, but sounds to me that knowing people is the most important thing in the Linux desktop business. Not the type of environment I'd thrive on nor I'm interested in participating in. Sounds to me this version of "open-source collaboration" is just looking for politicians that put the effort to enter and fit into tight-knit, closed groups, not an open-air bazaar of people brainstorming and improving code.
> participate in the Matrix chat and get to know people
I'm a software engineer, your plan is teaching me how to get into politics. I understand that knowing people is important, but sounds to me that knowing people is the most important thing in the Linux desktop business. Not the type of environment I'd thrive on nor I'm interested in participating in. Sounds to me this version of "open-source collaboration" is just looking for politicians that put the effort to enter and fit into tight-knit, closed groups, not an open-air bazaar of people brainstorming and improving code.
It is no different from the "politics" you play at work every day. Your coworkers have to like and respect you (on some level) and you have to like and respect them or you will probably have a bad time. If you are new your boss probably won't give you the root password to the production database immediately, you have to work up to it and become senior within that company.
It's not clear what you want otherwise, if you want other projects that have a lower barrier for contribution, there are plenty of those, and they also have huge backlogs in their issue trackers. I mean just think of this from the other perspective. Say you are maintaining an open source project in your spare time. Somebody comes along and asks you to do something that would take up months of your time. And the fix is somewhat complicated so instead of spending your free time with your spouse/kids/friends/etc you would have to spend it all on that fixing that issue, for months, during which no other issues can be fixed. You could close the issue with an explanation, you could say you want it eventually and then leave it open, or you could totally ignore it and leave it open. But none of those options will ever be satisfying to the reporter, sometimes people just ask for things that are not realistic. I'm sure you can relate if you have paying customers at work that have ever asked for unrealistic timelines...
It's not clear what you want otherwise, if you want other projects that have a lower barrier for contribution, there are plenty of those, and they also have huge backlogs in their issue trackers. I mean just think of this from the other perspective. Say you are maintaining an open source project in your spare time. Somebody comes along and asks you to do something that would take up months of your time. And the fix is somewhat complicated so instead of spending your free time with your spouse/kids/friends/etc you would have to spend it all on that fixing that issue, for months, during which no other issues can be fixed. You could close the issue with an explanation, you could say you want it eventually and then leave it open, or you could totally ignore it and leave it open. But none of those options will ever be satisfying to the reporter, sometimes people just ask for things that are not realistic. I'm sure you can relate if you have paying customers at work that have ever asked for unrealistic timelines...
The studies are obviously done with external groups like College students.
> there actually is data and research to back up what they are doing.
Oh really? There was data to back up that users wanted to start their desktop in Overview mode instead of the usual desktop? I'd be SUPER interested to see what kind of bullshit data was used, if this data ever exists. Right after this happened people created an extension to backtrack on this and this is one of the most popular extensions on GNOME extensions.
Oh really? There was data to back up that users wanted to start their desktop in Overview mode instead of the usual desktop? I'd be SUPER interested to see what kind of bullshit data was used, if this data ever exists. Right after this happened people created an extension to backtrack on this and this is one of the most popular extensions on GNOME extensions.
From all the questionable design choices you argue about a good one. Starting in an empty space means you go to the overview to launch an app (unless you have hot-keys to launch apps which I think GNOME doesn't have configured by default).
So it both saves you a click/gesture and it allows for new users to understand what's going on.
So it both saves you a click/gesture and it allows for new users to understand what's going on.
My pet peeve is the recent move of the dash to the bottom of the screen, thus requiring users to first move their mouse all the way to the top left corner, then all the way to the bottom just to switch apps.
I cope by not taking my hands off the keyboard and launching apps by hitting <Meta> followed by the application name. You can switch apps by <Alt>+<Tab> and <Alt><Shift>+<Tab>.
Yes, there was data to decide that, you should ask them nicely on the proper channel if you want more info. Please avoid dismissing things as "bullshit", that's rude and it doesn't help the discussion. If you have any additional data to the contrary, then now would be the time to present it. AFAIK extensions are considered as a data point but are not the only one, any time there is a design change there tends to be an extension that reverts it so it's not much of a reliable thing.
> Yes, there was data to decide that, you should ask them nicely on the proper channel if you want more info.
I'm all for asking politely if you're going to ask at all, but... why should asking even be necessary? Why not just post the justifying data by default? That seems like less work than "data available upon request if you ask nicely."
I'm all for asking politely if you're going to ask at all, but... why should asking even be necessary? Why not just post the justifying data by default? That seems like less work than "data available upon request if you ask nicely."
Well there is no marketing department, so AFAIK the designers have to balance doing blogs and press releases with all their other work which is not easy to do. It is a non-zero amount of work to explain it. If you just want to have a quick conversation about it and are interested to get involved with design then I think it would be faster to do that than trying to get them to write an entire blog article or something.
I guess the reason that they don't just post the justifying data is that ... they actually posted the justifying data[0].
google: gnome ux research
[0] https://blogs.gnome.org/shell-dev/2021/02/15/shell-ux-change...
google: gnome ux research
[0] https://blogs.gnome.org/shell-dev/2021/02/15/shell-ux-change...
That post very explicitly states that it does not in fact include the data for privacy reasons. Privacy seems like a good justification to not release the raw data, but claiming that data is available is wrong based on that post.
In particular I see nothing about starting in Overview mode (the original question about data was about that), although maybe I'm missing something not being familiar with recent Gnome releases.
In particular I see nothing about starting in Overview mode (the original question about data was about that), although maybe I'm missing something not being familiar with recent Gnome releases.
Yes there was lots of data in favor of that actually.
I have not seen a distribution where updating Gnome wasn't an issue. I hope that System76 is serious about their DE, and that if their development approach is more inclusive and better planned, other distributions will follow them.
In my opinion Gnome is a big reason why Linux Desktop is struggling to gain traction. It is not friendly to people migrating from other OS (the features are not there without tons of extensions) and it is not friendly to app and extension developers (things break after every small update and Gnome and GTK documentation is terrible).
People should stop expecting that Gnome will improve in those fronts, and similarly as Wayland is replacing Xorg, something better should replace the Gnome and gnome-shell desktop experience.
In my opinion Gnome is a big reason why Linux Desktop is struggling to gain traction. It is not friendly to people migrating from other OS (the features are not there without tons of extensions) and it is not friendly to app and extension developers (things break after every small update and Gnome and GTK documentation is terrible).
People should stop expecting that Gnome will improve in those fronts, and similarly as Wayland is replacing Xorg, something better should replace the Gnome and gnome-shell desktop experience.
I just installed fedora and I agree. Why would I want my whole screen to shrink everything every time I want to do something?
I can’t even open an app without all the stuff shuffling around and back. Why can’t I see the dock when I bring my cursor to the bottom of the screen? Oh wait I have to go all the way up there to activities to see it.
What windows do I have open? Oh wait I gotta go to activities again.
How do I minimize something? Idk, no button. Double click? No that’s just maximize. I guess I can only close stuff.
It’s almost like someone decided that we needed yet another “way “ of doing things instead of conforming to what people are used to.
I can’t even open an app without all the stuff shuffling around and back. Why can’t I see the dock when I bring my cursor to the bottom of the screen? Oh wait I have to go all the way up there to activities to see it.
What windows do I have open? Oh wait I gotta go to activities again.
How do I minimize something? Idk, no button. Double click? No that’s just maximize. I guess I can only close stuff.
It’s almost like someone decided that we needed yet another “way “ of doing things instead of conforming to what people are used to.
Wow. I didn't realise things were that bad. I stopped trying out other DEs years ago. I quit KDE after the v4 trash fire (2008), quit Gnome after v3 (2011) and had a year long affair with Openbox (nice, but needs too much work to get basics working). I settled down with XFCE about 7 years ago and never looked back (or forward). Nothing is perfect, but at least XFCE doesn't wreck my flow after an upgrade, and I can script most things I care about and attach them to keyboard shortcuts or triggers.
Eh, I find it hard to relate to complaints when Gnome devs have spent the last 20 years treating users like they don’t know how to use a mouse & telling anyone Who wants to make it better that they are wrong.
Just FYI. If your suggestions for "making it better" for yourself would be making it worse for other users, then that probably would be why your suggestions weren't taken. GNOME has made accessibility a priority for a while now, so that is why the interaction with the mouse has been done the way it is. (Disclaimer: I am not a GNOME developer, this is just my observation)
More than once the suggestions weren't breaking accessibility at all, and at least once it was GNOME devs deciding unilaterally that they know better than users who will face accessibility issues due to their changes.
Can you please give an example? Keep in mind that if a change fixes some accessibility issues for some people but then causes other accessibility regressions elsewhere, that could also be bad and not wanted. Nobody wants to be the person to make that decision and deal with the angry users, but sadly, somebody has to do it unilaterally otherwise development on the project will not happen.
Really now, if your stance is "it is bad for an open source maintainer to make decisions that might be difficult" then it seems you would have trouble finding any project that suits you.
Really now, if your stance is "it is bad for an open source maintainer to make decisions that might be difficult" then it seems you would have trouble finding any project that suits you.
Forcing single IME state globally and attempting to remove even the possibility of using per-window/application state in IBus. Mind you, this was removing the option, those who preferred single global state already could do so.
The argument was that it would lower cognitive load, without any evidence backing it up, and obviously with no input from people who regularly have to mix different input systems - where the ability for IME state to match context of the window they are in, especially as sometimes the different tasks in different windows would have incompatible needs on current IME state.
The argument was that it would lower cognitive load, without any evidence backing it up, and obviously with no input from people who regularly have to mix different input systems - where the ability for IME state to match context of the window they are in, especially as sometimes the different tasks in different windows would have incompatible needs on current IME state.
I honestly have no idea what you're talking about, I still see an option for "Allow different input sources for each window" in the keyboard settings panel.
Something like this presumably: https://bugzilla.gnome.org/show_bug.cgi?id=684210#c3
I really don't understand why you are posting this, this is a 9 year old bug that is marked fixed. Please read the rest of the comments on the bug beyond that one and please don't make me regret asking these questions, I'm feeling like my time is wasted when people post these bugs without checking them.
Note that I'm not the person who originally brought this up.
I'm posting that because (a) I believe that is the issue referred to, (b) if you look at the reactions there is definitely a lot of "why would you even want this", there is the "lower cognitive load", and they did go ahead with a release in which it was broken, even though it was reported before the release was finalized.
I'm posting that because (a) I believe that is the issue referred to, (b) if you look at the reactions there is definitely a lot of "why would you even want this", there is the "lower cognitive load", and they did go ahead with a release in which it was broken, even though it was reported before the release was finalized.
I see all that, but the issue is fixed now. Yeah they made a design mistake and then they corrected it, it doesn't seem to be much different from any other bug. If you are trying to get help with something, it is not particularly useful to cherry pick comments from a long time ago that are not even relevant anymore. I'm sure we could go through the old bug tracker and find various disagreements in other areas, but that won't really help with the status of a current bug.
At one point there was even a patch to IBus pushed by GNOME devs that simply removed such functionality.
MLooks like this post won't play out well for Gnome. Plus System76 is building its own desktop environment in Rust.
They also need to build their own toolkit (this one hopefully not in Rust or at least if in Rust with a C API that is accessible outside of Rust) because at this point Gtk is a vector for Gnomisms to projects outside of Gnome.
Honestly IMO there needs to be a new toolit, one that understands the important of ABI stability over an actual long period of time (see Win32) and being easy to interface by a variety of different languages without having to spent ages for each interface. Gtk fails at the first, Qt fails at both.
Honestly IMO there needs to be a new toolit, one that understands the important of ABI stability over an actual long period of time (see Win32) and being easy to interface by a variety of different languages without having to spent ages for each interface. Gtk fails at the first, Qt fails at both.
They said they weren't going to do that and they would continue to use GTK.
Also, this is wrong:
"because at this point Gtk is a vector for Gnomisms to projects outside of Gnome."
In GTK4 the goal has actually been to intentionally move GNOME specific bits out of gtk and into libadwaita. I can provide a source, if you want.
"one that understands the important of ABI stability over an actual long period of time"
I mean, I hear this asked for frequently but it's not clear what you want. You can keep using Qt 2/3, GTK 1/2 and those are technically "stable" but of course the trade off there is that you don't get new features, or bug fixes. So if you want someone to do something with those, it would help to ask for what you want specifically.
Also, this is wrong:
"because at this point Gtk is a vector for Gnomisms to projects outside of Gnome."
In GTK4 the goal has actually been to intentionally move GNOME specific bits out of gtk and into libadwaita. I can provide a source, if you want.
"one that understands the important of ABI stability over an actual long period of time"
I mean, I hear this asked for frequently but it's not clear what you want. You can keep using Qt 2/3, GTK 1/2 and those are technically "stable" but of course the trade off there is that you don't get new features, or bug fixes. So if you want someone to do something with those, it would help to ask for what you want specifically.
>Also, this is wrong: [..] "because at this point Gtk is a vector for Gnomisms to projects outside of Gnome." [..] In GTK4 the goal has actually been to intentionally move GNOME specific bits out of gtk and into libadwaita. I can provide a source, if you want.
I do not see it as wrong, Gtk and GNOME developers have said a lot of stuff over the year but at the end of the day it is what they do that matters and ever since Gtk3 they basically took over Gtk.
> I mean, I hear this asked for frequently but it's not clear what you want.
How is it not clear, i explicitly provided Win32 as an example right after the part you cut at. After all...
> You can keep using Qt 2/3, GTK 1/2 and those are technically "stable" but of course the trade off there is that you don't get new features, or bug fixes.
...Win32 does get new features and bug fixes all the time - even the pre-XP controls (i mean the non-themed common controls) still get updates.
Qt 2/3 and Gtk 1 (not Gtk 2 so far though) aren't realistic targets either as you can't make a binary and expect it to be available anywhere - except perhaps Slackware which still distributes Gtk 1 (i do not think it distributes Qt 2 or 3 though). So you have to bundle the libraries with your application (**please** do not compare this with Windows, Windows come with a A TON of stuff you can rely to be there even if you do not use it - like a GUI toolkit for example... actually a bunch of GUI toolkits, but let's stick with Win32 which is what i originally brought up) which not only bloat the application itself but also version lock the dependencies to whatever you bundled, including its features and bugs.
So for example a Gtk2 or Qt 2 or Qt 3 application (and perhaps a Qt 4 application too, though not 100% sure) might work but, e.g., it wont get a Wayland backend because the bundled version you have was never updated for it. It also wont get high DPI support for the same reasons. If you bundle Gtk3 or Gtk4 or Qt 5 now and someone finally implements per-monitor window events under X11 for scaling like in Windows which also requires toolkit support, your application wont support those because instead of using the system bundled libraries, you use your own. If some distribution decides that enough is enough and implements a better file dialog for Gtk again your application wont get the new functionality because instead of using the distribution's libraries you use your own. Etc.
What i want is simple: a stable ABI so that binary applications can keep working in future (think timeframes of 20, 30 years and more, not just a couple of years or whatever) while getting new features whenever that is technically possible with the same binaries, a stable and backwards compatible API so that source code can still be compiled as-is in the future (or at least the library wont be the reason it wont be compilable) while still getting new features for applications that are still in active development to use so that they look, perform and behave better but without forcing everyone to upgrade in a step-lock but instead letting them do that whenever they can (and assuming they even need the updates - let applications where these updates do not matter for keep using the existing APIs), any documentation, be it first party or third party, that was written over the years wont be invalidated and the invaluable and limited time of documentation writers wont be wasted and instead be used on new stuff where that matters, the knowledge of those who bothered to learn the library wont be invalidated, application developers who spent time targeting the library wont have to waste time re-do things that they've already done just to get more or less the same result, etc.
See OpenGL as an example: now OpenGL has gained bad rep over the recent years (and i personally blame Khronos over its mismanagement) but regardless, a Windows application that was written back in the late 90s using the OpenGL 1.1 API worked on GPUs of the time that usually all they could do was triangle rasterization and everything else was done on the CPU. Then the exact same application, same EXE file, could run on a later GeForce 2 TI that implemented many parts of the API in hardware. Then nowadays, the exact same application, same EXE file, can run on a modern GPU that got rid almost all of the fixed function hardware but still implements the same API largely in shaders - but the program works and has better performance than it ever did, even if it doesn't have the best performance it could have. But even better, it can get functionality like MSAA support from the drivers, triple buffering, vsync control, etc that didn't exist at the time. What is more, if the source is still around, chances are it can be recompiled as-is (or at least the OpenGL bits could) and its functionality be extended by adding additional code alongside the existing code to use new features like shaders. In fact this is what Beamdog did with Neverwinter Nights: Extended Edition where the original game was written against OpenGL 1.x but they - almost two decades later - started adding additional functionality to the game (but the original game still works fine).
What i ask isn't fantasy, it is something other APIs have done, including the Win32 API (at least the GUI bits) which pretty much offers what a toolkit offers in Linux.
I do not see it as wrong, Gtk and GNOME developers have said a lot of stuff over the year but at the end of the day it is what they do that matters and ever since Gtk3 they basically took over Gtk.
> I mean, I hear this asked for frequently but it's not clear what you want.
How is it not clear, i explicitly provided Win32 as an example right after the part you cut at. After all...
> You can keep using Qt 2/3, GTK 1/2 and those are technically "stable" but of course the trade off there is that you don't get new features, or bug fixes.
...Win32 does get new features and bug fixes all the time - even the pre-XP controls (i mean the non-themed common controls) still get updates.
Qt 2/3 and Gtk 1 (not Gtk 2 so far though) aren't realistic targets either as you can't make a binary and expect it to be available anywhere - except perhaps Slackware which still distributes Gtk 1 (i do not think it distributes Qt 2 or 3 though). So you have to bundle the libraries with your application (**please** do not compare this with Windows, Windows come with a A TON of stuff you can rely to be there even if you do not use it - like a GUI toolkit for example... actually a bunch of GUI toolkits, but let's stick with Win32 which is what i originally brought up) which not only bloat the application itself but also version lock the dependencies to whatever you bundled, including its features and bugs.
So for example a Gtk2 or Qt 2 or Qt 3 application (and perhaps a Qt 4 application too, though not 100% sure) might work but, e.g., it wont get a Wayland backend because the bundled version you have was never updated for it. It also wont get high DPI support for the same reasons. If you bundle Gtk3 or Gtk4 or Qt 5 now and someone finally implements per-monitor window events under X11 for scaling like in Windows which also requires toolkit support, your application wont support those because instead of using the system bundled libraries, you use your own. If some distribution decides that enough is enough and implements a better file dialog for Gtk again your application wont get the new functionality because instead of using the distribution's libraries you use your own. Etc.
What i want is simple: a stable ABI so that binary applications can keep working in future (think timeframes of 20, 30 years and more, not just a couple of years or whatever) while getting new features whenever that is technically possible with the same binaries, a stable and backwards compatible API so that source code can still be compiled as-is in the future (or at least the library wont be the reason it wont be compilable) while still getting new features for applications that are still in active development to use so that they look, perform and behave better but without forcing everyone to upgrade in a step-lock but instead letting them do that whenever they can (and assuming they even need the updates - let applications where these updates do not matter for keep using the existing APIs), any documentation, be it first party or third party, that was written over the years wont be invalidated and the invaluable and limited time of documentation writers wont be wasted and instead be used on new stuff where that matters, the knowledge of those who bothered to learn the library wont be invalidated, application developers who spent time targeting the library wont have to waste time re-do things that they've already done just to get more or less the same result, etc.
See OpenGL as an example: now OpenGL has gained bad rep over the recent years (and i personally blame Khronos over its mismanagement) but regardless, a Windows application that was written back in the late 90s using the OpenGL 1.1 API worked on GPUs of the time that usually all they could do was triangle rasterization and everything else was done on the CPU. Then the exact same application, same EXE file, could run on a later GeForce 2 TI that implemented many parts of the API in hardware. Then nowadays, the exact same application, same EXE file, can run on a modern GPU that got rid almost all of the fixed function hardware but still implements the same API largely in shaders - but the program works and has better performance than it ever did, even if it doesn't have the best performance it could have. But even better, it can get functionality like MSAA support from the drivers, triple buffering, vsync control, etc that didn't exist at the time. What is more, if the source is still around, chances are it can be recompiled as-is (or at least the OpenGL bits could) and its functionality be extended by adding additional code alongside the existing code to use new features like shaders. In fact this is what Beamdog did with Neverwinter Nights: Extended Edition where the original game was written against OpenGL 1.x but they - almost two decades later - started adding additional functionality to the game (but the original game still works fine).
What i ask isn't fantasy, it is something other APIs have done, including the Win32 API (at least the GUI bits) which pretty much offers what a toolkit offers in Linux.
"it is what they do that matters and ever since Gtk3 they basically took over Gtk."
I don't know what else to tell you. If you follow what is happening in GTK4 you will see that they are moving things out of GTK. This is what they are doing at this current point. Also I hope you understand that this stuff is all open source and nobody is "taking over" any projects, it's simply whoever shows up gets to make the decision. It was mostly GNOME that was contributing upstream during GTK3 so that's what happened.
"How is it not clear, i explicitly provided Win32 as an example right after the part you cut at."
Right, if you want Win32 API, you would use Wine for that. But if that's not adequate then please explain. And yes I know there are bugs and missing features in Wine, so that would be the place to start instead of trying to make a new toolkit that would also be incompatible. If you cared about compatibility with old apps then I'm actually very confused as to why you would be asking for a new toolkit, old apps that don't get updated would never use it.
"...Win32 does get new features and bug fixes all the time - even the pre-XP controls (i mean the non-themed common controls) still get updates."
Okay but which updates. If you want something implemented in Wine or you want something backported to GTK 1 or Qt 2 or whatever then you need to mention that. I can't guess what it is you want.
"So you have to bundle the libraries with your application which not only bloat the application itself but also version lock the dependencies to whatever you bundled, including its features and bugs."
This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time.
"it wont get a Wayland backend because the bundled version you have was never updated for it. It also wont get high DPI support for the same reasons"
Ok these are real things to ask for, that someone could feasibly attempt to do. I would say just skip all the other things you asked for, cut out the rest of your comment, and just ask for this, because these are real missing features that could be put into an action item. But actually, I don't think either of these would be technically possible for a lot of apps. If an older app uses Xlib functions then that won't work with a native Wayland backend. If it draws pixels to a buffer and doesn't calculate scale then it won't work with high DPI. (You would be surprised how many older apps actually do this...) So that is unfortunately not something that can be fixed in all cases by trying to backport things to an old API and I think you would largely be wasting your time trying to implement those things. At some point you have to accept that the old APIs are just not suitable for some things.
OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations.
"What i want is simple: a stable ABI so that binary applications can keep working in future (think timeframes of 20, 30 years and more, not just a couple of years or whatever)"
I mean, already I mentioned how it would maybe be possible to get this in some limited form. But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that.
I don't know what else to tell you. If you follow what is happening in GTK4 you will see that they are moving things out of GTK. This is what they are doing at this current point. Also I hope you understand that this stuff is all open source and nobody is "taking over" any projects, it's simply whoever shows up gets to make the decision. It was mostly GNOME that was contributing upstream during GTK3 so that's what happened.
"How is it not clear, i explicitly provided Win32 as an example right after the part you cut at."
Right, if you want Win32 API, you would use Wine for that. But if that's not adequate then please explain. And yes I know there are bugs and missing features in Wine, so that would be the place to start instead of trying to make a new toolkit that would also be incompatible. If you cared about compatibility with old apps then I'm actually very confused as to why you would be asking for a new toolkit, old apps that don't get updated would never use it.
"...Win32 does get new features and bug fixes all the time - even the pre-XP controls (i mean the non-themed common controls) still get updates."
Okay but which updates. If you want something implemented in Wine or you want something backported to GTK 1 or Qt 2 or whatever then you need to mention that. I can't guess what it is you want.
"So you have to bundle the libraries with your application which not only bloat the application itself but also version lock the dependencies to whatever you bundled, including its features and bugs."
This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time.
"it wont get a Wayland backend because the bundled version you have was never updated for it. It also wont get high DPI support for the same reasons"
Ok these are real things to ask for, that someone could feasibly attempt to do. I would say just skip all the other things you asked for, cut out the rest of your comment, and just ask for this, because these are real missing features that could be put into an action item. But actually, I don't think either of these would be technically possible for a lot of apps. If an older app uses Xlib functions then that won't work with a native Wayland backend. If it draws pixels to a buffer and doesn't calculate scale then it won't work with high DPI. (You would be surprised how many older apps actually do this...) So that is unfortunately not something that can be fixed in all cases by trying to backport things to an old API and I think you would largely be wasting your time trying to implement those things. At some point you have to accept that the old APIs are just not suitable for some things.
OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations.
"What i want is simple: a stable ABI so that binary applications can keep working in future (think timeframes of 20, 30 years and more, not just a couple of years or whatever)"
I mean, already I mentioned how it would maybe be possible to get this in some limited form. But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that.
> Right, if you want Win32 API [...] Okay but which updates [...] Ok these are real things to ask for, that someone could feasibly attempt to do.
These are examples. I'm not asking to use Win32 or add updates to Gtk1 or Gtk2. The important part is keeping ABI and API stability. Also i refer to what i'd like to see in a hypothetical library that did things right, not the current ones that either keep doing everything wrong (Gtk) or even if they wanted they can't due to the tech they're based on (Qt, though chances are even Qt could stay API and ABI compatible they wouldn't because they're primary middleware for paying corporations and only secondary a platform library that happened by chance thanks to KDE).
> OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations.
It is a great example because it shows that it can remain API and ABI compatible for decades. Also both CPU and GPU parallelization could be implemented with extensions (though GPU parallelization is something that GPU vendors seem to be moving away from) in a variety of ways, e.g. using display lists in different threads a per-thread shared context that records a thread-local command list for the operations inside the display list than later can be executed via the render thread. Similarly different contexts can be "bound" to different GPUs and yet allow for resource sharing. Those may or may not need new APIs (most likely will) but are still possible. Or a more low-level approach like Nvidia's command list extension could be used instead.
> But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that.
Well, i'm not explicitly asking for someone to do anything, especially from projects that do not seem to be interested in any of that. My comment was about what i ask for to exist, not what i ask for from someone or some specific project.
Also
> This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time.
This isn't a separate problem, it is a problem that exists because libraries do not have stable ABIs and programs cannot rely on libraries that are on the system to provide fundamental functionality that wont break (or even wont disappear) in a couple of years (or whatever other short timespan).
There is this great commentary by Linus from almost a decade ago...
https://www.youtube.com/watch?v=Pzl1B7nB9Kc
...where he went into the issues and yet they are still there because instead of trying to fix the problem at the core (which is what he explicitly mentions about ABI stability, like it is done in the Linux kernel - BTW this also would be a good example), the developers who work on these projects instead decided that the best solution isn't to decide and stick with a stable ABI but instead provide a standardized form of the "bundle your own libraries" approach - which barely solves anything related to not having stable ABIs.
These are examples. I'm not asking to use Win32 or add updates to Gtk1 or Gtk2. The important part is keeping ABI and API stability. Also i refer to what i'd like to see in a hypothetical library that did things right, not the current ones that either keep doing everything wrong (Gtk) or even if they wanted they can't due to the tech they're based on (Qt, though chances are even Qt could stay API and ABI compatible they wouldn't because they're primary middleware for paying corporations and only secondary a platform library that happened by chance thanks to KDE).
> OpenGL is not really a good example because while it might be easy to add some things like vsync and triple buffering, other things (like GPU parallelization) are basically impossible (or extremely impractical) to try to hack into in the GL implementation. The fixed function mode is always going to have its limitations.
It is a great example because it shows that it can remain API and ABI compatible for decades. Also both CPU and GPU parallelization could be implemented with extensions (though GPU parallelization is something that GPU vendors seem to be moving away from) in a variety of ways, e.g. using display lists in different threads a per-thread shared context that records a thread-local command list for the operations inside the display list than later can be executed via the render thread. Similarly different contexts can be "bound" to different GPUs and yet allow for resource sharing. Those may or may not need new APIs (most likely will) but are still possible. Or a more low-level approach like Nvidia's command list extension could be used instead.
> But someone has to actually put in the work to get it. Keep in mind, it is not helpful to keep requesting that small open source projects do things exactly how a trillion dollar corporation is able to. You are wasting your time asking for that.
Well, i'm not explicitly asking for someone to do anything, especially from projects that do not seem to be interested in any of that. My comment was about what i ask for to exist, not what i ask for from someone or some specific project.
Also
> This is an entirely separate problem of which there are multiple solutions to. Let's not get into this though, take it one step at a time.
This isn't a separate problem, it is a problem that exists because libraries do not have stable ABIs and programs cannot rely on libraries that are on the system to provide fundamental functionality that wont break (or even wont disappear) in a couple of years (or whatever other short timespan).
There is this great commentary by Linus from almost a decade ago...
https://www.youtube.com/watch?v=Pzl1B7nB9Kc
...where he went into the issues and yet they are still there because instead of trying to fix the problem at the core (which is what he explicitly mentions about ABI stability, like it is done in the Linux kernel - BTW this also would be a good example), the developers who work on these projects instead decided that the best solution isn't to decide and stick with a stable ABI but instead provide a standardized form of the "bundle your own libraries" approach - which barely solves anything related to not having stable ABIs.
The vitriol thrown at Gnome devs has always been a needed reminder that engineers are just as capable of falling for a surface-level and biased narrative as the average American. The fact that many of the Gnome maintainers still continue to develop the Gnome ecosystem is a bonafide miracle.
The one grain of truth in this mess is that many diehard desktop users don't want innovation, they want the traditional 00s style desktop. MATE, Cinnamon and XFCE serve that crowd swimmingly so can we stop with the hate?
The one grain of truth in this mess is that many diehard desktop users don't want innovation, they want the traditional 00s style desktop. MATE, Cinnamon and XFCE serve that crowd swimmingly so can we stop with the hate?
I was thinking something similar: on one hand system76 is probably wrong, but on the other hand gnome is trash and consistently screws up their users so...
So happy I moved to XFCE (and i've been trying KDE lately).
So happy I moved to XFCE (and i've been trying KDE lately).
Linux has taken over the server space.
But Linux can't even keep up with OSX in market share, or more importantly, developer effort for games/apps/etc.
So Gnome should ask itself after about two decades... are they helping or hurting. KDE should ask itself a similar question.
Gnome has several active Gnome2 forks out there and Gnome3, KDE is simply ... ok
And even then, Unity was another attempt, and who knows what ChromeOS is built on.
Linux already pissed away the golden opportunity of Windows 8. Now that Apple is leading an ISA shift from x86 to ARM on the desktop, Linux needs to get its desktop situation ready.
Linux and OSS are uniquely positioned to outclass Windows in the ISA move, arguably they are in a better position than OSX was in the M1 move. A huge portion of its applications can simply be ported with a decently supported recompile and I think there are package infrastructures that will well support an ARM ISA changeover.
The issue is the desktop. The blocker is the desktop. The barrier is the desktop.
I welcome System76 to take no prisoners in this critical period. If they fail, well, oh well. If they push Gnome/KDE to keep up out of paranoia, well, good.
Just please people, please. Windows is awful. OSX is becoming a jail.
But Linux can't even keep up with OSX in market share, or more importantly, developer effort for games/apps/etc.
So Gnome should ask itself after about two decades... are they helping or hurting. KDE should ask itself a similar question.
Gnome has several active Gnome2 forks out there and Gnome3, KDE is simply ... ok
And even then, Unity was another attempt, and who knows what ChromeOS is built on.
Linux already pissed away the golden opportunity of Windows 8. Now that Apple is leading an ISA shift from x86 to ARM on the desktop, Linux needs to get its desktop situation ready.
Linux and OSS are uniquely positioned to outclass Windows in the ISA move, arguably they are in a better position than OSX was in the M1 move. A huge portion of its applications can simply be ported with a decently supported recompile and I think there are package infrastructures that will well support an ARM ISA changeover.
The issue is the desktop. The blocker is the desktop. The barrier is the desktop.
I welcome System76 to take no prisoners in this critical period. If they fail, well, oh well. If they push Gnome/KDE to keep up out of paranoia, well, good.
Just please people, please. Windows is awful. OSX is becoming a jail.
The thing that's keeping Linux from taking over the desktop is the thing that kept Windows from taking over the desktop: OEM preinstalls. As soon as there are enough OEMs shipping consumer kit that runs Linux (and doesn't crumple under Microsoft pressure) then Linux will be a force to be reckoned with on the desktop. Otherwise, all of the DE bikeshedding in the world won't get Linux's foot in the door.
It's a long shot, because Microsoft pretty much controls and defines what a "PC" is now, but maybe there's an opportunity for Raspberry Pi, Pine64 and other SBC vendors here.
It's a long shot, because Microsoft pretty much controls and defines what a "PC" is now, but maybe there's an opportunity for Raspberry Pi, Pine64 and other SBC vendors here.
I have heard people saying that for 20 years. "We just need to get more OEM preinstalls and then Windows will fail." Meanwhile, various OEMs have come and gone (i.e. they all crumpled under the pressure) and nothing happened. System76 has been around for 16 years, they have their niche but that's about it. Ultimately, they are a hardware company making a distribution that works well with their laptops, and that's all they can really do.
For any of these companies, I would seriously ask them "do you think you can be the next Microsoft or Apple, and if so what would you do to get there". And if the answer has something to do with trying to convince OEMs to install Linux, or trying to ship more random embedded devices, then I probably say they need to come up with a new plan.
For any of these companies, I would seriously ask them "do you think you can be the next Microsoft or Apple, and if so what would you do to get there". And if the answer has something to do with trying to convince OEMs to install Linux, or trying to ship more random embedded devices, then I probably say they need to come up with a new plan.
I understand the sentiment, but I think the forgotten part on OEM installs is, current OEM offerings are on more premium models. I would be curious to see what would happen if Dell or Hp made like a 250-400 dollar laptop and put it on shelves in Best Buy and Walmart with Ubuntu, Pop or Mint installed. I don't know if it would work, but interesting to try. Like I said, most OEM install tries have been on premium hardware, or in the case of the PineBook, for the person who wants to tinker.
EDIT: Especially since winning on the desktop would be mass adoption. Most home computers are not Dell XPs Or Lenovo thinkpads. And marketing cheap laptops geared to students works in the case of ChromeOS
EDIT: Especially since winning on the desktop would be mass adoption. Most home computers are not Dell XPs Or Lenovo thinkpads. And marketing cheap laptops geared to students works in the case of ChromeOS
I think Walmart tried the downmarket linux thing about ... wow, ten years ago maybe? I see an article on Everex Green GPC, I thought there was another one too.
But.. the linux desktop is way better today compared to then, despite my bitching about it.
Maybe a kickass turnkey cloud-based desktop solution would be a big uptake. AWS has won servers, but why shouldn't they win desktops too? What company doesn't want to move to remote desktops for everyone?
That would probably take some investment in stabilizing the remote/RDP video drivers, a lot like what has always plagued linux desktop: video support and drivers.
But.. the linux desktop is way better today compared to then, despite my bitching about it.
Maybe a kickass turnkey cloud-based desktop solution would be a big uptake. AWS has won servers, but why shouldn't they win desktops too? What company doesn't want to move to remote desktops for everyone?
That would probably take some investment in stabilizing the remote/RDP video drivers, a lot like what has always plagued linux desktop: video support and drivers.
Dell does already ship a laptop with Ubuntu installed. No I don't think Best Buy and Walmart carry it, because the only target market for it is developers. I remember seeing lots of cheap netbooks that had a Linux option but no stores carried them because nobody besides developers and geeks actually wants that.
My experience with Dell's laptops, despite being supposedly ubuntu supported, would randomly restart, trackpad stopped working, and their docks wouldn't be compatible with linux.
Dell arguably did more damage: by releasing a flawed product, then the rest of the OEMs said "See? No one wants linux".
Dell arguably did more damage: by releasing a flawed product, then the rest of the OEMs said "See? No one wants linux".
I don't think this is going to help at all. There are already way too many desktops for Linux and none of them are pushing GNOME or KDE to keep up. To me this is just another one to add to the pile sadly. We already went through this whole song and dance with Canonical and Unity and that ended up dead as well.
ChromeOS (and Android) are their own things and not related to any of the other projects. If somebody was building a new desktop and had a few hundred million dollars to spare I would say just do that similar to how Google did it. A company with those resources would be wasting them by involving itself with the open source desktops, those projects are perpetually in a state of being 5-10 years behind. Of course that means they would have to bring their own app ecosystem too.
ChromeOS (and Android) are their own things and not related to any of the other projects. If somebody was building a new desktop and had a few hundred million dollars to spare I would say just do that similar to how Google did it. A company with those resources would be wasting them by involving itself with the open source desktops, those projects are perpetually in a state of being 5-10 years behind. Of course that means they would have to bring their own app ecosystem too.
So?
Linux works fine for me on the desktop. That’s what I care about. Melt neighbour may prefer BSD, or OSX, or windows, that’s fine
The idea that it’s a war to be won is sad. The only “war” should be against monoculture, and HN in particular loves monoculture.
Linux works fine for me on the desktop. That’s what I care about. Melt neighbour may prefer BSD, or OSX, or windows, that’s fine
The idea that it’s a war to be won is sad. The only “war” should be against monoculture, and HN in particular loves monoculture.
The problem with linux is not the desktop itself, but almost the whole of the userspace.
First of all, security, or the lack of it. The age-old xkcd is still true, where an attacker can’t install a video card driver on my laptop, but can encrypt, read, send, record basically everything I actually care about on a desktop, and it doesn’t even have to try (seriously, just hide a bash script wherever you want or append to bashrc). Running everything as the same user when no finer grade authorization is available is simply a no go.
Yeah, there is flatpak but I feel it tries to be two things at once, and not being the best in either of them (package management and sandbox). I think we should not imitate what docker or other OSs do, when we have nix, which is imo a superior solution to the problem and we should embrace it. As for the security, we do have SELinux which works very well for courser authorization (fedora does a decent job at it!), but it should be combined with a supportive capability-based security system a la Android, where new processes run as different user from the actual one, and all IPC should happen through some controlled manner.
My second gripe: why do linux people insist on using C for goddamn everything? And no, I’m not advocating for “rewrite everything in X”, but come on, should gnome’s welcome screen be a C executable, really? Especially knowing that bash scripting (which is even worse than C from a correctness POV in my opinion) is the often used alternative —- meaning that performance is nowhere near an issue as goddamn scratch is faster than bash. So other than pipewire, there really are not many places where such low level control/performance is needed, meaning that Java, C# or the other litany of GCd languages could work perfectly fine, and they would likely even increase productivity/maintainability.
First of all, security, or the lack of it. The age-old xkcd is still true, where an attacker can’t install a video card driver on my laptop, but can encrypt, read, send, record basically everything I actually care about on a desktop, and it doesn’t even have to try (seriously, just hide a bash script wherever you want or append to bashrc). Running everything as the same user when no finer grade authorization is available is simply a no go.
Yeah, there is flatpak but I feel it tries to be two things at once, and not being the best in either of them (package management and sandbox). I think we should not imitate what docker or other OSs do, when we have nix, which is imo a superior solution to the problem and we should embrace it. As for the security, we do have SELinux which works very well for courser authorization (fedora does a decent job at it!), but it should be combined with a supportive capability-based security system a la Android, where new processes run as different user from the actual one, and all IPC should happen through some controlled manner.
My second gripe: why do linux people insist on using C for goddamn everything? And no, I’m not advocating for “rewrite everything in X”, but come on, should gnome’s welcome screen be a C executable, really? Especially knowing that bash scripting (which is even worse than C from a correctness POV in my opinion) is the often used alternative —- meaning that performance is nowhere near an issue as goddamn scratch is faster than bash. So other than pipewire, there really are not many places where such low level control/performance is needed, meaning that Java, C# or the other litany of GCd languages could work perfectly fine, and they would likely even increase productivity/maintainability.
What do you think of System76 developing their own desktop environment?
HN post: https://news.ycombinator.com/item?id=29137180
HN post: https://news.ycombinator.com/item?id=29137180
Sounds cool. If they can fund it & have fun doing it could be neat.
All desktops started at Zero and competition will drive others to stay ahead or fall behind
All desktops started at Zero and competition will drive others to stay ahead or fall behind
that's alarming! They give examples where PopOS should have worked with upstream... they are
youtube-dl breaking [0] -- the bug was open for 21 days before maintainer fixed it... once it was fixed, it took about 10 more days to propagate to older releases. And this was for the script whose only purpose was to interact with 3rd party websites -- it makes no sense to use older versions, they likely won't work at all!
nvidia lid closing problems [1]: bug reported 2017-11-05 and includes ready to apply patch. 2019-06-11, more than 19 months later, system76 mentions the patch is not applied and recommends PopOS... only then maintainers notice this and fast-track into Ubuntu.
Not sure who is right there, but they are really not making the case for working with upstream.
[0] https://bugs.launchpad.net/ubuntu/+source/youtube-dl/+bug/18...
[1] https://bugs.launchpad.net/ubuntu/+source/youtube-dl/+bug/18...
youtube-dl breaking [0] -- the bug was open for 21 days before maintainer fixed it... once it was fixed, it took about 10 more days to propagate to older releases. And this was for the script whose only purpose was to interact with 3rd party websites -- it makes no sense to use older versions, they likely won't work at all!
nvidia lid closing problems [1]: bug reported 2017-11-05 and includes ready to apply patch. 2019-06-11, more than 19 months later, system76 mentions the patch is not applied and recommends PopOS... only then maintainers notice this and fast-track into Ubuntu.
Not sure who is right there, but they are really not making the case for working with upstream.
[0] https://bugs.launchpad.net/ubuntu/+source/youtube-dl/+bug/18...
[1] https://bugs.launchpad.net/ubuntu/+source/youtube-dl/+bug/18...
Me wonders if the gnome his are aware of the further barriers to entry they're effectively creating by dragging up settled arguments.
Not a fan of anything they've done recently under the gnome banner and don't see that changing too despite the IBM/RH money backing some of the project.
Not a fan of anything they've done recently under the gnome banner and don't see that changing too despite the IBM/RH money backing some of the project.
This post is by one person, not GNOME.
Yes, and my comment does not represent the entire non gnome community.
My point is that the gnome devs are often acting a little precious to their idealised project and don't want to let control go. The fact so many distros ship with growing patchsets is proof to the problems in vanilla gnome.
My point is that the gnome devs are often acting a little precious to their idealised project and don't want to let control go. The fact so many distros ship with growing patchsets is proof to the problems in vanilla gnome.
system76 isnt alone, openbsd devs and packagers regularly also dont share with upstream too. they even got caught so they change their policy on sharing https://marc.info/?t=160764244000001&r=1&w=2
You mean they got "caught" breaking their own policy, which they imposed on themselves, and they didn't break any copyrights?
I don't get all of the hostility against GNOME. If you don't like it... use something else? System 76 has been trying to have their cake and eat it too, using GNOME but not jumping through all of the GNOME hoops.
I guess the latest new is they're going to get away from GNOME and make their own DE, which is great news for all involved.
I guess the latest new is they're going to get away from GNOME and make their own DE, which is great news for all involved.
I agree that those are great news that someone is making a new DE.
But currently switching away from Gnome is not that simple, especially if you dislike KDE. A lot of work is being put into making Wayland usable, and a lot of interfaces for features that everyone expects from a modern computer don't really exist outside of Gnome and KDE yet.
As I see it, a lot of users are not forced to use Gnome, but because of their dominance, there aren't many modern mature alternatives to it.
I am a Gnome user myself and with every single update lots of extensions break. Without those extensions I can't really use Linux Desktop efficiently. What would you say if your browser extensions got broken with every browser update?
But currently switching away from Gnome is not that simple, especially if you dislike KDE. A lot of work is being put into making Wayland usable, and a lot of interfaces for features that everyone expects from a modern computer don't really exist outside of Gnome and KDE yet.
As I see it, a lot of users are not forced to use Gnome, but because of their dominance, there aren't many modern mature alternatives to it.
I am a Gnome user myself and with every single update lots of extensions break. Without those extensions I can't really use Linux Desktop efficiently. What would you say if your browser extensions got broken with every browser update?
The goal of the author here is to show how bad System76 behaved. But after reading this, clicking the links, and reading the PR that actually got implemented (link above) my take is that System76 had to fight for years to get an option added to fwupd, to avoid their users from getting tracked when downloading system76 firmware through the tool.
That... doesn't sound like evil to me? I didn't knew that fwupd collects statistics about which firmwares my laptops download, from where, when, etc. and sends them to the hardware vendors. Is there a way for users to disable this tracking for all firmwares from all vendors?
If anything, this actually makes me want to get a System76 laptop.