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

Understanding the working of X11 from the ground up (2017)

magcius.github.io

Post reply on HN
Print view View original

41–50 of 134 posts

Re: Understanding the working of X11 from the ground up (2017)

#41

Post by pedrocr »

simion314 wrote: post #11
roenxi wrote: post #7

Earlier quoted context omitted.

The basic problem with X11 is it wraps a whole bunch of things into one software package. So in theory you have to know about fonts, OpenGL, graphics drivers & memory management, the window model and networking simultaneously to configure and run the thing. Wayland is a protocol for a well designed future where all that functionality is broken up into separate pieces of software. Wayland handles the window model and…

The issue is I need the powerfull features, like I have a script that OCR a region of the screen when I press a button (the coordinates depend of the app that runs) so I do not want a GUI provided by the DE to let me capture the screen. Anyway the issue with Wayland is that it is not ready, the important screen recording feature is yet not here,I seen also some complaints from gamers and their issues are a won't fix,…

>like I have a script that OCR a region of the screen when I press a button (the coordinates depend of the app that runs)

This is easy to do. Something like grim to take the screenshot of whatever region you want:

https://github.com/emersion/grim

And calculate the coordinates you need by querying the window manager. In sway (i3 compatible tiling WM) that would be:

$ swaymsg -t get_tree

To get a JSON of all the windows currently open and do whatever math is needed.

You can also do a hand selection using slurp:

https://github.com/emersion/slurp

It works together with grim like this:

$ grim -g "$(slurp)" screenshot.png

Having recently moved from X to Wayland there are still some things missing sometimes but they're not many. If you want a DE at least GNOME and I think KDE as well are making the switch reasonably seamless. And there are some features that Wayland solves much more thoroughly (e.g., tear free output, fractional scaling). The network transparency part, that is often brought up but rarely used in X is also being delivered:

https://lists.freedesktop.org/archives/wayland-devel/2019-Au...

Re: Understanding the working of X11 from the ground up (2017)

#42

Post by throwaway2048 »

pcr910303 wrote: post #40
legulere wrote: post #26

Earlier quoted context omitted.

The problem with file systems is that it is extremely difficult to build reliable systems on top of them. It’s shared mutable state with barely any error handling possibilities.

> It’s shared mutable state with barely any error handling possibilities. And that makes me think about scoped file systems... (gotten the idea from global & scoped variables) Since the biggest advantage of ‘everything is a file’ is that it allows a consistent API for manipulating data, why didn’t this happen?

plan9 namespaces and user filesystems along with bind mounting achieved this sort of scoping.

Re: Understanding the working of X11 from the ground up (2017)

#43

Post by heavenlyblue »

alxlaz wrote: post #34
rvz wrote: post #28

Earlier quoted context omitted.

> Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. Brings back memories of the old days of the late 1990s trying out so many workstations running obscure Linux distros to actual UNIX OSes like IRIX, Solaris and HP-UX. They all ran some variant of X11 which was part of the UNIX philosophy which I found interesting (X11 forwarding, startx, etc) but as the requirement…

The uncomfortable truth today is that, while having to touch an X config file hasn't been a thing in more than 10 years, it will take you some fiddling with your favourite Wayland compositor (of which only three -- two massive DEs and a tiling compositor -- are anywhere near being useful) just to get it to stop crashing on that one application that you need, or to get things like multiple monitors or middle-click cop…

Are you saying that Wayland doesn’t not only run on Nvidia, it’s also buggy as hell?

Re: Understanding the working of X11 from the ground up (2017)

#44

Post by Znafon »

pcr910303 wrote: post #17

This is a bit of topic but: Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. It’s a pity that instead of improving the speed of the file system, everyone started to ignore it, hence making it’s speed even less important, and on and on... And now nobody uses the file system for these purposes.

> I realize that the UNIX philosophy (everything is a file) is dead

Was it ever alive? As far as I know lo0, eth0 and others where never accessible as a file interface and we still rely on them. Is there something to gain to give them a name on the filesystem?

Re: Understanding the working of X11 from the ground up (2017)

#45

Post by draw_down »

pcr910303 wrote: post #17

This is a bit of topic but: Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. It’s a pity that instead of improving the speed of the file system, everyone started to ignore it, hence making it’s speed even less important, and on and on... And now nobody uses the file system for these purposes.

I’m ok with it, everything isn’t a file.

Re: Understanding the working of X11 from the ground up (2017)

#46

Post by iikoolpp »

shmerl wrote: post #31
sly010 wrote: post #23

Earlier quoted context omitted.

In one word, nvidia.

Easy to fix - don't use it. Linux users today stay away from it for good reasons.

I specifically bought only NVIDIA GPUs because they were faster under Linux when I got them.

Re: Understanding the working of X11 from the ground up (2017)

#47

Post by pcr910303 »

mmrezaie wrote: post #27
pcr910303 wrote: post #17

This is a bit of topic but: Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. It’s a pity that instead of improving the speed of the file system, everyone started to ignore it, hence making it’s speed even less important, and on and on... And now nobody uses the file system for these purposes.

How do you think it should have evolved? I personaly think posix way of filesystem needs to be changed into specialized oject filesystems, but I am not sure what object filesystem for a UNIX OS should look like specially since it needs to be generalized into something all the other sub-systems can benefit from.

Personally I also preferred the ‘Everything is an object’ from the lisp machines. However, I also believe that files are an acceptable object format, since if several applications know how to manipulate a file format, it’s basically duck typing.

I believe file systems could have a more formal method to query the file’s format, and has less latency so that applications could use files as an inter communication format.

Re: Understanding the working of X11 from the ground up (2017)

#48

Post by geofft »

fao_ wrote: post #39
lvc_ wrote: post #32

Earlier quoted context omitted.

Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. The implications are more around having a standard set of syscalls for moving data in and out of a program, abstracting away where it actually lives and treating the data itself as something opaque.

> Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" You're right that it never meant 'everything is a disk file', but generally the implication of the unix philosophy was that everything could be accessed from the filesystem. Have a look at Plan9, which is essentially directly descended from 7th edition UNIX and IIRC was built from what w…

And it can be, see /tmp/.X11-unix/.

Re: Understanding the working of X11 from the ground up (2017)

#49

Post by fao_ »

geofft wrote: post #48
fao_ wrote: post #39

Earlier quoted context omitted.

> Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" You're right that it never meant 'everything is a disk file', but generally the implication of the unix philosophy was that everything could be accessed from the filesystem. Have a look at Plan9, which is essentially directly descended from 7th edition UNIX and IIRC was built from what w…

And it can be, see /tmp/.X11-unix/.

Original parent commented that UNIX was dead, given that Wayland does not seem to have an accessible interface from the file system, and nor does SystemD, Pulseaudio, or any of the major new things on the desktop system, I am inclined to agree. Of course Xorg is accessible from the filesystem, but it's probably one of the last technologies to have such an interface.

Re: Understanding the working of X11 from the ground up (2017)

#50

Post by geofft »

pcr910303 wrote: post #37
lvc_ wrote: post #32

Earlier quoted context omitted.

Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. The implications are more around having a standard set of syscalls for moving data in and out of a program, abstracting away where it actually lives and treating the data itself as something opaque.

> "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. Yeah, and shouldn’t that (theoretically) file systems with very small delay? (For example, RAM based file systems for inter-process communication.) I thought that it isn’t the slow storage that is blocking use of files, but more of a software problem that has significant overhead to use files as a communica…

If you're sending a message to some process for it to consume, like X11 or like standard input to your shell, sure, you could technically interoperate via disk, but

- UNIX itself has no inotify/kqueue/etc. feature, blocking reads are via pipes or sockets, not regular files (plain UNIX tail -f polls the file every fraction of a second)

- you're appending to the end of the file for a message that's going to get read once, and the file model of UNIX doesn't let you truncate a file from the beginning, so it will just grow indefinitely for no reason

- one benefit of the open socket/pipe approach is you get notified if the other side exits/crashes, you can't detect that from a disk file

Post reply on HN