Live data from Hacker News

Cool but obscure X11 tools

cyber.dabamos.de

221–230 of 256 posts

Re: Cool but obscure X11 tools

#221

Earlier quoted context omitted.

> Oh, and Lennart Poettering is also a jerk. Not an "I'm brash" kind of jerk (like Linus can be), but an "I'm an insecure person; don't critique my code" kind of way. Also, he thinks he's smarter than every one. I think it's largely due to how the community has treated him. It's frankly disgusting.

He's been that way for a long time; before he ever touched systemd. Same situation around avahi, and later around pulseaudio. I agree some people have behaved unkindly as well, but that doesn't excuse what he does. He also has a nasty habit of forcing his work into places where it is not wanted (especially now that he works for red hat).

I have to admit that avahi has caused me more trouble -- 100% CPU spin loops -- than any other piece of system software, over many years. It does nothing I want done, does it badly, and is inexplicably hard to get rid of.

PulseAudio mostly works, now, but I will be happy to see its low-latency successor displace it.

Systemd's only great sin is using up 100MB in each VM to do what should takevno more than 4M. As memory gets bigger, I run more VMs, so systemd usage grows apace. Maybe I should be running containers instead, but Qubes doesn't work that way.

Re: Cool but obscure X11 tools

#222
post #167

Earlier quoted context omitted.

I do not know about the person you are responding to, but I particularly take issue with how PA abstracts the hardware and does not allow low latency applications or servers such as Ardour, JACK, or other professional audio recording software to access it in an efficient manner. So you end up with this weird situation where pulseaudio reroutes itself when JACK appears and no longer takes control of the sound card. Wh…

Just how loudly do you think people would complain if PulseAudio decided to link in JACK and replace it, instead of getting out of the way (and becoming a JACK client itself, I believe).

If PA was actually capable of half of what JACK does, they would be fine with it. These people just needs to record music without latency. But PA does not do what they need, so they would indeed complain.

Re: Cool but obscure X11 tools

#223
post #146

Earlier quoted context omitted.

Don't forget to thank him for `avahi' too. Avahi is a fun whack-a-mole game where your computer hides the network connection. You win the game by remembering to kill processes and setting up stuff manually, like most games produced by LP studios. edit: Other popular games include: SystemD: hack your way through a blob of intractability. Try it on Nightmare mode, where you're only given access to a empty bootscreen, f…

You’re confusing Avahi with NetworkManager, which, IIRC, Lennart should not be blamed for. Avahi is simply an implementation of the ZeroConf service discoverability protocol, as also used by macOS’s “Bonjour”.

Avahi, in all my experience over many years, does nothing noticeable besides going into 100% CPU spin loops at random intervals. Looking it up online, it is reported and declared fixed every couple of years. I would like to know why it still happens, and the right way to get rid of it, or at least to know why I have to have it.

I don't have any other system daemons that like to drop into 100% CPU spin loops. Should I be happy it doesn't fork bomb? I guess I am.

Re: Cool but obscure X11 tools

#224

Earlier quoted context omitted.

openrc, runit, s6, upstart* dmix, jack, pipewire * now maintained at https://gitlab.com/chinstrap/startup

Jack does not overlap with PulseAudio. Pipewire does, but it came later and has the explicit purpose of unifying Jack and PulseAudio. Upstart is decidedly inferior to systemd; the event-based architecture is much harder to understand and apply than the target/dependency architecture of systemd. And systemd is in use in distros ranging from embedded (LibreELEC) to enterprise server, it must be doing _something_ right.…

Regarding the event driven architecture: it is far easier to understand than systemd's dependency system. But it is indeed more difficult to apply, particularly because it is a departure from how most systems work currently and in the sysvinit past.

I enjoy the architecture, and hope to continue developing Upstart/startup or at least work with a similar model.

Re: Cool but obscure X11 tools

#225
post #176
post #165

Earlier quoted context omitted.

> Well, I think Lennart misjudged how much trouble his projects caused. And especially Systemd was nothing you could easily avoid. Think about your second sentence a bit, and why it's true: major Linux distributions adopted systemd. Did they do that because it really caused a bunch of trouble or because a deliberative review process showed that it solved a number of hard problems? A small percentage of people having…

i think Lennart should be commended. Certain "projects" have such breadth in scope that they seem undermountable because they require an entire ecosystem to follow. Init was one of these. He managed to change it, it hurt, but it was for the better, all things considered.

It would be better if it did not eat 100MB, though.

It is hard for me to imagine what it could be doing with so much RAM.

Re: Cool but obscure X11 tools

#226

Earlier quoted context omitted.

From what I remember when trying to use it, it looked nice but it was very buggy Not sure it even supported threads for a while

Was it DDD that didn't support threads, or GDB though? I remember that GDB support for threads was horrific for a long time, especially back in the 90's.

I have not been tempted by ddd since I found cgdb.

Re: Cool but obscure X11 tools

#227

Earlier quoted context omitted.

Please be advised, I've downvoted your comments asking "if you know better, where's your code?", because I think that line of argument is absurd and has no legitimacy. To use some analogy, imagine I, a non-cook, have been invited to a restaurant by friends. After the meal I say to the waiter "this food is way too salty!", and he replies, "Oh yeah, then go in the kitchen and replace our cook!". What, you think we all…

No, your analogy isn't correct though. You're broadcasting your opinion on an online message board, not just a waiter. Plus, you're paying for the food. It's nothing alike. The parent comment is basically implying that the cook has cooked the dish completely wrong and that he (a non-cook) could do a better job of cooking that dish. Plus, isn't this the great thing about open source? If someone doesn't like systemd, t…

> The parent comment is basically implying that the cook has cooked the dish completely wrong and that he (a non-cook) could do a better job of cooking that dish.

I may not know how to cook (insert complicated dish here) but I can tell if it's too salty. Users of systemd / whatever software this man wrote may not have the time to do all the stuff I mentioned, but they know using/configuring the system is a nightmare.

> It's easy to complain and bitch online, that's the problem. Everyone seems to know the solution but no one seems to do it.

I repeat, they might not know the solution, just that the software tastes bad to them. Some of these complainers might be able to come up with a better solution, if they had the 3 things I mentioned before, but sadly, apparently, no one actually does. Otherwise a replacement would already exist. Of course it's another thing to get distros to adapt it.

Their lack of time/ability doesn't mean they're forbidden to say "this thing sucks!". IMO at least.

Re: Cool but obscure X11 tools

#228
post #29

Cloud computing is becoming a thing ... eg. apps that runs "in the cloud" or in your browser. But with Xserver you can just ssh -X into any machine, run an app, and the front-end GUI will be visible on your machine! You can even play games that way. Technology keeps going in circles ...

I find xforwarding extremely slow and sluggish. Can/Do you use it efficiently?

It usually helps a bit to enable ssh compression. But, some toolkits are better than others at managing the X connection; in general, things have gotten worse and worse as X over network has gotten less and less popular.

To some degree, you're never going to have a snappy experience when the program and the display have a 50+ms round trip, but it's much worse if the program makes lots of synchronous calls to the display while doing work.

Most of the older tools discussed here should be pretty good at managing the X connection and are probably doing more things in an asynchronous manner.

Re: Cool but obscure X11 tools

#229
post #187

Earlier quoted context omitted.

I find xforwarding extremely slow and sluggish. Can/Do you use it efficiently?

It works fine for me, but I can not really see any use cases, as I can just run the app locally. Use case's might be thin devices, like mobile phones and Chromebooks. Instead of running containers on Chromebooks, students could ssh into a computer that has all the apps they need; GUI apps like Photoshop, CAD, etc.

Just a couple days ago, I used remote X to show some coworkers some things:

a) a (bad) NES emulator i wrote that was on my home machine, I didn't want to compile it on the work laptop

b) chrome running on the home machine hitting a webcam pointed at a pressure gauge --- I didn't want to bother with proxying and prozy settings, and I don't let the webcam accept connections from public internet.

I've also found it super useful for running java based KVM clients for IPMI --- run a VM with the properly old version of java so the webstart file works, and display it with remote X.

xv or eog is nice for looking at images without the hassle of transferring them first (although, transferring them would probably use less bandwidth)

Post reply on HN