Software & Apps

Thank you to all involved!

It was a nice app, but not at this price. Alternatives?

I feel like they don't want people to be actually be able to do anything.

Today I was just trying to copy and paste some files and I almost went insane that now there are are icons when you right click instead of the words copy and paste, how is that better?

This is continuing the series on the progress of Desktop Linux software supporting VT-less kernels. Previous ones can be found here:

As an update since the last post, there have been some improvements since the last one from early 2023:

• Plymouth's support for showing the boot logs is now , (and with the help of Ray Strode is better than it was when first shown in the 2023 post, as it supports console logs and some terminal sequence handling, not just showing /dev/kmsg lines). This means that Plymouth can when the user presses ESC, instead of deactivating, and showing the VT.

• All Desktop GPU drivers in the Linux Kernel now support , which allows wlroots based compositors, such as , to run on all GPUs supported by the Linux kernel.

• A crash in cage related to multiple screens was .

• The login managers , , and have all been patched to support starting greeters and sessions on seat0's without VTs. It was mostly a simple fix to handle seat0 differently. While seat0 is the only seat that can have VTs, the assumption that seat0 always has VTs was corrected.

• A larger step though was Jocelyn Falempe, a kernel developer, has gotten their initial patch series merged in time for Linux 6.10. While the driver support is minimal at this time, and simpledrm is the only Desktop related driver that will have in in 6.10, there is already pending for v6.11. The benefit to drm_panic will allow users who experience a kernel panic to still be notified of the crash, without the need for a VT to see the output.

  • drm_panic is actually an improvement . As it stands now, in most conditions, without drm_panic panics usually appears as a dead hang, instead of explicitly informing the user that the kernel has crashed. (Which could lead some users to suspect the display server froze instead for instance.)

  • Furthermore, there are even of adding the ability to encode more verbose panic info as an on-screen QR code, which will allow an easier way for users to report crashes, without copying a whole stack trace manually.

• logind's key handling has been extended to now respond to a new key combination (Ctrl+Alt+Shift+Esc) that will be in v257. When pressed, logind will now emit a dbus signal to request the current login manager to . This will allow for two things:

  • When a display server is locked up, or in a state where it is not handling keyboard input for some reason, logind will be able to respond. This could even be a benefit to even users that have VT-enabled kernels, as the display server usually takes over VT switching from the kernel, and when they hang, even users of VT-enabled kernels could experience the same issue.

  • Second, while Ctrl+Alt+F(x) key commands actually do work on display servers running on VT-less seats, even now. Because of the SwitchTo(x) dbus method that most major display servers call on their logind seats when Ctrl+Alt+F(x) is pressed, they don't need to change anything to support session switching on VT-less seat0s.
    However, in many cases, the user's display server can be the only session running on the seat, Because there are no empty VTs to switch between, and when there is only one session running, this method of switching won't work, because they can't switch from only one session. This will remediate that, by giving the user an option to force the login manager to attempt start a greeter session back up.

There are improvements pending hopefully for 2024 fairly soon:

• More drivers should hopefully gain support for drm_panic.

• and and gaining the ability to respond to logind's new dbus signal, with pending patches (that may still need changes).

• After these two items are complete, most major desktop environments, and common daemons in the traditional desktop Linux stack already should have support for VT-less kernels, and the decision might be to the point where it is up to the distributions themselves.

Removing the VT subsystem, (or at the very least, disabling it in the default kernel config) has been talked about for , which initially led to the development of kmscon.
Now, especially since the dreaded was discovered involving possible buffer overflows that could be triggered by scrolling up in a VT, to remediate the exploit was to simply disable Shit+PgUp scrolling up in VTs.

• As there is no maintainer familiar with the VT subsystem, it will likely remain in that state for quite some time. The VT subsystem was first added in in 1992, but now, even well seasoned kernel developers shy away from making major changes to it, as most of them are familiar with other major subsystems.

• Note that while there is some recent news about "atomic consoles" and "threaded consoles" being worked on for realtime kernels, the terminology is confusing, and the printk/atomic console patches do not actually target the VT subsystem directly, but the console subsystem below it. VT's are a type of console, but so are serial consoles (which are simpler). The changes being made impact how kernel log messages are handled.

• VTs are in kernel mode, and have their limitations. They don't support displaying more than a maximum of 512 characters at a time in certain configurations, and in most cases the limit is 256 characters.

• Some arguments that many folks seem to make against removing VTs, are that they are fallback in case the user space fails. However, while it removes the need for a user mode terminal emulator for a minimal userspace, the getty, the shell, the /bin/login binary, and whatever utilities being used are all in usermode. VTs are not say, a kgdb prompt that goes completely around userspace, if ld.so is broken for instance, there will still be problems. .

• The kernel mode VT102 emulator is conceptually UI in the kernel, if minimalism is the goal, it would be better that this part is done in userspace instead.

• Before kernel mode setting (and simpledrm), there a much bigger need to have a fallback if the X server could not start, but now paring cage and as a fallback should cover for an emergency case better. An X server is no longer the only thing that can handle a UI with the advent of Wayland based display servers.

• Without VTs, it's MUCH easier to do a seamless boot

What is probably left is support for integration for fallback usermode terminal emulators, either using kmscon, or pairing a simple display server like cage, with a terminal emulator that has minimal dependencies like foot.
There are wrapper scripts but especially for the intird handling, they are Debian specific. There is:

• The ability to start the cage/foot combo when systemd goes into emergency.target and rescue.target with fakekmscon's recinit-emergency.service and recinit-rescue.service

• . Adding cage and foot to the initramfs is possible with fakekmscon's recinit initramfs hook.
  When Cage is compiled against a very minimal wlroots, (-Dxcb-errors=disabled -Dxwayland=disabled -Drenderers= -Dallocators= -Dbackends=drm,libinput), this only adds about 2.56MB to the rootfs of the initrd, inflating the compressed image file size by about 1.27MB.

  • This was calculated with Plymouth already in the initrd. Given the size of initrds due to drivers and firmwares, 1.27MB is fairly small.

• It is possible to have a mostly headless system, with only a text mode login prompt with

  • Using socat to run the getty process, and permissions, this also makes it so that cage and foot do not start as root, but as a daemon user, further reducing the attack surface.

  • This is more for systems that are intended to be 99% headless, where it might be a server that sees very few local logins, except for the initial network config, or running a utility like , or a local login for diagnosis.

  • User's can't start a new Display Server with this, unless they are administrators though, as the display server is not part of their session, but there is a solution...

• A fullscreen terminal session with fakekmscon's fullscreenterminal.desktop. It starts a session that is just cage/foot when the user logs in.

  • This session also uses a socat proxy, not for security in this instance though, as it all runs as the same user. Instead, this is so that users can still be able to run and diagnose their own display servers with uvtty-launch, uvtty-launch kicks out cage, allowing the user's shell prompt to still be running under socat. . This will allow display server developers to still have a usable workflow. Once the display server stops, cage/foot starts back up.

• These scripts are mostly demo though, and have not been integrated upstream though. They do, in best effort, try to maintain and reproduce the flexibility that VTs provide that advanced Linux users have come to enjoy.

• For users that don't like display managers at all, they will likely need to use (greetd)[, possibly paired with , to then start their session...

From here, once the login managers gain the support for systemd's SecureAttentionKey, and drm_panic sees more improvements, there are not really many upstream roadblocks remaining.

Am I the only one getting tired of the continues question “how do I make money out of knowing blender?”?

Like, I’ve known blender for awhile and have so much experience. I’m here to help just for the sake of it. If you don’t have a plan while using blender for money to begin with, don’t ask here? We are here to help and have fun together, not making a living out of it. I have specific places I can use blender to make a bit for myself, but it’s a niche community. Figure it out yourself, or atleast don’t ask people here “how do I compete with what you’re making”

That being said, I love you all, I understand the question, I’m just tired of seeing those posts while I’m here trying to help out just cause I have the knowledge