On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: Hi again, I have a bit more time today, so I can respond to your more of your arguments directly. > I'm trying to find out what's going on with Java in Fedora. Fedora 31 was released with a broken Eclipse. I subscribe to the java-devel mailing list but there is no traffic there. If I go to "Join a Group" and click on "J" there is simply nothing there... > > https://admin.fedoraproject.org/accounts/group/list/J*?_csrf_token=d8baf5dd81fbb8289de644963217177eddc13278 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.). > Please take an example from the recent Boeing failures where management pushed the engineers to cut corners to meet release dates instead of taking the time to test and fix problems. Anyone who has worked in an office can see that is what happened. I don't know if it's management that is the problem with Fedora since open source works a bit differently than your typical corporation. But there is a problem and it's resulting in a low quality product. You need automated tests. You need a suit of manual tests. For every package. And you need to take the time to fix problems when they're discovered. Software Engineering isn't just about writing code. It's about creating a product that works for your end user. Your end-user has to be your priority and that means quality has to be a priority. Well, there are *some* automated tests. For example, koschei does regular test rebuilds of a lot of fedora packages to check whether they still successfully build. There's even a Java package group set up there: https://koschei.fedoraproject.org/groups/java However, this only helps if 1) it's enabled for a package, and 2) if anybody is actually looking at build failures when they start happening. There's also automated tests for every update that gets submitted to fedora. For an example, look at the "Automated tests" tab for this recent maven update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0be8546e6d For updates in the "critical path" there's even more automated tests (does fedora boot with this update? does upgrading work? does networking continue to work? etc), like for this kernel update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3278105741 > The poor quality of Fedora in general and the poor support for Java is basically forcing me to use Ubuntu just so that I can get a system that actually works. I've been using Fedora for a long time and I hate to switch away from it. But, I do actually have to get work done. Between gnome shell crashes, long periods of the whole system being unresponsive, core Java programs that I can't even install, mysterious network failures in nfs, avahi, sshd and submitting bug reports that almost always end up failing to submit after spending 15 minutes collecting data...I can't get any work done. I agree, this Java situation is not good. We've been trying to keep it from exploding, but there's only so much 2-3 people can do for over 200 packages. The problem with failing bug report submissions is (I think) caused by 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. > I think the main problem is that you are not spending enough time on testing and fixing problems before you release. Maybe 6 months is too short of a cycle for the number of people you have. You can't cut a buggy release and depend on your users to find the bugs for you. If you do, you are going to lose all your users. As much as I love Linux and Fedora, I have to admit that the quality of Fedora is about equal to that of Windows 95. There were a few releases where quality was pretty good but 31 is in the gutter. The reason I use Linux is to get a better quality system than Windows. But, that just isn't happening with Fedora. 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 - it would just take longer for people to notice, I guess. > I really apologize for being an a-hole here but I'm saying these things because I REALLY care about Fedora and they really need to be said. Things need to change...quality needs to be the highest priority. And I'm willing to help but I have tried to join projects several times with no responses. The Java project doesn't even seem to exist. You're right. The Java SIG has basically dissolved. Of the 26 members listed on their wiki page, I think only 2-3 still actively maintain RPM packages for fedora. https://fedoraproject.org/wiki/SIGs/Java > Being that Java is the most popular programming language in the industry by multiple metrics, most corporations use it, a large part of Red Hat's business is Java, Hadoop is written in Java, I'd expect to see much better support for it in Fedora. But, it's like a second-class citizen. True. Nobody cares about Java packages in fedora, not even Red Hat employees. If you look at the members of the Java SIG, a lot of them were (or still are) Red Hat employees. For example, even JBoss / WildFly (a pretty big Java project by Red Hat) was unmaintained and broken, and most of it has now been removed from future fedora releases. I wonder what they are going to do with RHEL 9 - maybe somebody notices their stuff isn't available on fedora anymore. > Python, the slowest language ever created (except for Ruby), is about the only thing people care about. Python is part of the problem with Fedora as it is a big part of what makes Fedora slow. Anyone who has compared the performance of dnf versus apt can see that dnf sucks...bad. Apt is extremely fast and dnf is extremely slow. There is no room for argument there. It's just the truth. I'm not saying that to be mean. I'm trying to point out a serious problem that needs to be addressed. 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 :) > It does not matter now nice a language is to program in. What matters is the user experience. Programs that are integral to the operating system should not be written in Python or Java. They need to be written in an memory and CPU efficient language like C/C++ or Ada. If you could get better performance out of Python, that could be an option too, like maybe running Python programs in pypy instead of regular python. The important thing is getting the right user experience. By that I mean that the program has to run fast and not take up large amounts of memory on the user's machine so that other programs don't have enough room to run. I don't know which performance problems you have with python - which components (written in python) do you think cause bottlenecks here? 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 ... > These issues apply to Gnome, Python and Java. As a Java programmer I understand that Java uses massive amounts of memory. It's not an appropriate implementation language for operating system level components because of that. If you have 15 Java programs running on an end-user machine, the machine is going to run out of memory. It is fine to run 1 or 2 application-level programs on an end-user machine. And Java is great on the server where you can have a large amount of memory. > Python has the same problem but in addition it is also slow. If you think Java is slow you need to re-educate yourself, because it is not. You can test this yourself by writing some equivalent Java and Python programs and timing them. I'm not saying anything here you can't verify on your own. 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? > Gnome uses way too much of memory for an end-user's machine. It has an embedded JavaScript interpreter with JavaScript plugins that are slow. Most people don't have 32 GB of RAM on their machine so the memory consumption and the slowness has a real effect on your end users. Remember it's your end-user that matters, not how it runs on your 32 GB i9 development machine. 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 ...) > I have an 8GB machine which I think is pretty standard these days. Again, I'm talking about end-user machines, not developer machines. You have to have a mind set of what your end user is going to experience. But if I run Gnome, a Java IDE and a web browser, I'm pretty much out of memory. I don't want my operating system consuming all my memory. I don't use a computer just to run an operating system. I use it to run applications. I want my operating system to use a minimum amount of memory so that I have memory for my applications to run. Because the point of using a computer is to run applications, not just an operating system. 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 :) > My apologies if I offended anyone. I am just trying to communicate to you how your end-users, like me, are experiencing the system. My experience is no different from anyone else that I've talked to who has tried Fedora. In fact, everyone I know has already given up on it. I don't know anyone besides myself that continues to believe that Fedora is worth using. Everyone else that I know who uses Linux, uses Ubuntu. I can't even get my kids to use Linux. One of my boys told me that the default Gnome desktop that I provided to him to use was the worst computer experience he's ever had. He'll never bother to try Linux again because he thinks it's stupid. Because of Gnome. 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*. > In another case I tried to set up a Fedora system to run games, as that is what kids want to do. That was an utter failure because Fedora can't run any game that kids want to run today. The ability to run games cannot be underestimated because that is how you get the younger generation interested. That isn't really the fault of Fedora, I'm just mentioning that as an example of how, in general, the experience of the end-user is not being taken into account. And Fedora is failing to capture and retain users. 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 ... > I've also set up a Fedora Server to serve my Dropbox files over nfs to other machines I have that can't access Dropbox directly. It also runs dnsmasq. But, half the time this machine is unresponsive on the network. It doesn't respond to avahi requests until I restart the avahi daemon. nfs becomes unresponsive and ssh sessions become unresponsive for long periods of time. This machine worked fine under Windows. I have a 20 year old UltraSparc 5 running Solaris 8 that works better. It always responds on the network. Nfs, ssh, etc work flawlessly on it. 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. > This all leads me to believe that Fedora is not being tested properly. Gnome should also be required to go through user-acceptance testing. Software should be required to meet the needs of end users, not the other way around. When Microsoft created the start menu and the task bar, they did it in response to proper end user testing where they observed how end users used and reacted to the system and then created solutions to the problems they experienced. THAT is how user interfaces should be developed. (Probably the only thing that Microsoft ever did right.) Certainly not by allowing one person to guess about how it should work and then trying to force everyone else to accept that theoretical idea until it seems like the right way to do it. 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 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/ 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. Fabio > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
