The rules still require that local authorities designate suitable areas for building wind farms before an application can be made.

That sounds fine, except that it requires the planning departments to do something, and they are underfunded and overworked, so it's unlikely to happen.

That makes the prospect of building windfarms deeply uncertain, which makes it difficult for those that want to build them to raise funds, which means that they're less likely to start the lengthy application process, with the end result that no more windfarms are likely to be built as a result of this change.

So what is the reason for the change?

It seems that it's solely aimed at stopping a government rebellion

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fjoinpeertube.org%2F

Free Software, self-hostable, and uses peer-to-peer between viewers, so scales with popularity.

Originally SPI was created because Debian doesn't really have a legal existence in its own right. (In many ways it's just a bunch of mailing lists, and the contents of some servers etc. so it doesn't get to do things like open a bank account).

SPI could easily have been called something like The Debian Foundation, but rather than having something that was exclusively for Debian, it made more sense to allow other Free Software projects to also take advantage of the admin services it offers.

That being the case, you're right that Debian itself doesn't have any money, largely becaase it's not the sort of thing that can own things.
There are however funds held on its behalf by several Trusted Organisations, of which SPI is one.

Since Framasoft is based in France, the donation was paid from funds held by Debian France.

Since Debian folk hold quite a lot of small, local events, this _will_ directly benefit people within Debian (especially in times of Covid-19) -- the idea was greeted with overwhelming support from within Debian.

Debian doesn't actually have that many things to spend money on, and despite not really soliciting donations, generally accumulates more than we spend year on year. A lot of the things you might expect Debian to spend money on get donated, and thus cost us nothing, and end up being something where spending money in that area runs the risk of upsetting our existing sponsors (since we'd likely be paying their competition for something they are currently donating to us) and thus doing so might actually result in reducing the relevant resource available to the project.

In short, your assumptions about how Debian works are faulty. Hardly surpriing though really: Debian is clearly impossible ;-)

In fact, it wasn't very hard to imagine then, and it's even less hard now that we've had 6 years to find out what happend next.

Astonishingly, the people you seem to think were going to cause Debian's iminent destruction are still around, and Debian is too.

Bruce,

OK, so that's fair enough, but is there any real reason for Devuan to behave as anything other than a normal Debian derivative?

When they were trying to "eradicate every last work by Mr. Pottering", including libsystemd0, that wasn't going to work, since Debian doesn't really have a workable way to have two versions of the same package, differently linked (well, not without an explosion of foo-without-libsystemd packages, which wasn't going to get past the ftpmasters).

Now that they seem to have rowed back a little from that position, it seems like the main thing is the maintenance of alternative packages, and the testing of the coherent whole, both of which could be pushed upstream to some extent.

If all the packages could be pushed upstream, then Devuan might even be able to be a Debian Blend, or perhaps even a Debian Pure Blend, which would then allow them to release in a timely manner. Even without that, I'm sure that there are Debian users that would appreciate the option of using the main components like eudev.

Looking for evidence of attempts to package eudev for Debian, this is about it as far as I can see:

    https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bi...
and
    https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Flists.debian.org%2Fdebia...

neither of which have gone anywhere since.

Given that the packages now exist, it ought to be pretty trivial to upload them to Debian. That is likely to attract more people to use them, resulting in more effort being available to keep them maintained in future, so everyone wins.

If there's some reason that they cannot be uploaded to Debian in their current state, then it would be helpful to have the ITP ( https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwiki.debian.org%2FITP ) in the BTS ( https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwiki.debian.org%2FBTS ), with blockers being described, providing somewhere to discuss how to address that situation.

Cheers, Phil.

Hi Bruce,

Are you under the impression that Debian does not offer a choice of inits?

If so, you are mistaken.

If you think that you'd have been better off with some other init, why did you not just install another init?

I think it's a bit of a shame that so many people interpret the existence of Devuan as an assertion that Debian has somehow forced systemd upon our users, whereas in fact a lot of effort has been spent on making sure that systemd is just a default that can be easily overridden by installing an alternative init. This is particularly unjust because most of the effort required was provided by the maintainers of the systemd package, so they did the work to allow people to use other inits, which was pretty selfless of them, and meanwhile they get all the grief from people complaining (wrongly) about being forced to use systemd.

Cheers, Phil.

Hi Bruce,

Nice to see that you're still taking an interest in Debian ;-)

Perhaps you can explain why you favour Devuan over simply running Debian with the init of your choice installed.

The reason that I ask is that (prompted by a comment down the thread) I just tried out the live version of Devuan ASCII, and I see that is is true that Devuan now includes libsystemd0.

While I personally see nothing wrong with that, I've gained the strong impression that the fundamental reason for setting up Devuan in the first place was to avoid including that library.

If one is motivated to avoid every scrap of systemd, then I don't see how Devuan can now be considered satisfactory.

If on the other hand one is willing to accept having libsystemd0 (so that programs can sensibly accommodate running on systems with and without systemd) then I'm wondering what is supposed to be better about using Devuan than simply using Debian having selected one of the several alternative inits.

Is this about bugs that are being left unjustifiably unfixed in Debian?

If that's the case, and there are reasonable bugs that are being ignored, then I'm confident that the Technical Committee would give such cases a sympathetic hearing (and I say that as a current member of the committee).

Cheers, Phil.

Debian doesn't enable systemd-resolved by default, so they didn't even need to look at a manual to avoid that one.

if I have a problem with e.g. my dovecot instance on a server, with rsyslogd (as default installed on Debian) I get the fun of guessing which of mail.log, mail.info, or mail.err contains the messages I might like to see (with the mild suspicion that I ought to also glance at debug.log as well, just in case), then if I like to see things in chronological order I have the added amusment of running a command line like this:

    zcat $(ls -tr /var/log/mail.log.*.gz) | cat /var/log/mail.log - | grep dovecot | grep $whatever_I_really_wanted_to_see

and I'll get most of what I'm looking for, along with anything else that contains the word dovecot.

[BTW hands up anyone that thinks a gzip file is a text file]

whereas with systemd it's just so bloody tedious:

    journalctl -u dovecot | grep $whatever_I_really_wanted_to_see

Where's the fun in that?

Intel do have lawyers, and free software folk that understand licensing.

I'm sure they are capable of working out that all they need to do to be in compliance is to include the copyright notice somewhere in the binary blob that is ME.

Has anyone actually been in a position to check if they did that or not?

If not, I suspect that this is a non-story.

Also, even if AST were upset enough to sue (which does not appear to be the case), I don't suppose it would cost much to shut him up.

Are there any other copyright holders with standing here? (Minix used to be a one-person thing, but perhaps he's been accepting diverse contributions since relaxing the license). Even so, if they did include some sort of copyright notice, there's nothing for other copyright holders to say either.

The summary misleadingly opens with "systemd, the init system", whereas what we're talking about is "systemd-resolved, a part of the SystemD project" (or some such -- I'm a bit vague about the capitalisation TBH).

Anyway, the point is that this bug is not in the init code.

On Debian, we don't even execute this code by default.

So, if you see red and start screaming whenever you see the sequence of characters: s y s t e m d then I'm sorry if you're still reading this, but perhaps you should consider calming down long enough to notice that systemd is both the name of the init program, and the project that also includes a lot of other bits and pieces that are not even needed quite often, and can generally be run without having systemd running as init.

tmux is bigger from what I remember (if you include all the libraries it pulls in that are not already present in Debian Installer).

Also, screen gives you the ability to talk to serial ports, which might be quite useful for embedded use, which is one of the primary use-cases for this (since that is a time where you're talking to the installer over a serial/ssh connection and therefore don't have access to multiple virtual terminals)

If you're already a user of such software, and prefer tmux (as I do too), then using screen for d-i means you can simply type Ctrl-A, rather than needing to escape Ctrl-B to deal with nested tmuxs.