Use the RPM instructions here:
https://dev.mysql.com/doc/workbench/en/wb-installing-linux.html
LeFantome
joined 2 years ago
I was going to recommend Flatpak but it does not seem to be on Flathub. Maybe consider one of the other SQL front-ends:
It is just a desktop app, not server software.
Unless you mean Distrobox.
Let me just say that hierarchies are for breaking ties.
The normal process is that Linus prefers we all work through maintainers to cut down on the noise that comes to him. In this case, the maintainer is the reason the noise is coming to Linus. So, it will be up to him to settle it.
Perhaps. That is not my read. I hear Linus saying that he trusts the process and that sticking with it is the solution to working through the problem. He does not say that a maintainer blocking a technically sound patch is a problem. He does not say that he would reject the patch. He does say that the approach taken by Hector ( who is not the one that submitted the patch ) is the wrong one. If Linus had said that the technical approach or the code quality was a problem, I would agree with you. He did not object to either of those things. What he said is that social media is not the solution.
The problem with your timeline is that it completely leaves out the event(s) that Linus is objecting to. I am hoping that is unintentional on your part.
I will know what Linus thinks when he either accepts or rejects the submission from the R4L team.
Really seems like we are agreeing. I get that the limited package set is a feature. I also get that it is both too small and too enterprise to satisfy most people you would describe as a “SO” precisely because they are probably normal people.
You gave the excellent example of Spotify and suggested a Flatpak for that. Honestly, I am not sure where we are in disagreement. Especially since I started by “mostly agreeing” myself. We even agree on that. :)
The release notes refer to the “few remaining issues”.
https://gitlab.gnome.org/GNOME/gimp/-/milestones/3#tab-issues
There seem to be 115 issues on there which is more than “a few”. However, only 3 are listed as blockers. But a dozen of them are crashes.
How many of these need to be fixed before the 3.0 release? Does anybody know?
In the era of Flatpak, I kind of agree with you.
The primary drawback is the complete lack of packages. A home user is going to want something not included and then things fall apart. Flatpaks and Distrobox have made that a lot better.
If you could get away with a RHEL core and Flatpak for apps, you would have a pretty solid setup for a “normal” person.
The project has said it is a goal to move to a dual language model. So, no, it is not reasonable.
What would be reasonable would be technical arguments or pragmatic logistical concerns with the goal of finding solutions. What would be reasonable would be asking for and accepting help.
None of the reasonable stuff is happening. So, it not reasonable.
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.
Fair point. I do think burn out is a problem for the process in general. I guess Linux has always benefited from the long line of people looking to contribute. As long as progress is being made, I expect that to continue here.
I do not recommend Arch to new users but I really wish people would have a point supported by evidence when they post.
There is no 50 page manual to install EndeeavourOS or CachyOS, the two distros mentioned in the graphic. Both are as easy to point and click install as Fedora and maybe easier than Debian. The better hardware support makes the install much more likely to succeed. They both have graphical installers and lead you by the hand. In fact, when it comes to EOS, its entire identify is making Arch easy to install and to provide sensible defaults so that everything works out of the box. And of the 80,000 packages in Arch/AUR, less than 20 of them are unique to EOS (mostly theming).
There are lots of things to complain about regarding Arch related distros. Or maybe there isn’t if we have to lie about them.