> You're right. The Java SIG was not organised around an account group, > so it does not exist. I don't know why it is that way, but that could > easily be fixed - other language interest groups are organised this > way, after all (python-sig, go-sig, ruby-sig, etc.).
I don't really understand what you're saying here. But I'd like to fix it. > There's even a Java package group set up there: > https://koschei.fedoraproject.org/groups/java I will look at that. > the retrace server not supporting Zstd-compressed RPM packages, which > was a feature introduced in fedora 31. It's a known issue, and people > are working on fixing it. Awesome. > The release cadence is not a problem, in my opinion. Even if fedora > only released every two years, Java packages would still be > unmaintained and broken - Yea, I guess that is the problem. > That's not really fair. DNF is pretty much only the user interface, > and everything it's built on top of (hawkey, librepo, libsolv) is > implemented in C / C++. And when I think back to using yum, dnf is > really fast :) When I type "sudo dnf install something" it takes about 10 minutes to pull updates from every repository, every time I run dnf. The actual install or update proceeds at a reasonable pace. I wouldn't call it fast. I could send you a video of this if you'd like. I see this on all my machines and I see other people complaining about it too. In contrast, if I type "sudo apt install something" on Ubuntu or Debian, a bunch of text goes by really fast and BAM, it's done... If I do "sudo apt update" it's also a lot faster than dnf. I don't know if the problem is dnf or a library, but it is a serious problem. > I don't know which performance problems you have with python - which > components (written in python) do you think cause bottlenecks here? dnf firewalld This is probably not as big an issue as I though. I > also don't see excessive RAM usage with python - at least for my > use-cases, it usually stays at a few MBs, or ~20 MB tops - unless I'm > reading 100MB+ JSON files into memory ... firewalld is using 37MB right now on my desktop. If it was written in Java it would be using more. But if it was written in C/C++ it would be less than half that size. It's not terrible I guess, compared to other things. I just really prefer more efficiency at this level because when you start allowing this for more and more programs that extra memory usage adds up. > Again, if done right, python has no problems with performance (also, > people should use the right tool for the job ...). Which > performance-critical, python-written components do you see in fedora? dnf and firewalld. But already discussed above. > IIRC, it was recently debunked that the JS part of gnome-shell is to > blame for poor performance. A lot of improvements have been made > during 3.32 and 3.34 release cycles, and it shows. While I agree that > using JS as a scripting language for the desktop shell was probably a > bad choice, unless you use some broken gnome-shell extensions, JS > should not cause performance issues in gnome-shell (or at least, not > anymore). (I also don't know why the developers didn't opt for a > python scripting interface, which is pretty standard for a lot of > other GNOME components, and probably a python interpreter has a lower > footprint than a JS engine, but well ...) OK. I can accept that. If I had to choose between python and JavaScript I would also choose python. We have fake news...well JavaScript is a fake programming language. > Yeah, memory efficiency is a problem. People used to care about it > when everything needed to fit into 512 MB of RAM :) > But what do you want to do? Rewrite all non-C GNOME components in > Rust? It's not going to happen - not because it wouldn't be great, but > because nobody is getting paid to rewrite things that aren't broken :) I respect your opinion here. But, I feel that as the hardware guys provide more RAM, we shouldn't be wasting it. Because we waste a little RAM here and then there and eventually every program is wasteful and all that waste adds up. You end up with a poorly performing system even though it has plenty of RAM. We need to bring back a culture of efficiency rather than wastefulness. I believe we could be getting a lot more performance out of the machines that we already have. Our basic library, glibc is wasteful compared to musl libc and that contributes to performance and memory usage across the system. > Interesting - I converted friends and family over to use fedora, and > they're all really happy with it (happier than with both windows 10 or > ubuntu), even my not-so-technologically-savvy mother. Because it *just > works*. There are instances where this has worked out for me. My son and his girlfriend have been using a Fedora laptop for school for about a year. However, this one successful conversion now needs to run ProTools for her class in college. There is no way to make it work in Linux. > Have you tried the Steam flatpak? In my experience, it works great. > And now with Valve's Proton (basically wine + DXVK), you can run > almost any windows game as well ... Yes, see my other response about gaming. > Well, this sounds like a bug, and a wall of text on the devel mailing > list is probably not the right place to report it. I agree but I don't have time to deal with all the bug reports, explaining what happening and trying to prove to and unbeliever that yes there really is something wrong... And these are programs that are very old. They shouldn't be failing. I feel like there must be a kernel issue or a problem with the network layer. > fedora *does* a lot of QA work. There's automated testing of every > rawhide compose, every beta candidate, every release candidate. > There's manual testing of those candidate builds. See. > https://fedoraproject.org/wiki/QA OK, I don't know about this but I believe you. I'm just looking at it from a user's perspective that there are a lot of problems and makes me thing that not enough testing is being done. > Also, GNOME developers actually *do* user testing. And a lot of > thinking goes into the design process. For example, I recommend you > look at Allan Day's blog: > https://blogs.gnome.org/aday/ I will do that. > Again, it's not enough for issues to get discovered - somebody > actually has to show up and do the work of fixing things. > And with stagnating developer numbers and growing package > repositories, this is just not happening as much as it probably needs > to. Right I understand what you're saying. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
