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

171–180 of 318 posts

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

#171

Post by wmf »

terrorOf wrote: post #149
wmf wrote: post #138

Earlier quoted context omitted.

Since 99% of users are on Linux anyway, that can't be the largest issue.

What a typical Linux user mindset! That IS one of the largest issues for non-Linux users. Linux is by large margin a niche OS in desktop market share. So it is no issue if all programs are developed only for Windows and/or Macintosh. Right?

I admit that appealing to capitalism isn't likely to advance the Unix desktop but the "we're all in this together" excessive portability attitude didn't produce good software either.

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

#172

Post by ilyt »

dark-star wrote: post #96

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D

For me personally X11 just got to the point where everything I want works out of the box so switching to wayland seems like entirely pointless experience.

I'm also not a fan of attitude of moving support of even basic functionality like "take a screenshot" or "handle mouse/trackpad properly" into higher layers, it just feels like a lot of work duplication and moves that repetition of work to window managers

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

#173

Post by haileys »

dijit wrote: post #163
zozbot234 wrote: post #153

Earlier quoted context omitted.

The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.

Chiming in here to say that systemd seems to cover the 80% (or even 90%) case pretty nicely, however that last 10-20% is now really difficult. Anyone who has really delved into systemd knows this but they get shouted down as halting progress and hugging bash scripts, which is disingenuous as bash scripts (as per sysvinit) were painful and had great difficulties in areas such as determinism and parallel execution. If…

> If you ever want an example of what I mean: look at how systemd starts mysql. Someone (not me) spent at least a man month making that work.

I was curious, so I cracked open the mariadb.service unit that ships with Arch Linux. Other distros might ship different unit definitions, but this is the one I'm looking at.

It's large, yes, but very well commented and seems quite clear to me.

Much of the complexity seems to be around sandboxing: PrivateNetwork, CapabilityBoundingSet, PrivateDevices, ReadWritePaths, ProtectHome, PrivateTmp. These are all settings to do with hardening the service. They're totally optional, and can be removed without impacting functionality.

There is some extra complexity in the ExecStartPre and ExecStartPost commands. This appears to be something to do with the Galera cluster functionality. I'm not entirely sure what's happening with those, but I imagine these commands would also be present in a SysV init script implementing the same functionality.

The rest is pretty standard stuff: the user/group is set, along with the umask and some ulimits. LD_PRELOAD is set to load jemalloc. There's also some start/stop timeouts configured, with a comment explaining that these same timeout values were used in the SysV init scripts in the past.

Essentially, I'm not really sold that any of this complexity is caused by systemd. The hardening strikes me as a little unusual, and at a guess I'd say that this probably wouldn't be present in a SysV init script. If it were, the configuration would live in executable code, not in strictly declarative config directives.

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

#174

Post by dale_glass »

dijit wrote: post #163
zozbot234 wrote: post #153

Earlier quoted context omitted.

The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.

Chiming in here to say that systemd seems to cover the 80% (or even 90%) case pretty nicely, however that last 10-20% is now really difficult. Anyone who has really delved into systemd knows this but they get shouted down as halting progress and hugging bash scripts, which is disingenuous as bash scripts (as per sysvinit) were painful and had great difficulties in areas such as determinism and parallel execution. If…

This?

https://gist.github.com/thomasfr/e4e4bb64352ee574334a

I don't see anything out of the ordinary there.

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

#175

Post by emersion »

jmclnx wrote: post #114
dark-star wrote: post #96

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D

The largest issue with Wayland is it has "Linuxisms". That means no work was done by the Wayland people to make it portable to other UN*X. So the BSD folks (and other UNIX people) have a lot of work to get it going. And there still seems to be confusion if or will Wayland require systemd, from what I have seen, no 100% clear direction from anyone.

This used to be true, but not anymore. We have upstream support for FreeBSD in libwayland now. Other BSDs have MRs which are only waiting for CI support.

Wayland itself has nothing to do with systemd, many users are running Wayland without systemd.

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

#176

Post by haileys »

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…

Describing SysV init as 100% reliable is a very rose-tinted view of history, I think.

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

#177

Post by bawolff »

jmclnx wrote: post #114
dark-star wrote: post #96

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D

The largest issue with Wayland is it has "Linuxisms". That means no work was done by the Wayland people to make it portable to other UN*X. So the BSD folks (and other UNIX people) have a lot of work to get it going. And there still seems to be confusion if or will Wayland require systemd, from what I have seen, no 100% clear direction from anyone.

I mean, is it really wrong for linux people to focus on linux? What's the point of these different OS's if they all support the same software and software has to be made for lowest common denominator?

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

#178

Post by dale_glass »

Aardwolf wrote: post #162
dark-star wrote: post #96

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D

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 guess it could have gone with dumping JSON, but then you have issues with newlines, or escaping, and a single bad character can break parsing. At that point you might as well go binary, IMO.

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

#179

Post by Bjartr »

vetinari wrote: post #150
mort96 wrote: post #135

Earlier quoted context omitted.

Isn't xdg-desktop-portal a flatpak thing? It claims to be so here: https://github.com/flatpak/xdg-desktop-portal > A portal frontend service for Flatpak and possibly other desktop containment frameworks. When it comes to global shortcuts, I'm not saying it has a super easy solution, but it's something that it's essential to support. Wayland intentionally doesn't, and I can't see that changing in the short term (as yo…

It is dbus api, and is able to work cross-namespaces (i.e. flatpak containers too). There no harm in using it in non-flatpak apps, at least you will be ready if your app ends up in flatpak. Wrt global shortcuts, I see that there is some work done. The intentional part isn't malice, as in not willing to implement it at all. It is about not implementing temporary solution, that will be quick and dirty, and then being s…

So kind of like Go and generics in that regard

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

#180

Post by ilyt »

zozbot234 wrote: post #153
WhatIsDukkha wrote: post #151

Earlier quoted context omitted.

You are presenting this in certain way that I think veers into inaccurate and misleading in an attempt to smooth things over and be nice. What we had before systemd was - 90% glue code, reimplemented quite badly across X distributions. That glue code was, in practice, extremely brittle and very very unfun to attempt to keep even simple daemons running "portably" distribution to distribution. The other 10% was increas…

The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.

> The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.

I call bullshit on that.

We removed few thousand lines of SysV init scripts from our configuration management that were basically fixed by us for subtle errors when we migrated to systemd. There is very little cases that aren't handled by very simple systemd units, in fact I'd dare you to give example that would be easy in SysV and hard in systemd.

Few fun cases:

Process after doing /etc/init.d/servicename start -> status immediately returned service stopped. That confused service managers like Pacemaker that thought the service failed to start. Why?

The app did start -> save pid file. Java app so it took a second.

The script just forked the app into background. So if you run status after start the pidfile was not there and it showed it is stopped. Not the problem in systemd

Another

(IIRC) MySQL init script put pid file in /var/run/, like everything else. Bit old install so /var/run wasn't a separate partition or tmpfs.

MySQL init script also didn't try to start if it found the PID existing in system. It didn't check what* was running tho.

So in crash scenario, server started, MySQL init script went "oh, there is apache daemon using that PID I had last reboot, clearly that means mysql is working" and exited. MySQL status returned MySQL working. Not a problem in systemd

Another:

Script just... sent signal and exited on stop. App could took some minutes to shut down. stop -> start failed, pid was lost coz script removed file with it after sending signal.... similar problem with multi-process app scripts not killing all childs. Systemd "just have a cgroup and mark service as stopped once everything dies" fixes that. YOu can ask for that behaviour if you tell systemd to not kill processes on stop but that's pretty much "purposefully using non-default settings" so can't be really done on accident.

IIRC all or most of that is how SysV init script by standard should not work but were simply bugged

Those scripts were in popular packages in "enterprise" linux distros. If even those maintainers can't make "simple SysV script" then maybe sysv scripts aren't as "simple" as some people claim they are.

Post reply on HN