SUSE Dropping Mainline Work On Their In-Kernel Bootsplash System

[duby229]

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.

Actually there are a couple good solutions. Redhat has implemented Flatpack and Ubuntu has Snappy. I think the future looks a lot brighter for Flatpack though, so for now that what I've been using. It's a good possibility to have universal linux apps. The packages are bit fatter due to duplicated dependancies, but that duplication is what makes it universal, so it's a fair compromise.

[starshipeleven]

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.

How about you stop this bullshit?

Android boot animation is done by the OS itself when booting. It's all userspace, just like Plymouth. The Plymouth issue (any userspace bootsplash issue) is that you can't easily adjust the bootsplash to work on different hardware configurations as the initramfs has no way of knowing what GPU you have onboard.

On Android this is a non-issue. In each device you fully know what is the GPU and you can hardcode that in the firmware build configuration, and if there are any errors being printed by the kernel that fuck up the bootsplash you comment them out in your local source and rebuild, like debianxfce does.

So the question is to SUSE why are they not using the 2009 method

Because they don't build hardware-specific firmware like in embedded, and supporting multiple hardware configurations from userspace is not easy.

[oiaohm]

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.

Reason for flatpak is that idea does not address the base problem. Lets say someone is wanting to make application outside a distribution tree. Like internal business application. Or the fact major distributions are only design to have 1 version of program installed.

If Wine insists on 1:1 translations than obviously they are doing it wrong.

Problem here this is a guess not backed by any facts. The 1:1 translations of opengl and other parts in wine don't show up as causing trouble by bug reports.

What is causing failures is more often lack of implemented so function is not implemented or incorrect implementation basically where wine attempted to emulate something. So obviously wrong if that was the case it should be in the bugs right.

IThe 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.

Sorry to rain on you but here are some nasty facts. If you don't have source code to those smaller in house applications in windows one day due to windows updates they don't work any more any how. So if in house applications are causing you problems migrating to Linux you are already in hell just you don't know it yet.

Lot of migrations to Linux are not 100 percent so 90% Linux 10% windows and don't use wine at all. So if wine is excuse why not migrating to Linux that is lack of understanding how to plan migration. Migration does not have to be pure Linux or Pure Windows.

Question how many staff are in fact using those graphic editing packages. You can find yourself at times where only 10 percent or less staff needing features that Linux native applications cannot do. Of course this is that you don't have the in house application nightmare that is a nightmare if you migrate or not.

Migrate makes the issue of in house application that you lack source and developers to maintain problem straight away but that problem will come in future. Migration is not without a price tag.

[oiaohm]

How about you stop this bullshit?
Android boot animation is done by the OS itself when booting. It's all userspace, just like Plymouth. The Plymouth issue (any userspace bootsplash issue) is that you can't easily adjust the bootsplash to work on different hardware configurations as the initramfs has no way of knowing what GPU you have onboard.

I did not say the boot animation is done by anything else than the OS.

The boot loader on android sets a static image to screen not animated one then tells kernel to leave that alone until the userspace boot splash starts.

About time you stop the bullshit and read. The splashscreen is done twice once static by bootloader and once in userspace that is the animated one.

In android due to pure userspace graphics drivers in early version there was no choice but to use boot loader to set the first image to graphics because the kernel did not know. But some of the modern android are using DRI/DRM stack just like your normal Linux desktop.

https://memcpy.io/android-enabling-mainline-graphics.html

Yes androids using this newer stack do know what the GPU you have on board at the initramfs stage as the GPU driver is in the Linux kernel not userspace and if were not being told by the boot loader to shut up would be spewing text all over the screen early on. So switch to kernel mode graphics in the androids was not that painful because the bootloader just keep on doing what it had been doing of setting image and the userspace splashscreen kept on doing what it was doing.

[Charlie68]

It's nice to know that there is no splash screen problem in Gnu / Linux, but then I ask you, why is not there a Gnu / Linux distribution that has a decent splash screen not interrupted by unnecessary writing? Everyone incapable?

[oiaohm]

It's nice to know that there is no splash screen problem in Gnu / Linux, but then I ask you, why is not there a Gnu / Linux distribution that has a decent splash screen not interrupted by unnecessary writing? Everyone incapable?

Fact a method to do it has been present in mainline kernel since 2009. Its more most of the time we don't give a stuff its on the lower end of importance.. Most people turn computer on go do something else then come sit down. Yes it pretty pretty but is not directly functionally important. So if you had to choose developer time between making distribution run or having splash screen? You are going to put it into functional stuff first. You can fairly much fixing like a sound driver issue or application issue is well head of fixing a splash-screen issue most of the time. Splash screens are in the camp of pretty pretty.

The fact its lower end of importance really makes me wonder why so many people were like this is end of world that this method is not going forwards and failing to check if there was already a method in kernel.

[Charlie68]

Fact a method to do it has been present in mainline kernel since 2009. Its more most of the time we don't give a stuff its on the lower end of importance.. Most people turn computer on go do something else then come sit down. Yes it pretty pretty but is not directly functionally important. So if you had to choose developer time between making distribution run or having splash screen? You are going to put it into functional stuff first. You can fairly much fixing like a sound driver issue or application issue is well head of fixing a splash-screen issue most of the time. Splash screens are in the camp of pretty pretty.

The fact its lower end of importance really makes me wonder why so many people were like this is end of world that this method is not going forwards and failing to check if there was already a method in kernel.

I use Gnu / Linux for over 10 years, just access the forums of various distributions to realize that people turn on the computer and is there, do not go for a ride. Everybody always asks the reason of all those written and how to have a working splash screen. If you then use the proprietary drivers Nvidia is a disaster. Is all this fundamental? No, but it will be nice that there is a way to get a decent splash screen. Can you have no problems? Explain to users how to do it, so far all the guides I've found have not helped. I apologize for my English but I hope the concept is understood.

[oiaohm]

I use Gnu / Linux for over 10 years, just access the forums of various distributions to realize that people turn on the computer and is there, do not go for a ride. Everybody always asks the reason of all those written and how to have a working splash screen. If you then use the proprietary drivers Nvidia is a disaster. Is all this fundamental? No, but it will be nice that there is a way to get a decent splash screen. Can you have no problems? Explain to users how to do it, so far all the guides I've found have not helped. I apologize for my English but I hope the concept is understood.

It might be on forums but don't see the requests that often in the distribution bug reporting feature requests.

https://wiki.debian.org/plymouth

Debian kind of does splashscreen for open source driver. Note you are setting screen res in grub2 in debians case. And grub2 does not have a nice image set like uboot to make the transition to software one nicer.

https://wiki.archlinux.org/index.php/silent_boot

Even without a splash screen you do have the process of silent boot where you tell the system simply to print less to the point it prints nothing. Silent boot is about the best you can do with current day closed source Nvidia.

To get Nvidia closed source to work we will need Nvidia to properly support using Kernel mode setting and Direct rendering manager.

There is 2 technical problems against nice functional splash screen.
1)Grub2 the normal desktop bootloader being a little lacking in features where you cannot declare a boot OS picture to put on screen before booting OS left on screen so that OS can leave on screen until user-space spash-screen starts up. I do have this on embedded devices with uboot and this is my biggest annoyance on a desktop.
2) Nvidia closed source nightmare that fairly much ruins have a splash screen on them and is causing trouble wanting wayland on Nvidia.

There are a few distribution configuration issues.
1) Not setting all the quite options
2) Not installing and setting up a userspace splash screen program kind of a problem that is breaks with Nvidia closed source but could be enabled with open source drivers.
3) Not configuring boot loader for splash image if that is possible.

Nvidia is just an ongoing pain. Even the SUSE in kernel boot-splash only worked safely if you were using open source drivers not Nvidia closed source ones. So having or not having SUSE in kernel boot-splash did not change things much at all..

Please note done right using open source drivers you only have one screen resolution set at the boot loader. This means less flicker on boot as well.\

So something okish can be made today if you are using open source drivers but it does not come out the box that way.

Nvidia closed source starting up with a pure black screen until X11 start does not feel ok to a lot of people but its the only thing that works due to the way the Nvidia closed source driver is done and that is fairly much complain to Nvidia and hope they listen.

[starshipeleven]

About time you stop the bullshit and read. The splashscreen is done twice once static by bootloader and once in userspace that is the animated one.

I'm calling your posts bullshit because you keep repeating useless information over and over and over.

linux bootsplash from bootloader is still interrupted by console errors, just like "quiet" kernel commandline. On Android they either don't happen (as the most common source of these errors is crappy UEFI firmware or verbose drivers, and Android has neither) or are worked around by commenting out stuff, or hacking code.

But some of the modern android are using DRI/DRM stack just like your normal Linux desktop. Yes androids using this newer stack do know what the GPU you have on board at the initramfs stage as the GPU driver is in the Linux kernel not userspace

Ahem no. They still can't know what is the GPU they have onboard at the initramfs stage, just like Plymouth. Also Initramfs is userspace, not kernel. They can have GPU drivers in there fine (they only need dumb display controller drivers, the 3D accelerator drivers are not needed).

And they do exactly like the only workaround possible for Plymouth, they load ONE GPU driver in the initramfs, and the bootsplash loads this driver and uses it.

Which as I said is NOT an issue for Android because you can't change the GPU onboard anyway. On a linux distro targeting x86_64 PCs you can get hundreds of different GPUs so you need something to tell what is the GPU, or a generic system like they were developing, so you don't care of the driver because all KMS drivers would expose the same interface for this gimmick.

[starshipeleven]

And grub2 does not have a nice image set like uboot to make the transition to software one nicer.

This is completely irrelevant as it usually uses "quiet" boot option so it just shows a black screen for 2 seconds at most before Plymouth takes over.

The issue is that errors are still posted on screen (also with bootsplash from uboot), and that Plymouth looks like crap if it does not have the driver for the GPU in the initramfs.

Decent distros just scan for GPUs and load the driver for the CURRENT GPU in the initramfs every time there is an initramfs rebuild (i.e. kernel update), but it's kind of a workaround.