Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Preparing for KDE Plasma's Last X11-Supported Release

blog.davidedmundson.co.uk

Post reply on HN
Print view View original

351–360 of 392 posts

Re: Preparing for KDE Plasma's Last X11-Supported Release

#351

Post by l72 »

feverzsj wrote: post #66
krs_ wrote: post #63

Earlier quoted context omitted.

qimgv uses libmpv for video playback support for example. I'm guessing that's not what you mean, but I'm struggling to think of how one might "embed" one application inside of another on xorg.

x11 supports foreign window embedding. You can embed window from other application into your own window. That's why lots of mpv/vlc based players/editors don't work probably on wayland. The only way to achieve this on wayland is writing a custom compositor for the foreign window.

I worked at a company that had a powerful legacy software that was meant to be configured once and run full screen.

At some point it needed a custom interface and the ability to reconfigure itself on the fly.

Adding in a GUI was not a reasonable option.

We ended up writing a GUI (in gtk) then using Xembed to embed the other process and communicate via a Unix socket.

What would have been a major rewrite (and likely a port to a different language) ended up being a few a days project and worked beautifully.

It really showed me how powerful X11 really was.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#352

Post by l72 »

mixmastamyk wrote: post #112
mvdtnz wrote: post #82

I can't be the only long time Linux use who still has no real idea what X11 or Wayland are. Except that sometimes software won't work properly with one or the other and I need to paste some arcane command to fix it.

It's what puts graphics on the screen. If you are not interested in hacking or developing it, there's not much else to know except X11 is deprecated and Wayland is not finished, leading to this suboptimal situation.

I think it is amazing that Linux has reached such an audience that the knowledge of what windowing or desktop system being used is unknown.

But at the same time it makes me a little sad. Part of the draw of Linux was being able to understand what was under the hood and how to bend it to your will.

I’m hope the community doesn’t lose sight of that in trying to gain new users.

People often talk about the year of Linux or what success is, and in my opinion, Linux had achieved success by 1996.

Trying to pull a casual user from windows or Mac OS is a worthy goal, but that shouldn’t be the end all be all metric.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#353

Post by l72 »

ahartmetz wrote: post #236
chlorion wrote: post #185

Earlier quoted context omitted.

They are actually both much better than the things they replace, but a bunch of whiner babies can't stand the thought of anything changing and will claw and scream while being dragged into the future.

Systemd-resolvd is a bad DNS resolver and journalctl makes logging needlessly complicated and log files slow to read. Also, socket activation is basically xinetd and we got rid of it because it's a brittle hack, also slower than starting stuff as soon as possible if you actually need it.

I’ll agree with some parts of this as I have some big issues with parts of systemd. But writing service files with systemd is so much better and having a unified interface into logs is really really nice.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#354

Post by josephcsible »

l72 wrote: post #353
ahartmetz wrote: post #236

Earlier quoted context omitted.

Systemd-resolvd is a bad DNS resolver and journalctl makes logging needlessly complicated and log files slow to read. Also, socket activation is basically xinetd and we got rid of it because it's a brittle hack, also slower than starting stuff as soon as possible if you actually need it.

I’ll agree with some parts of this as I have some big issues with parts of systemd. But writing service files with systemd is so much better and having a unified interface into logs is really really nice.

Sure, there are a few things it's better at. I don't think it's entirely bad, just that the good things are way outweighed by the bad.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#355

Post by dwattttt »

LtWorf wrote: post #306
bluGill wrote: post #40

Earlier quoted context omitted.

Most people are not you. A small minority do things that really need X. However there is good reason to say that the things that really need X are things you shouldn't do anyway. Meanwhile there is a slightly larger minority that need things that cannot be done in X. For the vast majority of people they cannot tell the difference, either works just fine. If there are issues they are tiny things they don't notice unti…

> Meanwhile there is a slightly larger minority that need things that cannot be done in X. List of things that cannot be done in X:

That's not actually a good thing. General purpose programming languages as configuration file formats also give you "can do anything"; but when it comes time to try to improve or update the Python package ecosystem, you're forced to break backwards compatibility. Or give up on whole classes of improvements, because you can't constrain package behaviour at all.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#356

Post by bayindirh »

pseudalopex wrote: post #327
bayindirh wrote: post #272

Earlier quoted context omitted.

Well, seeing how systems are brute-forced and how much speed you can achieve today, these delays are more and more welcome on my end.

Authentication systems had lock out periods or increasing delays since decades. 1 attempt per 5 seconds and 12 attempts per minute would be equivalent for brute force. And 12 attempts per minute would be a very loose lock out policy.

However, it's a good starting point for any systems which might be user facing and reasonably secured by the network around the system.

There's such thing as bad defaults and starting too heavy-handed is starting with bad defaults.

In short, current default is a good compromise and a good default.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#357

Post by liamwire »

irthomasthomas wrote: post #287
KptMarchewa wrote: post #282

Earlier quoted context omitted.

[flagged]

Why do people only do this to the x11 guy? I bet if you interrogated the wayland side to the same degree you would find similar, or worse. Afterall, who is more likely to be the bad guy? The corporations hurting linux by killing accessibility and interoperability, or the guy giving his spare time to save them?

Find your criticisms of others and, if valid, air them. But surely, don't expect others to be silent in the face of harmful and terrible voices.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#358

Post by tancop »

bayindirh wrote: post #272
The_President wrote: post #116

Earlier quoted context omitted.

The Bluetooth integration needs work - missing features such as "never connect automatically." Default lock screen experience still has a needless delay of 5 seconds when entering a wrong (even blank wrong) password, even on the first attempt. +1 on the gamma controls

Well, seeing how systems are brute-forced and how much speed you can achieve today, these delays are more and more welcome on my end.

[dead]

Re: Preparing for KDE Plasma's Last X11-Supported Release

#359

Post by justinclift »

ceayo wrote: post #281
justinclift wrote: post #168

> Our internal metrics within KDE show that over 95% of users of Plasma 6.6 are on Wayland Wonder how representative of the real end user population this is?

I think most people who even know the difference between x11 and Wayland are much more privacy conscious then those who don’t. 0% of people going out of their way to jump through all the hoops to get plasma working on x11 would ever opt in to such metrics.

Nah, don't think so. When I setup my main dev desktop (a Debian variant) a few months ago it defaulted to X11 and getting Wayland to work on it was a pain in the butt.

That being said, on a different box with an older gen Nvidia card (3070) it defaulted to Wayland and just worked out of the box.

So, bit of a mixed bag. ;)

Re: Preparing for KDE Plasma's Last X11-Supported Release

#360

Post by LtWorf »

dwattttt wrote: post #355
LtWorf wrote: post #306

Earlier quoted context omitted.

> Meanwhile there is a slightly larger minority that need things that cannot be done in X. List of things that cannot be done in X:

That's not actually a good thing. General purpose programming languages as configuration file formats also give you "can do anything"; but when it comes time to try to improve or update the Python package ecosystem, you're forced to break backwards compatibility. Or give up on whole classes of improvements, because you can't constrain package behaviour at all.

You mean like how wayland is breaking backwards compatibility?
Post reply on HN