SUSE Dropping Mainline Work On Their In-Kernel Bootsplash System

[oiaohm]

This is unfortunate. I was looking forward to it.

But whatever. I just wish we could check a single option somewhere and get a fully silent boot.

That my problem I have that when using uboot on arm just set splash screen and all the early kernel stuff is blocked and have a user splashscreen start latter and it done.

[oiaohm]

Yeah, and look at where that lead MS to. If you want to install something for windows, you have to get online, search the web for a download, and then trust a third party proprietary installer. Yes, it could have been different, but this way is most definitely better.At least now I've got a repository of thousands of sources, all together, and available without searching or downloading from third party servers, or trusting proprietary installers.

Yet that repository per distribution results in dependency hell for anyone needing exact versions of particular applications. Where windows users can in fact install exact versions.

Its not like the Linux Distribution Packaging model works 100 percent correctly. You do need users to be able to install what applications the need. And that need can have a exact version requirement.

The fragmentation on Windows was also party caused by application makers going hey we will just buy /use the cheapest installer we can because we don't have to care about this bit.

Linux needs flatpak or equal. The existence windows mess and Linux distribution mess around applications fairly much trace to application developers not caring or being involved in development of how applications should install not to conflict with other applications.

If wine truly isn't an emulator, then its a wrapper... But literally the -only- thing it truly wraps is gallium nine. Pretty much everything else it implements as 1 to 1 translations and that never did work, it still doesn't work. It never will work.

So totally ignore the opengl stuff. gallium-nine is not part of the wine project.

There is quite a bit that is wrapper inside wine that when you run test suite over it faster than windows implementations. Its not like the ELF file-format does not come with particular advantages over the PE/COFF windows uses.

[duby229]

Yet that repository per distribution results in dependency hell for anyone needing exact versions of particular applications. Where windows users can in fact install exact versions.

Its not like the Linux Distribution Packaging model works 100 percent correctly. You do need users to be able to install what applications the need. And that need can have a exact version requirement.

The fragmentation on Windows was also party caused by application makers going hey we will just buy /use the cheapest installer we can because we don't have to care about this bit.

Linux needs flatpak or equal. The existence windows mess and Linux distribution mess around applications fairly much trace to application developers not caring or being involved in development of how applications should install not to conflict with other applications.


So totally ignore the opengl stuff. gallium-nine is not part of the wine project.

There is quite a bit that is wrapper inside wine that when you run test suite over it faster than windows implementations. Its not like the ELF file-format does not come with particular advantages over the PE/COFF windows uses.

You can call it fragmentation if you want, but in this case it's a good thing. We have a choice between different linux vendors because of it and giant repositories that can be trusted and relied upon for each of them. But there's only one MS and they don't have any trustable repositories. Ijn fact the real truth is there is almost no software download for windows that can be trusted. Basically almost all of them are untrustworthy. Linux can be trusted -because- of package management and windows can't be trusted because of lack of package management.

Faster don't mean anything if it isn't compatible. And that's something you will never achieve with 1 to 1 translations. You yourself admitted wine has something less than 50% compatibility, and this is the exact reason why.

[oiaohm]

You can call it fragmentation if you want, but in this case it's a good thing. We have a choice between different linux vendors because of it and giant repositories that can be trusted and relied upon for each of them. But there's only one MS and they don't have any trustable repositories. Ijn fact the real truth is there is almost no software download for windows that can be trusted. Basically almost all of them are untrustworthy. Linux can be trusted -because- of package management and windows can't be trusted because of lack of package management.

Faster don't mean anything if it isn't compatible.
Really "Secure don't mean anything if isn't compatible."

If a person need X version of a program to-do their job and they cannot install X version because of Linux Distribution dependency hell Linux is no use to them.

Sorry pushing the security point of view miss the item Windows gets right allowing users to install the versions of programs they need.

Of course we should be wanting to take what Microsoft offers add on security and make it work for Linux. Linux vendors giant repositories are not selling points to desktop users who have to cope with files coming for different people and needing to match application version.

Faster don't mean anything if it isn't compatible. And that's something you will never achieve with 1 to 1 translations. You yourself admitted wine has something less than 50% compatibility, and this is the exact reason why.

No the reason why I said less than 50% is based on how many functions are in fact mapped or implemented in wine. Wine is less than 40% implemented/stubs vs the number of functions that appear in windows. There are quite a few functions that are implemented in Windows that there appears to be not a single application anywhere ever uses so wine project has optimised what has been implemented on documented usage reports. Where the 1 to 1 mapping like inside opengl/vulkan support are there is 100 percent compatibility for the applications or at least inside the variation you do expect to see on Windows..

Really the biggest problem for wine is lack of developers to spend the time to implement and map the functions. Followed by copyprotect/anti-cheat things that checksum memory and other horrible things meaning you cannot do dll replacements and you legally cannot ship core dlls of windows.

If you want to see resource trouble just look at reactos attempt to-do a 1 to 1 implementation of windows. Its not like following the emulator path would make life any simpler and would be even more broken by the lack of developers problem.

[duby229]

Faster don't mean anything if it isn't compatible.
Really "Secure don't mean anything if isn't compatible."

If a person need X version of a program to-do their job and they cannot install X version because of Linux Distribution dependency hell Linux is no use to them.

Sorry pushing the security point of view miss the item Windows gets right allowing users to install the versions of programs they need.

Of course we should be wanting to take what Microsoft offers add on security and make it work for Linux. Linux vendors giant repositories are not selling points to desktop users who have to cope with files coming for different people and needing to match application version.



No the reason why I said less than 50% is based on how many functions are in fact mapped or implemented in wine. Wine is less than 40% implemented/stubs vs the number of functions that appear in windows. There are quite a few functions that are implemented in Windows that there appears to be not a single application anywhere ever uses so wine project has optimised what has been implemented on documented usage reports. Where the 1 to 1 mapping like inside opengl/vulkan support are there is 100 percent compatibility for the applications or at least inside the variation you do expect to see on Windows..

Really the biggest problem for wine is lack of developers to spend the time to implement and map the functions. Followed by copyprotect/anti-cheat things that checksum memory and other horrible things meaning you cannot do dll replacements and you legally cannot ship core dlls of windows.

If you want to see resource trouble just look at reactos attempt to-do a 1 to 1 implementation of windows. Its not like following the emulator path would make life any simpler and would be even more broken by the lack of developers problem.

I'm not implying it would be easy, that's for sure. What I'm saying is that as long as you guys keep on this 1 to 1 translation path, it'll never ever achieve good compatibility. Behavior must be duplicated. Linux libraries do not behave like windows libraries so you'll never duplicate the behavior of windows libraries if you are trying to do direct 1 to 1 translations. You will always get the behavior of the linux library, which is almost never the behavior a windows application expects.

Direct translations will never work no matter how much human resources you throw at it.

[BwackNinja]

This "Year of the Linux Desktop" moaning needs to stop. Linux isn't compatible with any of that from a philosophical standpoint.

Users want power not control. They want to know as little as possible and be able to do great things. What open source software enables is the opposite. Programs are no longer opaque masses of uncertain logic; they can be examined and changed - for better, worse, or mere preference. To take advantage of any of this requires a certain level of technical knowledge that's laughable to expect the common user to have or even deem worth pursuing.

The only Linux systems that have gained traction with users (i.e., those who have to maintain their own system, so not servers or embedded devices) beyond the purposely technically inclined are Android and to a lesser extent ChromeOS (and other less known examples of course). What all of these have in common is that they entirely discarded the Linux application ecosystem for their own and don't particularly relate to normal Linux at all. They're powerful, yet limiting. Their power makes them attractive and their limitations make them comfortable.

For a Linux distribution to achieve that, they'd similarly have to dissociate with the Linux application ecosystem. This is important because similarities and compatibility with other distributions give rise to the natural Linux arguments of "Distribution X does what Distribution Y does, except also does Z". A Linux distribution cannot become mainstream while being seen as an option among many similar ones. It has to be sufficiently unsavory for the kind of technical users who want control, so that they aren't normalized and driving the decisions about user experience and developer focus. Android is a much better system to develop for than it is to develop on.

The only other option is for Linux to have a killer feature that cannot be similarly replicated on other systems that's exciting enough that people will ignore its faults to be able to use it. Honestly (and perhaps disappointingly), the closest we've gotten to that was Beryl/Compiz. It was something you could show someone and they would be astounded that you could call that normal. They would want it for themselves, despite the caveats.

The real "Year of the Linux Desktop" that everyone wants, a time when people understand and appreciate the power of an open system and that support gives it the corporate attention that's always been a sore point.

[Danny3]

Average consumers don't think like that. To these people the first impression from booting up the OS is important because if they see strange looking text on their screen they might think their computer is broken or has a virus infection.

Average consumers are right thinking that way.
You shouldn't see any text while booting.
What's the point of seeing lots of success messages?
Maybe you look at first time you boot the system out of curiosity, but that's it, one time only.
Besides, developers need to understand that not everybody, and I want to actually say that the majority of people on the planet are not even speaking english, so they can't understand the english garblage.
This has something to do with sefishness and ignorance.
Anyway what's so fucking hard to do a conditional statement like?:

if($error){
Show debug messages
}else{
Show nice graphical animation
// This could be easily understood in any language
}

[oiaohm]

I'm not implying it would be easy, that's for sure. What I'm saying is that as long as you guys keep on this 1 to 1 translation path, it'll never ever achieve good compatibility. Behavior must be duplicated. Linux libraries do not behave like windows libraries so you'll never duplicate the behavior of windows libraries if you are trying to do direct 1 to 1 translations. You will always get the behavior of the linux library, which is almost never the behavior a windows application expects.

Direct translations will never work no matter how much human resources you throw at it.

The problem here is what you are saying is not matched up with testing. You are also missing something COFF/PE. ELF was designed to replace COFF. Wine uses an ELF/PE. So there is no need to exactly duplicate the behaviour of windows libraries.

The difference in behaviour from Linux Library with wine bugs history does not support that as problem. Direct X application normally fail because something not implemented at all. Opengl application under wine have issues mostly because the opengl version provided by the driver for that particular hardware is not up-to date.

No amount of claiming that direct translations don't work will disprove the tested evidence that where direct translations are implemented that is the areas that give the wine project the least problems and the evidence shows that more often than not is a perfect behaviour match.

There is a optimisation in gcc coming allowing more Microsoft calling conventions to be used inside ELF without requiring a lot of wrapping. There has been a few compiler limitations that have been getting in way. This is not a limitation of a Linux native library or the loader that loads the Linux native binary but a limitation of the compiler generating excess code when linking from windows calling conventions to Linux calling conventions due to lack of intelligence in optimisation..

You are also forgot even emulator has to translate back to host at some point.

[oiaohm]

Average consumers are right thinking that way.
You shouldn't see any text while booting.
What's the point of seeing lots of success messages?
Maybe you look at first time you boot the system out of curiosity, but that's it, one time only.
Besides, developers need to understand that not everybody, and I want to actually say that the majority of people on the planet are not even speaking english, so they can't understand the english garblage.
This has something to do with sefishness and ignorance.
Anyway what's so fucking hard to do a conditional statement like?:

if($error){
Show debug messages
}else{
Show nice graphical animation
// This could be easily understood in any language
}

Displaying text is better than displaying absolutely nothing like Windows does in different parts of it boot.

You code example does not work. Working pattern I use.

1) bootloader show static image/picture on screen.
2) kernel boots leaving static/picture on screen image in place unless there is a error as it been informed by bootloader that the image is present.
3) early on in user space start up start a program to start graphical animation that replaces the static image.

This process with supporting boot loaders and drivers has been possible since 2009 with the Linux kernel. This process the end user does not see any text if nothing is wrong.

The big thing you missed is you don't know in advance if you are going to hit an error or not. Graphical animation if you look at windows Microsoft has changed how they have done that 12 times so far. Really do we want a distribution wanting their splash screen animation done differently patching the kernel each time where errors equal system not booting at all.

Danny3 the problem here is there is a different highly popular way to solving the issue SUSE has without patching the kernel. When was the last time you saw kernel boot text on a Android phone. Remember the Android phone is not require an extra patch to the Linux kernel but using the stuff that has been there since 2009.

Just because 1 way of addressing end users problem is being reject does not mean something else that address same end users problem in a different way has not been accepted.

So the question is to SUSE why are they not using the 2009 method of having boot loader set image on screen and then have the Linux kernel not stomp it and use a animated userspace splash screen what is the stock standard embedded way of addressing the problem.

[jpg44]

Just one little tiny nitpick, otherwise I mostly agree. Package management is -the- thing that differentiates most distributions. Call it fragementation if you want, but in this particular case it's not a bad thing at all. We wouldn't have Gentoo or Arch or Debian if it hadn't worked out this way, so it's proven to be a really good thing. In fact -the- main thing all distributions do is..... distribute packages.....

EDIT: Also I agree with you about wine, but here's the thing, wine -needs- to emulate the behavior of native windows libraries. Linux libraries don't behave the same way and direct 1 to 1 translations cannot ever work. They won't ever work. As long as they refuse to admit that wine actually -is- an emulator it'll never have good compatibility. If it's not an emulator then the only real solution is to implement those libraries wine needs natively, and then they can trust its behavior. Not until. I'm talking about everything, GTK doesn't behave like GDI, opengl doesn't behave like d3d, alsa and PA doesn't behave like core audio.... etc, etc. Wine devs really need to come to terms with the fact that wine needs to emulate behavior exhibited by the native windows libraries. It's either that or those libraries need to be implemented natively on linux. It's either an emulator or it's a wrapper, they need to make up their minds.

I agree the different package management has allowed for indepandent innovation and more choices. As for compatability, maybe the solution is to allow a user to install multiple distributions package systems in seperate filesystem overlays or roots. So if your using ubuntu, you could install Red hat packages in a seperate directory subroot like /pkg/redhat/, holding /pkg/redhat/usr etc, and just install all the dependencies seperately inside that root. Redhat packages would see /pkg/redhat as being / instead. This would require duplication of all dependancies, trying to make ubuntu and redhat packages share dependencies has proven too complex, but on todays larger disks its not a big price to pay if someone wants to use applications from different distributions.

If Wine insists on 1:1 translations than obviously they are doing it wrong. The situation with Wine is really awful making it useless for most users who just want things to work. You cant sell Linux as a migration path from Windows on being able to run 11% of windows applications. The biggest problem with Linux migration is various kinds of in house apps and niche applications that were written for Windows, not big mainstream apps like office applications. Yes you can find Linux alternatives for many mainstream apps. Thats not possible with a small in house program that was written for use in a specific company. Also, many large Linux programs such as the graphics editing packages lack many of the capabilities of Windows apps.