zxzax

32 ms·

271.
by zxzax 5y ago
The issue I know of is, you cannot really use waitpid(-1, ...) in the same process as waitpid(<pid>, ...), as it would create a race condition on which call consumes the pid first. You can mitigate it in some programs by doing a looku
272.
by zxzax 5y ago
I don't know what you mean you'll need to break it again, this one particular hole is already plugged in Wayland. That won't cause additional breakage, and you'll still want to be plugging those additional holes like ptr
273.
by zxzax 5y ago
I get that, but everyone else also seems to have that attitude, so you see why it doesn't really get done when nobody has any wheat or bread :)
274.
by zxzax 5y ago
IME, most of those functions tend to get implemented in the DE when it turns out they're actually useful, or some other mechanism can be used to activate them. So no reason to get hung up on that particular method to do it either.
275.
by zxzax 5y ago
People have been asking for similar grab-type things since early on in Wayland, and there have been many proposals, but nobody has actually stepped forward to build such a permission system that would work everywhere and would not create ad
276.
by zxzax 5y ago
Wayland obviously cannot solve all security issues and privilege escalations in the underlying OS -- the solution to that problem would be to just disable debugging within that security context. In Wayland the situation is also not so much
277.
by zxzax 5y ago
All of your concerns regarding music players are actually already addressed by the MPRIS spec: https://specifications.freedesktop.org/mpris-spec/latest/ This problem has been solved in the DEs for quite some time
278.
by zxzax 5y ago
Can you elaborate? I found it very easy to interact with once I learned how to use the tooling (busctl, d-feet, etc). I also don't think I would say it's desktop-focused, it was designed for that use case originally, but it seems
279.
by zxzax 5y ago
Again, what you are saying is not correct. You may be comparing their designs to other apps developed for other desktops using other toolkits, but that's not what is influencing GNOME. The space is saved compared to previous designs th
280.
by zxzax 5y ago
The issue is solved in any service manager as long as the service doesn't fork, when you are the parent process you can ensure that you don't reap the child before sending a signal. Once the service forks then it becomes a problem
281.
by zxzax 5y ago
I don't think that would necessary solve it, since the maximum number you can have open is still RLIMIT_NPROC * RLIMIT_NOFILE, right? It seems it would still be a problem as long as it's greater than RLIMIT_NPROC. Edit: I suppose
282.
by zxzax 5y ago
Not really, most systems should set RLIMIT_NPROC to prevent that. If pidfds held onto the pid, it would create a new denial-of-service that allowed random other processes to keep zombie processes open, and the fix for it would actually allo
283.
by zxzax 5y ago
But that's more working around the problems than fixing them, no? You can't really move all signal handling logic to a dedicated process, because every process can receive signals. And as for databases: every major production data
284.
by zxzax 5y ago
The problem was discussed quite a lot around the introduction of pidfds: https://lwn.net/Articles/773459/ https://lwn.net/Articles/784831/ In essence it's a classic TOCTTOU.
285.
by zxzax 5y ago
I think the idea with that was it would lead to denial-of-service type situations where some process could leak a bunch of pidfds and then that would cause exhaustion of pids everywhere else.
286.
by zxzax 5y ago
Something else that doesn't often get brought up here is that kill(2) itself is an unfixable race condition waiting to happen. It's only safe to use that to signal direct child processes. In Linux, programs should be using the new
287.
by zxzax 5y ago
I looked into this a while ago -- a traditional transactional CRUD database is totally unnecessary here, these are not files that you want to be editable by random tools. The journald log files have the important property that they are appe
288.
by zxzax 5y ago
Having a lot of small composable functions and a lot of singly linked lists describes most functional programming languages though. I think that's only one part of the traditional Unix design. Though to me it was always seemed like th
289.
by zxzax 5y ago
This is a common thing I hear but it's not true. The hamburger menus were done to save space and reduce clutter, not out of any desire to be a tablet app. I sympathize with your criticism but it wasn't done for that purpose, it&#x
290.
by zxzax 5y ago
>the wrong people claimed ownership of the subsystem That's... not what's happening at all? The issue is there _wasn't_ any of the right people around to claim ownership of the bug. It's not like someone in the know c
291.
by zxzax 5y ago
I have to say, that seems like a strange requirement: I have never really considered Emacs (or Lisp) to be particularly Unix-like at all! I think the plan 9 people would probably tell you to ditch Emacs and use acme (Me personally, I say us
292.
by zxzax 5y ago
The customization in the desktop of GNOME itself is still there, but it has mostly moved to shell extensions. If you're willing to deal with that, you can change quite a bit of functionality. The apps are a different story, those tend
293.
by zxzax 5y ago
Sorry I wasn't clear -- most of the stuff I was talking about (hashmaps, b-trees, parsers, low-level utility functions, etc) is the private and unstable stuff, in the sense that it's a little too specialized towards systemd's
294.
by zxzax 5y ago
I think the comments towards the bottom of this thread is what is being referred to: https://web.archive.org/web/20140928104327if_/https://plus.g...
295.
by zxzax 5y ago
Does it really make a difference whether it's called libsystemd or something else? If you're talking about the other functionality that's private and unstable, it's not included in a separate library for exactly that rea
296.
by zxzax 5y ago
I don't know the status of this on a practical level (e.g. in any given distro) but systemd does support daemonless dbus access over a private socket (/var/run/systemd/private) in some scenarios. Would that help?
297.
by zxzax 5y ago
Just to be clear: the alternative there is that nobody looks at the bug at all because nobody but the bug reporter has the hardware. I don't think that's what you want, I assume you would just prefer the bug to be fixed.
298.
by zxzax 5y ago
I think they are aware of what they signed up for. Linux has continued to grow year after year, the reality for them is that they can afford it.
299.
by zxzax 5y ago
I've seen a lot of these comments to this effect but I'm still not quite sure: what is the issue with dbus? Is there another replacement that meets all the use cases?
300.
by zxzax 5y ago
It has been supported for at least the last 9 years now, I don't see why they would have any reason to break it. >The main reason why they haven't yet is most likely that their attempts to integrate dbus into the kernel and sys

More ›