Re: Bits from the DPL (August 2019)
On dj., set. 19 2019, Jerome BENOIT wrote: On 19/09/2019 00:46, Sam Hartman wrote: Init System Diversity = So perhaps sysvinit and init scripts have had their chance and it is time to move on. We could move away from init scripts as the default representation. We could stop caring about sysvinit (which isn't quite the same thing but is related). That would leave non-linux ports in an unfortunate position. But right now there are no non-linux ports in the main archive. So perhaps we don't even care about that. Again, a change, but a change that we can ask ourselves if we are ready to make. This does not look as diversity. Otherwise I am very surprise that Devuan was not mention at all. May be it is time to work with the Devuan team and merge Devuan to Debian. As someone involved in Devuan: please don't pull it into this. Sam's *full* message, and not just the bit you quoted, is what *Debian* needs, which is what his current role asks for. Mark (elogind's developer) works closely with Devuan but in general over there, there is consensus that whatever changes are worth having in Debian should happen in Debian whenever possible, which is where it has the greatest impact, and that is what this is about: determining if it is possible and desirable for Debian that this particular bit *also* happens in Debian. And that truly has nothing to do with Devuan or what people think of it. -- Evilham
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On dv., set. 13 2019, Simon Richter wrote: Hi, On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote: > Note that by way of counterargument, Google and its services > have > been blocked in mainland China by the Great Firewall for > nearly a > decade now, so I question whether there is really such a > thing as > "too big to block." This is a false dichotomy: not all nation states are willing to go to the extreme lengths as China. Also, China cannot block Github, because they have no equivalent, and even if they did, it wouldn't have the same content. Google is too easily replicated, because they have no immediate contributors. I expect that China will set up a proxy service with clones of all relevant Github repositories soon to keep read-only access to free software around but inhibit organizing through shared documents. CloudFlare has too many services behind them that are important for the economy and not replicable, so they are in a better position than Github here. Also, this is a cat and mouse game and DoH is probably just the next step :encrypted SNI will probably be needed as well later. Mandatory Encrypted SNI with no fallback option -- everything else can be circumvented easily. This is a game that we should not play, really. It raises the cost of running a service on the Internet so only big players can afford to do so. We are throwing some ice cubes into the boiling pot so there are local zones that are warming up slow enough that the frogs there do not notice. This is a losing strategy. Simon There's also this: https://use-application-dns.net/ https://tools.ietf.org/html/draft-grover-add-policy-detection-00 The way I read it, it means that "soon" DoH would be enabled by default for "everyone" unless it can be trivially disabled by the network operator. Quite confusing, at least for me it'd look as having all the issues of centralising DNS (a couple kill-switches for de-facto global censorship) and then undoing all the benefits of using encrypted DNS in the first place. -- Evilham
Re: Please stop hating on sysvinit
On dv., ag. 09 2019, Vincent Bernat wrote: ❦ 9 août 2019 09:22 +02, Martin Steigerwald : Reality seems different. Almost nothing was using inetd (tftpd is the I note that you wrote "seems". But still: As if there would just be *one* reality. Actually there is. But I never saw any human being being able to express it in words. So I'd rather not. I believe it can be experienced at any time. But for me it is beyond words and so much else. With arguing about what reality might be and claiming it is this or such… the trouble starts. Cause then people who somehow dare to manage to experience a different reality can easily be made wrong. I think this has been one of the core issues around the conflicts regarding Systemd. How dare you see things different than me? But you just need to talk to ten people to recall a situation they experienced together and you will receive ten different story. Now: which one would be right? The one which provides real-world examples. One says "socket activation is not used for decades, let's just not use it", I say "it is used right now, see the following examples". You come and you say "I don't use it with dovecot". Sorry, but upstream did implement socket activation for a reason, not out of the blue of nothing. Not that it's too relevant, but most of this sub-thread already isn't: Socket activation was used in low end embedded devices running Debian, precisely as Simon described, already 10-15 years ago. Those devices just didn't have the RAM (32M!) to have the processes running all the time, but they could afford swapping and starting the services on-demand for shorts period of time. That one hasn't first-hand experienced (or noticed) certain things doesn't mean they were/are not there. In any case, and this bit *may* be relevant, but that's for each person to judge and my understanding / perception may be wrong: it'd look as if lately on this ML many technical topics derive in some bits of the Debian community pushing for "let's drop sysvinit" or (wrongly) claiming that "sysvinit is bit rotting and nobody is using it" and that in turn results in long discussions like this. My theory on this is: those that were very vocal against systemd in a non-constructive way moved away from Debian, those who were vocal *for alternatives* in a constructive way are trying to do what they can where they can (which is not always directly Debian); I perceive systemd-bashing to be mostly not a thing *here* (and that's good!); but it looks like this kind of threads, discussing details of wildly different use-cases for Debian or how "systemd can do X and Y can't > but you also can do it without it in a perceived simpler way" are more of a magnet for quick postings than those actually tackling issues, which usually have very good points and different perspectives. Basically: the Debian community has been able to make the change a big part of it wanted to make (adopting systemd by default), but that means the other bits of that process should also be respected. That is: sysvinit is supposed to be supported and that's not going to be always in the same way; sometimes that will require not blindly adopting systemd's upstream's way of doing things for everything, but talking things through and seeing what would be best for Debian as a whole, sometimes supporting other init's will be a bit of an after-thought, sometimes just having different init's be possible in the same OS it will help find hard-to-spot bugs. If that's accepted and respected, it's not a thing to argue about or waste brain-cycles in, in the meantime things are getting both calmer and better. -- Evilham
Re: Debian Buster release to partially drop non-systemd support
Dear debian-devel, Am 15/10/2018 um 15:20 schrieb Jonathan Dowland: > [ re-adding TG who requested CCs in an earlier message, but has not > set Mail-Followup-To:. You've probably missed half the conversation, > Thorsten… ] > > On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote: >> I believe Andreas Henriksson is right, the packages are going to be >> removed unless someone with time and interest show up to take care of >> them. A good start would be to split initscripts off from the sysvinit >> binary packages, to let them live separate lives. It will be sad, but >> the proper way for Debian to handle unmaintained packages in a sad >> state. > > Is it worth interested parties reaching out to the Devuan project > regarding person-power for sysvinit maintenance? As a derivative > distribution, I imagine their lives would become much harder if we did > drop sysvinit; they would have to pay the cost of maintaining the > sysvinit package themselves (which is what I am proposing they do now) > *as well* as a rapidly growing delta of sysvinit-support/initscripts in > lots of other packages, as they steadily rotted in Debian. it's my first time writing to this ML, which calls for a quick hello/intro and the FYI that I intended to send: The quick hello/intro: I go on the internet by Evilham and have been using Debian for ages. When it was time for me to give back to the community, systemd and Devuan were both already a thing, and things ended up bringing me to help Devuan first. The FYI: Devuan is not blind to this topic or reticent to contributing in Debian, the discussion is indeed taking place over at devuan-dev and, without having discussed it thoroughly yet, many are of the opinion that it *is* in everyone's best interest to keep the packages in Debian, and in a good state. https://lists.dyne.org/lurker/message/20181015.100838.2018520a.en.html At least personally speaking, there is interest in helping Debian from Devuan, as most of us see that there is big benefit in both distros. However, as you are aware, maintaining a distro is a lot of work (BTW: thank you all for your contribution to Debian), there have been priorities other than supervising state of packages in Debian. I don't think many were aware of the state of things and that this was the path these (very critical) packages were following in Debian. Where to now? At devuan-dev, Adam Sampson has suggested that the debian-bsd and debian-hurd communities are also very interested in keeping non-systemd things working, which is why I'd hope this won't end up in non-systemd support being dropped, but that this thread becomes the distress call that the topic needed. If I had to guess, this requires some organisation first, and since it may require cross-communities organisation it may be somewhat tricky. From Devuan's side, there is a weekly meeting happening on (UTC) Wednesday evening, where this will surely be a big topic. Just letting you know, things are moving (albeit somewhat late and slowly). Best regards, -- Evilham signature.asc Description: OpenPGP digital signature
