Well, my paid job is to work on the Anaconda installer (used by Fedora, RHEL, CentOS and other distros) as well as to maintain the Initial Setup post installation tool.

We both use Systemd and it's related functionality (such as Journal) in Anaconda (Anaconda & IS are started by Systemd units, both support logging to Journal, etc.), as well as support configuring it on the installed system (for example you can select which services should be enabled/disabled via kickstart).

We have certainly any apocalyptic scenarios, which is of course not saying Systemd is faultless - as any piece of non-trivial software there will be bugs, that need to be fixed.

We are also quite often in contact with Systemd maintainers - they seem to be pretty responsive and generally fix reported issues rather quickly. They even recently implemented an RFE that makes it possible for me to drop an impossible to maintain list of all possible console names & make Initial Setup startup much more robust.

So unless there are some specific confirmed issues preventing Systemd from being used in our environment, it seems to be a bit premature to select a distribution as a new base for Maemo just because it doesn't use Systemd.

Especially if the given distribution has a relatively small community compared to Debian, which, if the Purism Librem project is successful, might yet again be a part of mobile Linux effort.

There is more that no systemd in devuan that is valuable - devuan has images for couple of embedded devices (including N900), see http://neo900.files.dev-1.org/files....ssie/embedded/ . Also, it is very easy to create devuan bootable image for another embedded HW platform using arm-sdk - https://github.com/dyne/arm-sdk and that will help when and if Neo900 sees the light of the day. All this eases forward-porting by letting us focus on it, not side things.

Also, I haven't seen any interest in debian community about maemo, no matter how big that community is, unlike devuan community. If anybody has relations with that community, feel free to ask them if they want to help/support us.

However, what is done so far, is in no way tied to devuan. Devuan is maybe 99% identical (package wise) to debian, so switching to debian is a matter of setting up the needed repos. In theory .

For what it's worth, Debian used to be the Universal Operating System, they still claim to be, but I can't attest that claim. Debian still offer packages for System V init for those who don't want to use systemd so in theory it should be a supported configuration, but in practice it doesn't work very well. Many things are broken or don't work properly without systemd. They provide systemd-shim, but that really is a workaround rather than a proper fix.

At first I wasn't convinced that forking Debian was the right way forward and things really ought to be fixed in Debian. After seeing Debian's lackluster responses to related bugs to get these things fixed, I was convinced that there is a real need for Devuan. freemangordon is right in that if you need systemd, all you need to do is change the repos to use Debian's instead. As for Purism, they plan to upstream everything so when they arrive in Debian, they will also end up in Devuan, maybe with the exception of GNOME stuff that is dependent on systemd.

I don't want to turn this into a systemd debate, there are plenty of those around. I actually agree with the systemd folk that System V init is broken and needs to be replaced. systemd does solve real problems, but in my opinion it is not the right solution. My main gripes with it are architectural, and the hostility and technical incompetence of the lead developer.

No offense wicket, i have no technical competence to estimate Lennarts technical or leadership skills and enjoy learning from your all posts, but

Sorry, I didn't mean it as a judgment but as a partial explanation for why I don't have any confidence in his software products. To give you one example, if you have some idea of how parity checking works, you'll find his post here rather surprising. I could give you plenty more examples but as I said, I don't want to turn this into a systemd debate.

Surprising ?

Yeah btrfs can probably recover a lot more than a few bits (never looked at how it works), but what he is saying for "non trivial amount of errors", doesn't seem wrong, and is related to Hamming distance (https://en.wikipedia.org/wiki/Hamming_distance), and in particular things like this quote "Thus a code with minimum Hamming distance d between its codewords can detect at most d-1 errors and can correct ⌊(d-1)/2⌋ errors.".

Did I missed something obvious ?

I don't claim to know all the ins and outs of Btrfs and I was unaware it uses Hamming distance to detect errors. Thank you for enlightening me.

The basics of volume management are that checksuming is used to detect errors and then the data recovery depends on what type of RAID you have configured. In the case of RAID1, the data is corrected by copying it from a valid mirror disk. In the case of RAID5, the correct data is calculated using the parity check. This has absolutely nothing to do with the length of the checksum. Btrfs can rebuild your whole disk if it has to as long as there is sufficient redundancy in place.

Or am I missing something?

Perhaps I am not understanding what you mean (and I agree with the rest mostly), but this seems inverted to me - why would you take new bits and nail them onto the old base? Why not switch to a new base (e.g. devuan or debian) that is maintained by hundreds and add on top the (older) parts that you need? Do you have time to maintain all the old and outdated packages? Do we have a special team that takes care of critical security issues? Who are on top of all the security bugs that occur on a nearly daily basis? What will happen in the next five years, as the old base starts to rot even more because there's no maintenance?

Essentially, most of the good things from the FOSS community (lots of hands, constantly improving software, lots of people taking care of most of the things for you) are taken away with this approach, leaving the few that want to work on and with maemo with all the work they really shouldn't be doing?

A simple example would be the root CA store -- if we used a modern base, we would just get that kind of updates for free and you would not have to worry about it. And there's a lot of examples like that: the wpa2 issue right now for example. Or the endless backporting of fixes to openssl that is not even being maintained by upstream anymore.

Adding to that, I am not sure how easy it will be to ever extend to other devices if we stick with an old base. Many newer devices need a way newer X, drm, dri, etc.

But maybe I just misunderstood you.

For me, the only issue I have is maintaining a focus on ABI/ API compatibility is like creating Maemo 5.1 (I hate Chrome inspired inflated version numbers) and doesn't simplify maintenance based on the number of us left.

There's absolutely nothing wrong creating a 5.1 but remember some design principles are 8 years old or more. There are better ways to do things that remaining compatible prevents. As for existing source available projects, I would happily recompile as needed with an up to date toolchain and upload to a new repo instead of worrying about binary compatibility. Why? So that you had a clean repo structure (stable/testing/devel without unmaintained projects, without the #insert own word# idiots running extras-devel/cssu-devel and wondering why things break.

So Maemo was built by paid and unpaid Devs. We have a limited community left. My earlier experiments were to see what we could do to reduce workload. Fmg and myself looked at GtkModule so we could just maintain Hildon specifics and rely on upstream to handle GTK, didn't work out. Switching to wpa_supplicant stack would remove some work in the long run, but needs to have a compatible replacement interface for OLD APPS ONLY that would still be easier than maintaining the whole stack.

Systemd Vs Upstart = I don't mind as long as one isn't going to be a lock in. Systemd in some places requires more work (MCE in Sailfish sends signals to systemd to notify status). Systemd on the other hand is used by far more projects so is a much bigger community to maintain it. My early work used systemd as Mer did. fmg's work uses upstart as Maemo does.

All this focuses on the now problem. There's two immediate choices, ground up or update base, libraries, kernel etc. As stated elsewhere, the second will see results sooner (Fremantle-GTK2 project) and is now my preferred option. BUT, what's the plan from there?

If someone can fixed tracker / media player to correctly handle album artist and title separation I would be much happier. Too many messed up Greatest Hits.

I did not mean to start a debate here, but I must point out that I have heard a lof of emotional response and negativity towards systemd, but haven't heard of any concrete and relevant problem with it. Personally, I've been using it since 2010 (Fedora 15) and it was a smooth experience.