When I came to openSUSE, It was in a mad attempt to get a distro that would install on my Laptop, I don’t recall just how many distro’s I tried to install just that I burnt an incredible number of CD’s and DVD’s. The OP comments about what was said about openSUSE would fit with what I found trying with the other distro’s. Funny thing is, I have many PC’s and not one of them has the identical distro not to mention version as any other.
When I came to openSUSE this was one of my biggest problems. Yet-Another-System-Tool was seen in fact as Yet-Another-Stupid-Tool that reported a bad value in the network set-up (which I might add IT made the bad value) asked you to acknowledge the message and then cycled around to report it again instead of fixing it or letting you out of the loop to fix it. Secondly, this tool couldn’t understand that a usb printer is NOT a network printer needing ipv6 protocol! Turn off Ipv6 and remove entries in fstab (made by Yast) for it and presto, network works, printers work, wifi works, and one is happy.
This is a bold statement. Some people complain for the same reason about KDE. How can measure anyone anyway what is bloated. The same goes to other OS’s too. But with more features build in, bigger code its getting bigger. Thats just the way it is. I think faster it would only go if one writes it in assembler.
What people fail to realize that unlike M$ a big distro does not mean bloat. Bloat is where every conceivable feature no matter how obscure is crammed into the OS forcing the need for big memory, fast hardware (cpu and drives) and where the settings of every program install is held in memory even when such applications haven’t been used for years think ‘windows registry’. Yes, Linux distro vary in OS size for the features they want in their branding. Too many equate the size of install with bloat and to them I simply say then change what you install as apps then. I remember when Linux classic comment was “Linux works best with older hardware … Newer hardware will be usable when programmers have the time to reverse engineer and write the code for them” this was back in days of RedHat 5.1. Back then my perfectly working mustek 600III parport scanner worked in Linux but then the kernel changed for 5.2 and they reported that due to conflict and coding issues to accomodate CIS scanners CCD scanner support has been dropped from the kernel. Point is that people talk about bloat and then complain that their favorite this or that won’t work.
“I think faster it would only go if one writes it in assembler.” I am with you all the way here! I know how I will get lots of flame here but the fact of computer science is that faster but more lazy program coding does not equal faster more efficient programs. C/C++ has been heralded as the best thing since mom’s apple pie. It allows for easier more understandable code that is more human readable. Fine, but our objective is to have the code more machine readable as long gone are the days of a front panel with 64 lights, 64 switches and a push button or dare I say card reader.
I have been following along in another thread where discussion is being waged about a universal all distribution package manager. It was said that the reason that one would not work is because each distribution is different with different C libraries, different resources etc. Well, it is time to wake up, the x86 or xx86 architecture use the same op codes regardless of whether it is running M$, Ubuntu, or openSUSE! Assembly language understands this even if C/C++ doesn’t. The simple solution is to write the C for the package management, convert to assembly (this step is for the benefit of those who never learned a real assembly language). Do the same for the required libraries. Then merge the code into 1 final product that does not rely on libraries and compile it with a standard gcc. You would now have a single package menagement program that will work indefinately on every distro out there.
Another approach is to use xBasic because it has the simplicity of BASIC but includes the power of C, assembly, and libraries. It compiles into a program that is library independant and outputs both binary package and assembly source. Different method same result.
I wonder how many of the incompatibility issues or bugs are really just bad fit of programs to the libraries they reference.
Can’t see me changing anyway but I do hope the new owners do their best to return it to it’s former near super stable state - not any easy task given KDE.