Devuan Beowulf 3.0.0 released
| From: | Mark Hindley <mark-AT-hindley.org.uk> | |
| To: | dng-AT-lists.dyne.org, devuan-dev-AT-lists.dyne.org | |
| Subject: | [DNG] Devuan Beowulf 3.0.0 released. | |
| Date: | Tue, 2 Jun 2020 18:30:50 +0100 | |
| Message-ID: | <20200602173050.GQ3124@hindley.org.uk> | |
| Archive-link: | Article |
Dear Friends and Software Freedom Lovers,
Devuan Developers are delighted to announce the release of Devuan Beowulf
3.0.0 as the project's new stable release. This is the result of many months
of painstaking work by the Team and detailed testing by the wider Devuan
community.
What's new in Beowulf 3.0.0?
* Based on Debian Buster (10.4) with Linux kernel 4.19.
* Support for ppc64el in addition to the existing i386, amd64, armel,
armhf and arm64 architectures.
* runit optional alternative /sbin/init.
* openrc optional alternative to sysv-rc service and runlevel
control.
* Standalone daemons (eudev, elogind) to replace aspects of
monolithic systemd.
* New boot, display manager and desktop themimg.
Installation and Documentation
Whether you are upgrading an existing Devuan install, migrating from Debian
or installing from scratch, instructions and guidance can be found at
https://devuan.org/os/install and https://devuan.org/get-devuan.
Packages[1], netboot images[2] and installation media[3] are available
through a resilient network of http package mirrors, http, https, ftp and
rsync iso mirrors, torrent and magnet.
Please take time to read the Release Notes[4]. They include important
configuration information and tips to help your install or upgrade go as
smoothly as possible.
Or, for the impatient, you can go straight to the package and sources.list
information: https://devuan.org/os/packages or the installation media
downloads: http://files.devuan.org/devuan_beowulf/
ARM Support
Bootable ARM images are provided by the Devuan ARM community.
You will find these resources useful for ARM-related discussion and
development:
* https://dev1galaxy.org/viewforum.php?id=24
* https://arm-files.devuan.org/
* #devuan-arm (Freenode)
Resources and Support
* Mailing list: https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
* IRC: #devuan #devuan-dev #devuan-arm (Freenode)
* Forum: https://dev1galaxy.org
* Press contact: freedom@devuan.org
* Source code: https://git.devuan.org
* Bug tracker: https://bugs.devuan.org
* Package information: https://pkginfo.devuan.org
* Popularity contest: https://popcon.devuan.org
After Beowulf
The next Devuan release, 4.0.0, is codenamed Chimaera. Repositories are
already available for the adventurous to test.
Appreciation
We wish to thank all of you for the incredible support given to Devuan.
Without your help and feedback, Devuan could not be the reliable and
versatile distribution that it is.
To support the Devuan project you can donate at:
https://devuan.org/donate (includes financial reports) or take up one
of the tasks listed at:
https://dev1galaxy.org/viewtopic.php?pid=1380#p1380
Live long and prosper!
The Devuan Development Team
References
1. https://devuan.org/os/packages
2.
https://devuan.org/get-devuan#installation-media-for-amd6...
3. https://devuan.org/get-devuan#iso-guide-for-i386-and-amd64
4. http://files.devuan.org/devuan_beowulf/Release_notes.txt
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Posted Jun 2, 2020 22:36 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (45 responses)
Posted Jun 2, 2020 23:21 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link]
Linux has never been entirely about what people need. In many cases, it's been about what people want to do or think it would be fun to do. I agree that trying to maintain a version of Debian that avoids systemd is a waste of time, but I'm sure other people feel the same way about my hobbies. Maintaining a forked distro is ultimately pretty harmless, and it's a far, far better way of spending one's time than starting endless arguments with the people over your particular hobby horse. If the Devuan people want to waste their time on something pointless, it's no skin off my nose; it's their time to waste as they see fit.
Posted Jun 2, 2020 23:25 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
(I'm done this sub-thread, by the way.)
Posted Jun 3, 2020 8:27 UTC (Wed)
by jrigg (guest, #30848)
[Link]
Nobody needs unnecessary negativity like this either.
Posted Jun 3, 2020 8:40 UTC (Wed)
by mbunkus (subscriber, #87248)
[Link]
Posted Jun 3, 2020 10:24 UTC (Wed)
by amacater (subscriber, #790)
[Link] (2 responses)
The arguments on Debian and Devuan mailing lists weren't pretty - but actually, folk from Debian and Devuan have found a way to work together to improve support for non-systemd within Debian as well. In the fullness of time, it will probably prove too much to continue Devuan on the number of maintainers they have for the one main issue they care about. Over time, it may be that more of the Linux ecosystem will require systemd. Over time, it may come to be that systemd is replaced by something else. Debian has been doing this for a long time - a couple of months longer than Red Hat, a month or two less than Slackware - that's geological epochs longer than most.
People do this Linux development thing for a whole heap of reasons, mostly not for bragging rights. Allow the Devuan folk to be happy in a major release - which they will have worked hard for - and don't disparage them for that. Nobody's forcing you to use it, but by being negative, it doesn't make the atmosphere better for anyone
Posted Jun 3, 2020 15:06 UTC (Wed)
by ale2018 (guest, #128727)
[Link] (1 responses)
Over time, it may be that Debian stop supporting sysV altogether. That would prove that continuing Devuan was worth all the way through.
Posted Jun 4, 2020 13:29 UTC (Thu)
by anselm (subscriber, #2796)
[Link]
If and when Debian ever stops supporting System-V init, chances are that 99% or more of Debian users won't even notice. Whether that will happen before or after the Devuan maintainers find something more fulfilling to do with their time is anybody's guess.
Posted Jun 3, 2020 10:28 UTC (Wed)
by oldtomas (guest, #72579)
[Link] (6 responses)
Not because of its content, but because of the reactions it elicited, which filled me with joy. That's the kind of world I want to live in.
Posted Jun 3, 2020 11:33 UTC (Wed)
by caliloo (subscriber, #50055)
[Link]
Posted Jun 3, 2020 14:08 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Jun 3, 2020 14:20 UTC (Wed)
by tekNico (subscriber, #22)
[Link]
Posted Jun 3, 2020 15:59 UTC (Wed)
by djs_tx (guest, #29646)
[Link]
Posted Jun 3, 2020 17:18 UTC (Wed)
by jrigg (guest, #30848)
[Link]
This is childish. Please stop.
Posted Jun 5, 2020 22:07 UTC (Fri)
by flussence (guest, #85566)
[Link]
Posted Jun 3, 2020 12:42 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link]
Also, these people's idea of a reasonable way to put together a reasonable Linux system is sufficiently odd so that everyone's better off if they are working on their own distro instead of endlessly arguing to get things their way elsewhere.
Posted Jun 3, 2020 14:22 UTC (Wed)
by tjc (guest, #137)
[Link]
Perhaps you would enjoy Phoronix more than LWN.
I don't need Devuan, but if MX Linux did not exist, I might. It's nice to have alternatives.
Posted Jun 3, 2020 17:04 UTC (Wed)
by jmclnx (guest, #72456)
[Link] (18 responses)
At one time Linux was used by people to "scratch an itch", and that was encouraged. Now many people seem to say "get on the systemd highway or you work is worthless".
People like systemd, others would rather not to use it, the projects that avoid systemd should not looked down upon or discouraged.
Posted Jun 3, 2020 17:07 UTC (Wed)
by jmclnx (guest, #72456)
[Link]
Posted Jun 3, 2020 19:38 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Of course, they are free to work on whatever they want. Good for them.
But. Given Devuan's entire raison d'etre is that "Systemd (and its progenitor) is not only worthless, but so incredibly awful that we can't even allow libsystemd to pollute our filesystems" (I'm paraphrasing; this is typically expressed with far more derogative vehemence) they are in no position to complain about how their own work is perceived. The public record is replete with examples.
Demanding respect from the very folks they're _still_ crapping all over is not likely to accomplish much, especially when one considers the sheer magnitude of effort expended versus what they have to show for it. Which, truth be told, isn't actually all that much. [1]
To that end, most of their work has been cleaning up their own messes, instead of actually maintaining the various bitrotten pre-systemd codebases (eg consolekit) whose general awfulness was a big part of why systemd was so widely adopted so quickly. Maintenance and testing is hard and unglamorous work, and could have _easily_ been accomplished under the existing Debian aegis, without all that fire and brimstone.
[1] Seriously, this is like someone bragging about digging a ditch using hand trowel instead of a shovel, because they don't like one of the people who helped make the shovel. Sure, it's an accomplishment of a sort, but not exactly one that tends to engender respect given that ditch diggers are paid by the cubic foot.
Posted Jun 3, 2020 22:38 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (15 responses)
That would be a fair point if Devuan actually did anything useful or even just interesting. That is to say, if it actually scratched anybody's legitimate itch. But it doesn't. It doesn't offer some alternative solution to the problems that systemd solves, like, say, GNU shepherd does, it just pretends those problems don't exist. That's of no use to anyone, hence my initial comment.
Posted Jun 4, 2020 2:17 UTC (Thu)
by sionescu (subscriber, #59410)
[Link] (2 responses)
Posted Jun 4, 2020 20:20 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Jun 5, 2020 6:02 UTC (Fri)
by diegor (subscriber, #1967)
[Link]
Honestly I don't see too much difference. And it's not like they are forcing you to use devuan.
Posted Jun 4, 2020 9:35 UTC (Thu)
by james (subscriber, #1325)
[Link] (11 responses)
It mostly stops systemd flamewars, which is worthwhile in itself.
Meanwhile, the rest of us can more-or-less pretend modern Linux systems without systemd don't exist, and Devuan can take on the costs and experience of working without it. They might even come up with a worthwhile alternative.
Posted Jun 4, 2020 18:16 UTC (Thu)
by ldearquer (guest, #137451)
[Link] (8 responses)
I always thought of this as a very real possibility.
Especially when building small embedded systems, it is really nice to have available alternatives which follow the "Do one thing..." approach
Posted Jun 4, 2020 20:15 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (1 responses)
If that were possible, it would have happened by now. No, these guys are just wasting everybody's time.
Posted Jun 4, 2020 21:03 UTC (Thu)
by corbet (editor, #1)
[Link]
I get tired of asking you to stop dumping on other peoples' work, but I'll do it again. Can you please stop?
Posted Jun 4, 2020 21:11 UTC (Thu)
by nivedita76 (subscriber, #121790)
[Link]
Posted Jun 4, 2020 21:13 UTC (Thu)
by jiiksteri (subscriber, #75247)
[Link] (4 responses)
I wonder how relevant the "small embedded systems" argument is these days, as the small embedded systems keep getting more and more powerful. And if you're really resource-constrained, you're likely better off with something that's neither systemd nor SysV init?
A more worrying scenario might be one where _applications_ start depending on systemd socket activation or somesuch, as that actually starts limiting your options.
Personally I don't really care which init system of the day gets thrown at me as my needs are simple enough to manage. But I don't really understand why anyone would act like the Devuan work is worthless or taking something away from them. Clearly it's worth the effort for someone, and everyone else gets to observe the experiment. How is that bad?
Posted Jun 5, 2020 7:37 UTC (Fri)
by HelloWorld (guest, #56129)
[Link]
> A more worrying scenario might be one where _applications_ start depending on systemd socket activation or somesuch, as that actually starts limiting your options.
Posted Jun 6, 2020 15:35 UTC (Sat)
by ldearquer (guest, #137451)
[Link] (2 responses)
It is not only about how powerful the system is, but about keeping the system as simple as possible for maintenance and auditing. For a serial login, ssh on a static ip, syslog and a custom service or two, we tend to use busybox init or a custom bash script to using something bigger. All I was saying is, under this approach, it is nice to have "do one thing" tools.
> And if you're really resource-constrained, you're likely better off with something that's neither systemd nor SysV init?
But I never said it has to be SysV ;)
Posted Jun 6, 2020 20:06 UTC (Sat)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Jun 6, 2020 21:29 UTC (Sat)
by ldearquer (guest, #137451)
[Link]
Posted Jun 4, 2020 20:13 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (1 responses)
So the reason we need Devuan is to stop the flame wars that its creators started?
Sorry, I'm still not impressed.
Posted Jun 4, 2020 21:14 UTC (Thu)
by amacater (subscriber, #790)
[Link]
Posted Jun 3, 2020 18:36 UTC (Wed)
by BirAdam (guest, #132170)
[Link] (5 responses)
Posted Jun 4, 2020 18:17 UTC (Thu)
by amarao (guest, #87073)
[Link] (4 responses)
Moreover, I can finally trust unit scripts (units). Sysv scripts were massive applications with hundreds of bash lines. Who again love to write and debug asynchronous parallel applications in bash, I forgot?
The systemd replaced simple underlaying mechanism with fatty complex one. But at the same time it replaced typeless 'garbage in garbage out' with rich and robust interface where errors are errors (not UB), and well-defined state machine you can reason about without executing it.
Posted Jun 5, 2020 8:59 UTC (Fri)
by bmorel (guest, #138892)
[Link] (3 responses)
* it is unfair to say the bourne bloat is sysVinit's fault. That mess is caused only by rc.d/init.d, which basically looks like some service manager built in a language that is prone to errors (yes, bourne shell). It is perfectly possible to have sysvinit running daemontools or runsvdir or other ones.
More on topic, I personally think it is sad that devuan sticks with the rc.d thing. Now, I understand that even Debian needed years to really switch toward systemd units, and with more manpower and more stuff worked on before by other distros.
I'm also planning to give it a new try, now that Debian includes runit-init as an alternative init system (the debian 10's init meta-package depends on either systemd-init, sysvinit or runit-init), because I'm tired to have to manually fix the errors when I try to install components that have a kilometer-wide cascading dependency that ends on systemd (got some examples there).
Posted Jun 5, 2020 12:26 UTC (Fri)
by pizza (subscriber, #46)
[Link]
I should point out that for all Devuan's rhetoric about "init freedom", nearly all of the (significant!) work to enable and integrate that choice in Debian (and thus, Devuan) was done from within Debian itself.
IMO Devuan's only real accomplishment has been to siphon off Debian's more toxic users and developers, giving Debian the breathing room to improve and evolve, and Devuan's proponents their own sandbox to strut around in. Win-win, I'd say.
Posted Jun 19, 2020 13:37 UTC (Fri)
by emorrp1 (guest, #99512)
[Link] (1 responses)
You just need to create a /usr/sbin/policy-rc.d script with `exit 101` if that's what you want (that's what docker uses too). It's only consulted by package management (see init-system-helpers) so won't interfere with whatever init enabling/starting config you have.
Posted Aug 4, 2020 4:08 UTC (Tue)
by bmorel (guest, #138892)
[Link]
Well, thanks for the pointer, it's *really* appreciated. Now to go rtfm and I'll get rid of that problem, nice!
Posted Jun 5, 2020 17:21 UTC (Fri)
by hiddenengine (subscriber, #87942)
[Link] (3 responses)
I was able to set them all up exactly the way that I needed with rc/init.d configurations, and it was a way that I was very familiar with, having worked with Linux since the 2.4 kernel days.
I completely recognise that for many, many people, systemd is a very nice solution. But for a small proportion of users, of which I am one, it makes some things much harder. For that reason, I don't want to have to run it, and I am extremely grateful that Devuan exists because it is based on Debian, which I've been using for many, many years.
I still have some Debian systems... and some Ubuntu systems... but some are running Devuan for the reasons above.
Posted Jun 5, 2020 17:32 UTC (Fri)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Like what?
Posted Jun 9, 2020 7:01 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Jun 11, 2020 16:08 UTC (Thu)
by surinameclubcard (guest, #139470)
[Link]
Posted Jun 8, 2020 16:56 UTC (Mon)
by dullfire (guest, #111432)
[Link]
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
[Disclaimer: I'm a Debian developer of long standing - I did read through all the arguments on the Debian mailing lists, I was sorry to see folks leave who decided that they could no longer work with Debian at the time. I used to maintain the Distributions HOWTO - so I'm fairly aware of how long distributions last and the exercise last month just confirmed this to me, sadly]
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan scratches my itch.
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
They are "wasting" their own time only. Leave them in peace.
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Exactly, see for instance
https://openwrt.org/docs/techref/procd
Yeah, so maybe the Devuan developers should support systemd-compatible socket activation. Needless to say, they don't.
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
* it is unfair to compare systemd to an init system or a service manager, for all of those components: systemd is more like a framework, which have both pros and cons. As a dev, I've learned that when you use a framework, and when you find that this framework, for any reason, does not fit your current goals and constraints, you must restart from scratch. Libraries, or "unix-philosophy-tools" allows to reduce the pain when such event happen, at the cost of higher initial cost.
* systemd is not the first and only one to provide cleaner ways to have async daemon starts. Daemon-tools provided that long ago, and since then there are several init systems based that embed such facilities, including runit (which is default if not only init choice of at least one distro: voidlinux) or nosh (which can converts systemd units to it's own things, it seems).
* I can write runit scripts in less than 5 lines, including shebang and some empty lines, without having to learn a language or syntax specific. I could also avoid starting the binary if dependencies where not yet up, even if yes, it does imply that pre-requisites are checked every time units.
* I can read the the code behind runit-init without much pain. This is not true for systemd.
I'm curious to see where devuan will go.
Needless to say, my system works well and is fast to boot with my current debian setup, which is neither based on sysvinit nor systemd, while now relying on debian's packages for the actual init (a change I appreciate a lot thanks to debian 10).
Well, if that fixes even a tiny bit my situation, that would be nice. I guess I would still have to manually disable the Debian's automatic enabling of daemons after any upgrade though.
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Also, dunno if this is documented (or where), but I have since found that in runit-init based debian will prefer runit daemons *if* the name is exactly the same as a the rc.d's one. This might help someone, someday (and avoid the comment to only say thanks).
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released
Devuan Beowulf 3.0.0 released