A Run Down Of VT Switching On Linux

[Ericg]

Ericg, you claim to be objective and often point out when you believe others do FUD. But it's getting hard to ignore that you're doing the same just from the other side of the fence.

Have you, or have you not actually read the VT code?

The code itself? No, I've never claimed that I have. I talk to devs, I read the kernel mailinglists, I read kernel code comments. Unless most people I actually find kernelspace interesting and find developer communications interesting. I don't trust news sites if I can help, no offense to Michael, but I typically find them one sided. Which is why I do whatever I can to get my information as 'start from the horses mouth' as I can.

EDIT: Its also important to note though Curaga, I AM as objective as I can be, and I don't just mean in the above mentioned ways. If systemd, or packagekit, or KDE, or Openshot, or Pulse start fucking up-- you better believe I will call them out on it, whether I like the project or not. I was a big proponent of Gnome up until the 3.0 release, I couldn't stand KDE. But KDE got their act together, and Gnome started screwing up-- so my opinion changed. I take the side of the best product and the best solution, I don't have the near-zealot levels of devotion (or hate) for projects that I see many people on here going on about daily.

The VT's have problems, the VT's have security holes, the VT's are a hacky mess, The VT's (in my opinion) don't belong in kernelspace given that EVERYTHING they depend on to WORK...is in userspace(/bin/login,/usr/bin/bash, etc). I know this because I've read the developers blogs and talked to a few of them, and I am taking it on a little bit of faith that as the MAINTAINERS and the people who have to WORK with this code, they know what they are talking about and they themselves aren't spreading FUD and lies.

Since I get the feeling that you aren't restricting my comments to just this topic, I'll continue.

sysV had problems, sysV was ugly and hacky-- that one I do know, because I had to write init scripts a few times on Arch. It wasn't fun, it wasn't enjoyable and the entire time I kept thinking to myself "Why isnt this better?" Lennart came along with systemd and guess what... init became better.

Alsa had problems, alsa was buggy as all hell, alsa couldn't do jack-detection for headphones. Guess what, I hated on them too. When Ubuntu adopted Pulseaudio and I was still using Ubuntu, you better believe that I spent many hours trying to rip Pulse out because I thought it was the source of my problems. I learned later that it wasn't Pulse's direct fault, it was buggy alsa drivers, granted that fact alone didnt magically FIX my problems but it reminded me of an important lesson: go beyond the surface when debugging. When Pulse and Alsa got better, guess what? I stopped hating on them then too.

Unlike a few people on these forums I actually am willing to give things second tries, even if the first try was horrid. Try, try again. I don't just limit myself and my perspective and knowledge to one attempt and call it "Good enough" and then start preaching my experiences from the mountaintop for all eternity. Nor do I call something "bad" just because its not traditional without TRYING it. I adapt, and I learn.

[jrch2k8]

yeah i had my reservations about systemd at first too but once you get used to it is really impresive and the dbus API is simply fantastic and very easy to use from QtDbus classes, beside controlling cgroups is really powerful for spawn separated processes from c++ and keep proper track of them, no more tracking stderr output and bash scripts or envirement variable hacks.

most ppl hate it for no reason but once you see the light and see how powerful is you realize how sad were those times with bash based init systems.

[erendorn]

I'm aware of the rolling hash network optimization for Wayland, and it can indeed boost remoting well over VNC. I however disagree that it's the best option; for mostly-text content, the text should be transferred as text. The efficiency of this is easily proved: compare the sizes of compressed text to the image of that text.

Toolkits render, display servers display.
Remote rendering can be done in the toolkit, remote displaying can be done in the display sever.

If you have some apps that have hard requirements on being able to remotely display text in a bandwidth efficient manner, use HTML 5.

[curaga]

What about yourself?

I have. It's only a few k lines. Which is why I'm able to discuss it in the first place.

I have only contempt for someone who preaches gospel based on hearsay instead of something they have personally verified.

The code itself? No, I've never claimed that I have.

Like this. Ericg, your whole position is based on hearsay, on something that "Authority A said".
You're taking very strong positions on something that you haven't personally verified. And you're preaching those positions to others.

Even Authorities are humans. They have biases, they have bad days. You cannot trust hearsay to such a strong degree. You can only trust what you can verify. "The horse's mouth" is unreliable in the first place.

This was already pointed out earlier that it's not the case. Compare the size of sending the whole font, instructions on where to place the text, how large it should be, what hinting it should use etc. plus the background image on which the text is supposed to be rendered, to a well-compressed single image of the background with the text baked onto it. And even if the text approach was somehow smaller, Wayland developers can't do anything about it, because they are making a protocol, not a toolkit. You have to talk about that with GTK and Qt developers instead.

The assumption was that fonts are already on the client (screen) end. The hinting and placing info is tiny in comparison.

It's too late now indeed, as toolkits have already written support for Wayland as it currently is. Had it had proper networking from the start, there's much greater chance that all toolkits would support it.

[curaga]

Toolkits render, display servers display.
Remote rendering can be done in the toolkit, remote displaying can be done in the display sever.

If you have some apps that have hard requirements on being able to remotely display text in a bandwidth efficient manner, use HTML 5.

You're correct that I can do whatever I want for my apps. But the issue is not just my apps. Efficient remotability of _all_ apps is a huge platform advantage.

Ignore X and Wayland. Take that sentence on its own for a hypothetical OS/3 or whatever. Do you agree that it's a big advantage for that platform over ones that do not have it?

[GreatEmerald]

I have. It's only a few k lines. Which is why I'm able to discuss it in the first place.

Good, it means it should be easy to remove it from the kernel.

Ignore X and Wayland. Take that sentence on its own for a hypothetical OS/3 or whatever. Do you agree that it's a big advantage for that platform over ones that do not have it?

A slight advantage (sending images is usually good enough as it is), and OS/3 would need to mandate that all apps are written in a single toolkit which implements efficient remotability, with all the pitfalls that this entails.

[curaga]

Good, it means it should be easy to remove it from the kernel.

Current status: You can get a shell with kernel + shell.
Your proposed status: You need kernel + shell + several daemons and helper programs to get a shell.

How is that an improvement?

A slight advantage (sending images is usually good enough as it is), and OS/3 would need to mandate that all apps are written in a single toolkit which implements efficient remotability, with all the pitfalls that this entails.

Such a mandate wouldn't be needed. It would be enough if the major 3-4 toolkits supported it internally for the majority of use cases. If someone wanted to go around it and ship images only, they could, but the easier way would be to do it properly.

[erendorn]

You're correct that I can do whatever I want for my apps. But the issue is not just my apps. Efficient remotability of _all_ apps is a huge platform advantage.

Ignore X and Wayland. Take that sentence on its own for a hypothetical OS/3 or whatever. Do you agree that it's a big advantage for that platform over ones that do not have it?

Efficient text remote rendering at the cost of efficient local rendering? I personally wouldn't.

Mainly because not _all_ apps are heavily reliant on text. And for the apps for which remote rendering would be a noticeable advantage, most of the time you have better solutions (like accessing the text data directly), which are better dealt with on a app by app basis (or even use case by use case basis).

A PNG compression of a screenshot of a text editor already achieves a compression factor of 100 (and it's lossless, and not even optimized for text).
Adding to that sending only surface damages, and translations info of sub surfaces (for scrolling) already gives you a low bandwidth solution, but also super easy to do and not relying on many thing on either client or server side.

Anyway, it's a pointless discussion, history showed that if you provide a central remote rendering toolkit/API, everybody will end up not using it and doing their own thing.

[erendorn]

Hum, practical test:
I considered my previous post as a sample.
PNG of background + 7z compression of html text (css data not included): 11.5 + 2.01 = 13.51 kB
PNG of post, including text: 30.1 kB

Compression ratio: 2.2 (real one is probably a tad lower, as you need additional style data)

Same order of magnitude looks not worthwhile to me, but different uses cases might have a different opinion.

[GreatEmerald]

Current status: You can get a shell with kernel + shell.
Your proposed status: You need kernel + shell + several daemons and helper programs to get a shell.

How is that an improvement?

It is an improvement. It's called modularity. By your logic, integrating the X server into the kernel is a good idea because then you don't need several daemons and helper programs to get a GUI!