381–390 of 428 posts
Earlier quoted context omitted.
I suppose 'power-users' can put up with 'small-button' GUIs but I do think a general purpose GUI needs to be easy to use for people who aren't used to controlling mice and keyboards all the time.
Those users won't use Devuan or Gnome but Android/iOS.
Earlier quoted context omitted.
Much of that information has to do with creating a new hardware port from scratch. The i386 support just needs to be "demoted" to the Debian ports infrastructure once it's officially scheduled to get dropped from the main Debian repository (which could well happen starting either in Debian forky or duke), and this can probably be done with some special handling. (Answering the "to what end?" question, a lot of 32bit-…
Well, the existing i386 port is going to remain as-is for supporting old software (especially games) (but the CPU baseline will likely get increased), it isn't going to be removed, so you would need a new architecture for 32bit-only hardware. Since i386 is not going to do the 2038 transition either (since that would break the ABI), also you would need to either make a new ABI for the new port, or do the 2038 transiti…
I had seen conflicting information about this, though nothing official. I suppose we'll know more once some actual release planning happens for forky, which might take some time.
Earlier quoted context omitted.
python3.7 is from June 27th, 2018 https://www.python.org/downloads/release/python-370/ Why is that the default?
I don't think it is? Or at least, it only was on some particular older Debian release.
Earlier quoted context omitted.
I think that superkuh's point is that it is not a systemd thing. Cleaning up /tmp by deleting old files has been around since before systemd was invented. Since before Linux was invented, even.
Yes but in Debian this was not a default until now. Before, /tmp was wiped on reboot. /var/tmp was not. Neither were cleaned otherwise. So for Debian, this is a systemd thing. And it was pushed by a systemd maintainer, who is also a Debian developer. I have zero interest in Debian "being brought inline" with other distros, because other distros should be coming inline with Debian.
AIX had /usr/sbin/skulker from at least as early as version 1.2.
For AT&T System 5, Fielder and Hunter were popularizing a similar utility named rmtrash that is run nightly.
Fielder and Hunter exemplify traditional Unix thinking in their 1986 book on Unix system administration, which includes rmtrash:
> By putting all temporary files in one or two directories, it is easy to clean them all out at regular intervals. For this reason, it's a good idea to encourage users to use /tmp for all files they need only a short while.
skulker is not in the old comp.unix.aix Usenet FAQ document, but given the number of times "That's what skulker does, and you should be running it daily." seems to have been the answer over the years, it probably should have been. (-:
To old hands, this is not a systemd novelty at all. The novelty, to old hands, is the idea of doing this not using a script. I remember the war stories from the 1990s and turn of the 21st century when users did things like include LF in the names of temporary files, and administrators suddenly learned the utility of find -print0 and xargs -0 or find -exec rm {} +. Stéphane Chazelas for one has had a lot to say on the subject over the years.
That said, mtree (from 1989) already existed at the point that systemd-tmpfiles was invented, and already had the idea of working from a specification file with names and owners and permissions and whatnot. It is surprising that no-one ever apparently tried mtree for completely wiping /tmp. The BSDs are using find to this day in the several places with they auto-delete stuff in /tmp including the daily periodic, although they did spot that their own find had a -delete option in 1999. (-: Hell, even I am still using find.
https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/pe...
Earlier quoted context omitted.
You may not like it, but “arbitrary” isn’t a fair description; there’s reasoning behind it that is over 10 years old: http://0pointer.net/blog/projects/stateless.html https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... That said, my knee-jerk is also that this is about strong-arming distros. Which leaves a bad taste in my mouth. I’d be interested to hear other viewpoints though.
Note that this is about a different thing - Debian has also merged its /bin into /usr/bin, but now systemd also wants /usr/bin and /usr/sbin to be merged.
My first thought is to wonder: why would systemd care about this then? Any idea?
My second thought is: with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? My understanding is that sbin has historically been useful to have statically linked binaries that can be made available early during boot without needing various lib dirs mounted. But that need seems obviated by a unified /usr…
Earlier quoted context omitted.
> As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine). My advise to you is to deny all support from people using the Debian version of your software and automatically close all bug tickets from Debian saying you don’t support externally patched software. You would be far from the first to do so and it’s a completely ratio…
I agree that maintainers should not be expected to support patched versions of their software, but as a user I like the Debian policies you call insane. I would actually pick Debian exactly because they are cautious with the dependencies.
I personally wouldn't use Debian but people are free to do whatever they want. I don't want to waste my time dealing with Debian maintainers and how they think software should work however. I advise all software developers to do the same and am vocal about it because it's easy to get guilt tripped in the idea that you should somehow support their users because they want to use your product or that introducing changes to support their esoteric targets somehow make sense because they have done the work despite the burden of futur support actually landing on you.
I want to make clear to people who decide they have no interest in it that they are not alone and it's perfectly fine.
And to be clear, I am singling Debian here because they are by far the worst offender when it comes to patching but the comment applies equaly to any distributions that apply invasive patches.
Earlier quoted context omitted.
> Why do you think this is an attempt at a persuasion tactic Because they said so: > As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration [1] 1. https://0pointer.de/blog/projects/the-biggest-myths.html
This was written 11 years before that debug log was added. Extremely loose connection. Things do actually change over the course of 11 years, believe it or not.
> it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so. [1]
> Distros may deviate from this by patching this downstream, but by shipping this as secure default I do hope to gently push everybody in the same direction.
> start pushing people gently to define GPT partition type UUIDs for missing archs > Let's generate a single gcc `#warning` message asking people to define partition type UUIDs for their architectures if they are missing. [3]
[1] https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
[2] https://lists.freedesktop.org/archives/systemd-devel/2011-Ma...
[3] https://github.com/systemd/systemd/commit/d42e4fa258701ff5e0...
Maybe a niche concern, but SDL2 is still in Trixie. The sdl2-compat layer (translating SDL2 APIs to SDL3) is in testing, where SDL2 also exists side-by-side with it and is intended to be used to test and verify that SDL2 apps that use it are actually compatible. Night-and-day decision-making process compared to Fedora and Arch, which both replaced SDL2 with sdl2-compat, broke a bunch of SDL2 apps because sdl2-compat…
Well Fedora is the equivalent of testing for Red Hat and Arch is Arch.
Earlier quoted context omitted.
Defaults matter a lot, snap is not open source (client is, backend isn't), you cannot "just modify it (Ubuntu)" to use a different store, because Ubuntu installs snaps even with apt. Mint is not part of the discussion.
> Mint is not part of the discussion. Read the parent comment I responded to
Earlier quoted context omitted.
Meh, it looks pretty in screenshots but it's a huge waste of screen space in the end.
I suppose 'power-users' can put up with 'small-button' GUIs but I do think a general purpose GUI needs to be easy to use for people who aren't used to controlling mice and keyboards all the time.