zxzax

Unfortunately, on Linux there is no posix_spawn syscall. It's implemented in glibc as a wrapper around clone + exec.

I can't say I agree with that conclusion, if you're just applying a patch then you don't need to edit the low level packaging. It doesn't affect the occasional user at all.

This is just for arbitrary autotools, cmake and meson projects using any language supported by those build systems. The sizes and dependencies vary. I don't really see it being much harder, the debian developer documentation is really convoluted but that's a different problem.

Last time I tried that I had bad problems with package conflicts trying to overwrite files, but it was a while ago and maybe I was doing something wrong, I'll give it another shot.

The difference there is that debhelper will usually try to keep its own modifications temporary, and otherwise keep the source in the same state as the original upstream source. So that way you know when there is going to be a merge conflict.

I'll try to respond to some of your comments, but I'll admit I'm always somewhat confused by rant posts. I never really understood PPAs, that seems like an Ubuntu thing that was not ever suggested to use in debian. If you want to stay on bleeding edge for packages, the suggestion would be to use debian sid.

I'm not sure what you mean 30 GB of memory. How is that related? And how would merging the -dev packages into the library packages solve it? IMO there are problems with the Debian approach but I wouldn't say that's one of them -- a worse problem to me is that things like cross-compiling/multi-arch mostly requires chrooting which is a lot less convenient than the approach used by something like Nix.

If the point is to look like someone who is unnecessarily rude, I would kindly request that you not do that. Please avoid throwing insults around and starting flame wars. It doesn't help anyone. We can have a good conversation without doing that.

That's great that people are doing that with FPC, but if they're continually adding new features and removing deprecated things then that's not legacy software. To illustrate further what I mean, probably none of those people can be convinced to work on other old stuff like GTK1 or GTK2, because you're really comparing apples and oranges here. If it were easy or profitable to do that in GTK, somebody would have done it already. Half the reason things changed is because the entire underlying stack changed along with the hardware -- this is not even remotely comparable to something like a self contained compiler for a programming language.

If you disagree, I'd love to hear your proposal on how to keep all the various API changes working in the same codebase without causing it to become overly complex and burdensome, and this is probably over the span of at least 20 system libraries that have all deprecated and/or removed various things over the last 30 years. From my view, part of the problem here is that there were some legitimately bad decisions made back then, that looked reasonable at the time but turned out to be not so great, and nobody really wants to keep paying for those decisions. This is not similar to something like a Pascal implementation where they could just aim for compatibility with an existing compiler from the 1970s and then build on that, these were entirely new APIs at the time and they didn't have their designs fully fleshed out, and in some ways they still don't, because the problem space is still somewhat open-ended.

You're wrong that there are no technical reasons, I assure you the technical reasons are real. Again, I can tell you if you're willing to listen, but if you're going to blanket deny they exist, we can't really have a conversation, so I won't bother typing it out. Let me know if you change your mind. In context your JWZ quote doesn't any make sense either, because Xorg got bug fixes for a very long time. It's being moved away from because it's no longer effective to keep doing that, which is the opposite of what that quote suggests. Please don't let rude and dismissive quotes like that be the guiding line of your discourse, let's actually discuss the real issues.

>If it suddenly started breaking now it wouldn't be because it is impossible to not break but because the developers somehow started breaking it.

This is the root of the misunderstanding -- there is no significant difference between these two. It's at the point where it needs a major refactor or rewrite to make continued work on it worth it, which is going to break things, and at that point writing a new display server makes a whole lot more sense.

I'm not sure I understand the question? This is for any package. Of course you will run into trouble if you introduce breakage, like removing files that the build script expects to be there, or causing merge conflicts with patches applied by the build script. But those breakages can happen with any package manifest, including PKGBUILD.

Really? For me it's literally just `dpkg-buildpackage` after patching the source. I never had any problems with it.

>It's so much harder to build your own software packages on Debian. Even patching an existing Debian package can be painful, and having to write your own packages is even worse.

I can't say that's been my experience, once I figured out dh_make [0] that made it pretty easy by handling most of the boilerplate. Building an existing package is as simple as doing `apt source` and then `dpkg-buildpackage` to rebuild it (you may have to do `apt build-dep` first too). I agree with the rest of your comments though.

Edit: I haven't looked into the details of how it works but I would imagine that YMMV with trying to use makepkg that way. The hard part here isn't getting the packages to build, it's in reconciling the library dependencies across all the tens of thousands of packages that make up both distros.

[0]: https://blog.packagecloud.io/eng/2015/07/14/using-dh-make-to...

The point there is, while some negative attitudes may not be preventing other projects from using the code, they do prevent the project from growing, and it leads to fragmentation, which I believe they are seeking to minimize. So something has to give.

That's just about managing expectations, and it falls on you to be clear in your marketing. If you said "we support all versions of Windows" then you could expect someone to misinterpret that, the same way they would misinterpret "we support all versions of Linux." So really to make it clear, you might consider only saying "we support Ubuntu Focal" or something like that. Most products I see now make it pretty obvious that they only test on some combination of Windows 7/8/10 and above, so just do the same for whatever Linux distribution.

It's not hypothetical, I've seen the odd comment like that on various forums and github, etc. You can say you aren't going to support an obscure setup without judging people for having it.

If anyone gets ousted from the process, they probably deserve it, for wasting more maintainer time. Nobody is immune from that, not you, not me, not the maintainers, not the BDFL. Expecting the BDFL to be able to have full control and to review every patch is also nonsense that causes the exact same type of issues: https://lwn.net/Articles/393694/

I wish people would not use the phrase "CADT" like this, it's not relevant, and it's insulting and ableist. Nobody wants to maintain legacy software for free in their spare time. That's all it is. It has nothing to do with the age of the person or the status being "attention deficit," which is a real condition that people actually have and suffer from. If you disagree, you're welcome to spend your spare time working on it. I support you doing that. I really doubt anybody will though, because outside of servers and Android, there is very little interest in doing anything on Linux.

If you're willing to listen, I could describe to you the technical reasons why Xorg was abandoned. But I also doubt the answer will please you, because the reality is that the reason it's perceived as being "stable" is because it's not being improved anymore -- if people were still hacking on Xorg instead of Wayland, then your Xorg would be breaking left and right too.

What is the confusion? People on Windows 98 are able to send emails too.

That has nothing to do with Linux at all, you can just as easily get some weird requests from people trying to run your game at 640x480 on Windows 98 or some other strange thing like that.

The usual response here (from any vendor, not just an independent game developer) is to say you only support the latest LTS version of Ubuntu/SteamOS with the officially supported drivers there and that's it. You're absolutely right to do that. If you want obscure distros to be able to run your program, you can open source it and let them deal with the packaging/testing/maintenance. The fact that all the OS packages are open source is the only reason all the random distros are even able to exist, so you're already making it difficult for them when you don't do this. No reason to dance around that.

The point with those laptops is, you use the keyboard when it makes sense, and you use the touchscreen when that makes sense. I think you're confusing "touch-first" with "having any support for touchscreens at all," some concessions need to be made if you don't want it to be totally unusable on a device like that which has an optional touchscreen.

The sales seem to be increasing, I wouldn't say it's a gimmick. Also touch support is not just for touchscreens, most laptops now have multi-touch touchpads where you can do gestures. Making a program support those already puts it significantly closer to having real touchscreen support, so it's not as hard or difficult as you'd imagine for older Windows programs to gain good tablet support.

I don't think so, the studies I've seen actually show the number of touchscreen devices is growing, and desktop PCs are shrinking.

Touchscreen laptops and convertible laptops are becoming increasingly common, they can't just ignore this market segment.

It does the same thing it does for audio: routes and multiplexes streams. Video devices in Linux the same problem as audio devices where multiple applications can't have them open at the same time. Pushing the video through a daemon also allows you to do the same interesting things that you can do with audio streams in pulseaudio/jack, where you can transparently change the inputs and outputs around without having to restart or reconfigure the application, and you can route video through arbitrary effect chains before it reaches the destination.

If the application can use v4l devices directly (I think this includes all ffmpeg players such as mpv) or can output a video stream somewhere, then it might make sense to also add a pipewire backend there. Maybe somebody will make this easy by adding a pipewire encoder/decoder to ffmpeg? Then the applications won't have to do much at all to support this. If the application uses gstreamer, you may already be able to get it to work automatically by using pipewiresink/pipewiresrc.

That would need UI similar to Qubes that would have to be built and integrated probably on the IDE side. Purposefully, flatpaks don't typically ship a whole OS like Qubes VMs do, so the gap has to be filled somewhere.

It really depends on what you're trying to do. Doing some things on some distros is still not possible without having the setuid bit.

Flatpak handles all that too, all these tools are using the same Linux security primitives. There is really not any difference between them from a security perspective. Technically flatpak is based around bubblewrap for some of the low level bits, which is kind of like an even simpler version of firejail: https://github.com/containers/bubblewrap

It's not papering over it if you look at the rest of the paragraph. The problem is that the IDEs just aren't made to work with this kind of sandboxing and need to be changed significantly. I agree it would be cool if someone eventually made an IDE that could operate like that.

Firejail can easily suffer from some of the same issues, if it's not configured properly. Some of the issues listed here are not specific to Flatpak, and need to be addressed with any sandboxing mechanism.

There is no such thing as "zero repercussions way out" here, and it seems to make no sense to even want that in this context. Either the bugs are real and they get fixed, or they don't and now the project looks bad; if for whatever reason the bugs turned out to not be an issue, that would be the only time it wouldn't matter in the end.

If the author isn't actively working with upstream to get them fixed, and isn't announcing that association with the project, it's probably safe to say they don't have a position of authority within that project.

You can use kdialog or zenity to run a standalone file chooser from the command line. For applications that want to integrate an external chooser, they can use the flatpak file chooser portal. Of course the caveat with these is, your application can no longer put custom widgets in the file chooser, because it is now an external process.

Please stop making these insulting comments calling me apologist, this is rude and unhelpful; you're a better person than this. I've respected your kernel expertise for a long time and it's disappointing to be treated this way. This is the kind of behavior that pushes people away from open source. I'm only here to help explain how this works and to help get the issue fixed, I would do the same if you were making such statements about KDE.

>We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.

GNOME unfortunately does not have enough maintainers to do this. If you'd like to help out, please contribute, or help direct some others to do so. That might mean helping to maintain some extensions that you're using. If you don't want to help, and you want to use KDE, that's understandable too -- but please understand what the real issue is.

>Device drivers should live in the kernel. Period.

It would be great if it was technically possible to do this with GNOME, if this is your goal, I would encourage you attempt to merge all the hundreds of extensions together into one big tree, resolve all the conflicts, and then maintain that. It's probably going to be a lot of work, and will break a huge number of things, and if you don't want to do it... well now you understand why GNOME maintainers don't either. Until that happens, people have to stick to another approach: extension maintainers just have to use CI to check their extensions against master and keep it updated.