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

X12: Requirements for a successor to the X11 protocol (2013)

x.org

Post reply on HN
Print view View original

251–260 of 318 posts

Re: X12: Requirements for a successor to the X11 protocol (2013)

#251

Post by throwawaylinux »

kelnos wrote: post #191
vetinari wrote: post #132

Earlier quoted context omitted.

1) no, he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. So they had to maintain it, despite not being used in practice, except by that little something that nobody can point their fingers at. 2) he talks about obsolete hardware. There's no really a point to support s3 t…

> he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. The thing that I find ridiculous about this attitude is that you have two choices: 1) Remove parts of the core that some (mostly old, unmaintained) applications rely on, which will break them. You'd probably have to cal…

3) Build a new system that supports the old system reasonably well and doesn't prevent people using and improving the old system until the new one meets their needs.

> If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered.

It's true though there have been features missing. It's good thing that they are being worked on though, no? The X protocol and the Xorg implementation are both abandonware, so your comment comes across as positive, because missing $IMPORTANT_FEATURE in X/Xorg is not WIP.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#252

Post by throwawaylinux »

destructionator wrote: post #246
vetinari wrote: post #132

Earlier quoted context omitted.

1) no, he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. So they had to maintain it, despite not being used in practice, except by that little something that nobody can point their fingers at. 2) he talks about obsolete hardware. There's no really a point to support s3 t…

> That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland). I do, in fact, use modern X11 apps over the network literally every day. Some are better than others - if the programmer made the effort to actually gracefully degrade it can be a considerably better experience than the ones wh…

If you don't mind answering, what do you do that uses GUI over network? Not looking to argue or try to claim would work better or anything, just curious what people use it for seriously these days.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#253

Post by throwawaylinux »

destructionator wrote: post #245
chlorion wrote: post #220

Earlier quoted context omitted.

None of Waylands internal functions between a client and compositor are blocking or synchronous to my knowledge. Generally you fire off a message and will later receive an event back from the compositor, which is happening in an event loop. There is an exception, which is the explicitly blockling "roundtrip" function(s), but that is meant for special cases only. Being asynchronous was an design goal for Wayland from…

This isn't that different than X though which also has the fire off a message and receive event back. Very few of the functions actually make you want (even in xlib, which wraps the protocol itself to be a bit easier to use from C, the majority of functions still are async - much to the chagrin of newbies trying to decipher error messages)

What do you mean by all Wayland's calls being blocking though?

Re: X12: Requirements for a successor to the X11 protocol (2013)

#254

Post by Cheeeetah »

steponlego wrote: post #109
bitwize wrote: post #83

Earlier quoted context omitted.

100% of the developers who know anything about how graphics works under Linux are focusing on Wayland. Development on Xorg is moribund, with only Xwayland getting significant attention. Hint: X was optimized for 1980s graphics, which was 90% simple blits, line draws, and fills mediated by the CPU perhaps with special fixed-function accelerators for those operations. In 2023, graphics is done with the GPU -- period. Y…

It doesn’t matter to me if the X.org developers have decided not to do their jobs, which is maintaining X.org. This isn’t proof that X.org is bad, it just shows that giggers who really work for big tech firms shouldn’t also be trusted to maintain Free software. I’ve noticed them slowly trying to ruin X.org for a couple years now, deprecating drivers for no reason whatsoever, etc.

[dead]

Re: X12: Requirements for a successor to the X11 protocol (2013)

#255

Post by froh »

nine_k wrote: post #212
blibble wrote: post #167

Earlier quoted context omitted.

redhat seem to have tried their best to use systemd to turn Linux into Windows NT - over-complicated service manager - binary logs that are difficult to find - incomprehensible task scheduler - hidden caching dns resolution service - disk manager - network manager - login management - crappy ntp client all it needs is svchost.exe something that was 100% reliable is now about 98% reliable, and when it inevitably break…

But look, having a stack that replaces many Unix services, and which you basically completely control, is very convenient. It allows, say, to drastically limit third-party userland in embedded systems, where Red Hat is big. Systemd is trying to replace Unix, a bit more successfully than GNU Hurd.

this.

the whole "sysv init is so slow because of shell scrips" was a scapegoat. yes bash is relatively slow. and yes, dash is the answer to that problem, not systemd.

they who control systemd now control Linux as an OS. not as an API (that's kernel/libc) but as an OS. how you manage it, run it, suspend it, initialize it, turn it off, everything

was RH, and now is MS.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#256

Post by steponlego »

bitwize wrote: post #249
wkat4242 wrote: post #239

Earlier quoted context omitted.

Yeah I know RedHat 'maintains' X11, this is part of the politicizing they do. Embrace, extinguish, they just forgot the extend part :) RedHat and their business focus is a lot of what is wrong with Linux for users today. We don't make money for RedHat so their priorities aren't with us. I'm hoping someone will still take it over for when happens. RedHat doesn't own X11. Wayland has its uses but there's a lot of niche…

Probably your best hope is OpenBSD's Xenocara project, a fork of Xorg. If Xorg bitrots away and Red Hat won't touch it, some OpenBSD madlads are likely to step up... at least until Wayland gets running well on OpenBSD. :)

OpenBSD runs on architectures which will never be supported by Wayland, it’s very doubtful they’d switch.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#257

Post by pjmlp »

blibble wrote: post #167
Aardwolf wrote: post #162

Earlier quoted context omitted.

Simply the fact that systemd turned logs into a binary format that can't be read with standard tools, and this was not (easily? at all?) possible ti cgange made me really strongly dislike it. systemd has its own tool to read its binary log format, but I've already seen it corrupt its own logs and fail to read it. And did they do the binary format for efficiency? Get this: I've never seen anything be inefficient due t…

redhat seem to have tried their best to use systemd to turn Linux into Windows NT - over-complicated service manager - binary logs that are difficult to find - incomprehensible task scheduler - hidden caching dns resolution service - disk manager - network manager - login management - crappy ntp client all it needs is svchost.exe something that was 100% reliable is now about 98% reliable, and when it inevitably break…

Only if we ignore the fact that commercial UNIXes already did this before systemd came to be.

Also in the Cloud OS world, classical UNIX doesn't even matter that much, we only need something to run those containers or managed runtimes on top of.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#258

Post by nine_k »

froh wrote: post #255
nine_k wrote: post #212

Earlier quoted context omitted.

But look, having a stack that replaces many Unix services, and which you basically completely control, is very convenient. It allows, say, to drastically limit third-party userland in embedded systems, where Red Hat is big. Systemd is trying to replace Unix, a bit more successfully than GNU Hurd.

this. the whole "sysv init is so slow because of shell scrips" was a scapegoat. yes bash is relatively slow. and yes, dash is the answer to that problem, not systemd. they who control systemd now control Linux as an OS. not as an API (that's kernel/libc) but as an OS. how you manage it, run it, suspend it, initialize it, turn it off, everything was RH, and now is MS.

RH is s/MS/IBM/, quite literally.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#259

Post by pjmlp »

froh wrote: post #255
nine_k wrote: post #212

Earlier quoted context omitted.

But look, having a stack that replaces many Unix services, and which you basically completely control, is very convenient. It allows, say, to drastically limit third-party userland in embedded systems, where Red Hat is big. Systemd is trying to replace Unix, a bit more successfully than GNU Hurd.

this. the whole "sysv init is so slow because of shell scrips" was a scapegoat. yes bash is relatively slow. and yes, dash is the answer to that problem, not systemd. they who control systemd now control Linux as an OS. not as an API (that's kernel/libc) but as an OS. how you manage it, run it, suspend it, initialize it, turn it off, everything was RH, and now is MS.

Solaris:

https://www.oracle.com/technical-resources/articles/solaris/...

macOS:

https://developer.apple.com/library/archive/documentation/Ma...

Re: X12: Requirements for a successor to the X11 protocol (2013)

#260

Post by throwawaylinux »

dale_glass wrote: post #178
Aardwolf wrote: post #162

Earlier quoted context omitted.

Simply the fact that systemd turned logs into a binary format that can't be read with standard tools, and this was not (easily? at all?) possible ti cgange made me really strongly dislike it. systemd has its own tool to read its binary log format, but I've already seen it corrupt its own logs and fail to read it. And did they do the binary format for efficiency? Get this: I've never seen anything be inefficient due t…

The binary log format has a huge advantage: it allows for arbitrary amounts of fields containing arbitrary content. Unlike syslog, journald is trivial to parse unambiguously, and you can even dump binary data like crash logs into it if you really want to. It also parses universally -- you always know what the timestamp is, you don't need to craft a per-service regex. I'm not sure what would be a better alternative. I…

If an application provides some standard command line tool that allows its internal data to be output as formatted text, then it in fact can be read with standard tools and manipulated with shell pipelines and scripts.

Plain text files are nice where possible, but binary formats are not automatically going against the Unix Way.

Post reply on HN