My vision for the future of Maemo Fremantle
 

There is an effort right now to produce a Devuan based OS that uses Maemo libraries (hildon and things for example) and can be run on various bits of hardware (with both the N900 and Neo900 being suggested as targets)

The idea of moving to a new OS base with modern kernel and libraries (ones that get fixes for any security flaws they may contain) is a good one but the way its being done by that team doesn't make sense.

I see the software stack for the N900 and Neo900 containing the following things going forward:
1.Replacements for old Maemo Fremantle packages taken from Devuan or elsewhere that are modern, up-to-date and still maintained and which are ABI compatible with Maemo
Fremantle/support the hardware we have in the N(eo)900 (or can be modified to be ABI compatible and support the hardware we have without a lot of work). So, newer kernel, newer libraries, things like that.

2.Replacements for Maemo packages that aren't a direct replacement but still do the same job. So, newer browser that isn't a direct clone of microb but still does what a browser for the N(eo)900 needs to do, new WiFi stack based on wpa_supplicant that replaces the old Maemo stack, things like that.

3.Existing maemo-specific FOSS packages (be they originally FOSS or be they cloned by someone) that are maintained and fixed (including security issues) going forward (this may include porting such packages to newer versions of various libraries). So, hildon stuff, status bar widgets, control panels, hardware daemons, things like that.

4.Older versions of FOSS libs that we need to keep around to keep existing binaries running. So, older openssl that we need for certain binaries, old browser engine that we might need for rtcom-mesasging-ui or nokia-maps, things like that.

5.Binary packages distributed by Nokia as part of Maemo Fremantle (where cloning those packages or otherwise replacing them just isn't an option or where we want that functionality in the short term but plan to replace it completly in the long term). So, cellular services daemon on N900, dialer app, messaging app, nokia maps, things like that.

and 6.Packages distributed by 3rd parties be they FOSS or otherwise that we want to be able to install and run as-is without needing to change them. So, things in extras-*, things on Garage, things on the forums, things like that.

Re: My vision for the future of Maemo Fremantle
 

Could you explain what exactly doesn't make sense and what is done differently to what you think it should be?

Re: My vision for the future of Maemo Fremantle
 

I was mostly talking about the armhf thing but FMG says there is no real reason the new work needs to use armhf at all and that switching to armel is trivial so that's sorted.

Re: My vision for the future of Maemo Fremantle
 

In regards to libraries on the N900, the libraries we have on the N900 fit into several categories:
1.Libraries where we have a newer modern maintained version that is ABI compatible with the Fremantle version (e.g. libc) or that can be modified/forked to be ABI compatible (e.g. I suspect GTK2 fits in this category)
2.Libraries specific to Maemo where we can keep the same ABI (e.g. hildon or e.g. various closed-source libraries we are keeping around)
3.Libraries where the version on Maemo is obsolete and there is a newer maintained version and its possible to have both libraries side-by-side on the one system (e.g. openssl)
4.Libraries where the version on Maemo is obsolete and there is a newer maintained version and its not possible to have both libraries side-by-side on the one system. (this should not happen since the Linux convention is that you bump up the library version and create a new .so file any time you do something that breaks the ABI)
and 5.Libraries that can/will go away because they are no longer needed due to changes elsewhere

Re: My vision for the future of Maemo Fremantle
 

Then please edit your comment, as it sounds impolite to the guys doing the really hard work for the last couple of months (if not more).

Re: My vision for the future of Maemo Fremantle
 

Why Devuan? What is wrong with Debian?

Re: My vision for the future of Maemo Fremantle
 

I guess not having Systemd is a good thing.

Re: My vision for the future of Maemo Fremantle
 

Yeah, that sounds like a much better base for me as well (bigger community, know track record, the actual origin of Freemantle, etc.). Also the Librem guys apparently want to choose Debian as well.

Re: My vision for the future of Maemo Fremantle
 

Do you have any concrete things in mind where using Systemd would be an issue ?

Systemd (and journal) has been used by Mer/Sailfish OS from day one and I really can't remember any Systemd specific problems during all those years.

Re: My vision for the future of Maemo Fremantle
 

Yes but the thing is, you want to be rid of systemd.
Take it from someone who's paid job is to work with systemd! :D :D

Re: My vision for the future of Maemo Fremantle
 

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.

Re: My vision for the future of Maemo Fremantle
 

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 :) .

Re: My vision for the future of Maemo Fremantle
 

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.

Re: My vision for the future of Maemo Fremantle
 

No offense wicket, i have no technical competence to estimate Lennarts technical or leadership skills and enjoy learning from your all posts, but
https://i.imgflip.com/1xtvzm.jpg

Re: My vision for the future of Maemo Fremantle
 

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.

Re: My vision for the future of Maemo Fremantle
 

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 ? :confused:

Re: My vision for the future of Maemo Fremantle
 

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? :confused:

Re: My vision for the future of Maemo Fremantle
 

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.

Re: My vision for the future of Maemo Fremantle
 

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.

Re: My vision for the future of Maemo Fremantle
 

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.

Re: My vision for the future of Maemo Fremantle
 

Personally I see systemd as a non issue. We are using upstart right now for compatibility/historical reasons, and until the startup stuff is untangled, we can definitely not switch to openrc or systemd. It also really should not matter much, it's a luxury problem. Let's first get hammering on the things that are essential. Same goes for devuan/debian. They are so similar that it shouldn't be hard to branch out in a specific direction down the road.

Re: My vision for the future of Maemo Fremantle
 

What I mean is that the specific packages in point 1 (e.g. libc, kernel etc etc etc) will come from Debian/Devuan and we will either point to the built .debs directly (if there are suitable .debs out there compiled with the options we need) or we will point to the source for those packages and have our build system pull that and build it.

For example, right now we are getting our libc from glibc version 2.5.1-1eglibc27+0m5+cssu3. This provides libc.so.6. On Debian Sid (as an example), the version of glibc is 2.24-17. This also provides libc.so.6. And because of the way backwards compatibility is generally handled with shared libraries on Linux systems we can use the newer libc.so.6 and still allow programs linked against the older libc.so.6 to run as-is. And if glibc then gets updated to some newer version, we just pull that in and use that instead.

In regards to the WiFi stack, the number of things that said stack exposes to the outside world via dbus, glib or otherwise and that are used by things outside of the WiFi stack is minimal (figuring out just what is exposed is on my todo list). I suspect it will mostly be some gconf keys under /system/osso/connectivity/IAP that will need to be in place.

Once we know that, we can easily rip the whole WiFi stack out and replace it with wpa_supplicant and other things instead.

In regards to the root CA store, the easiest solution there is to write a shim library that looks just like the one in maemo-security-certman but talks to whatever new way Debian/Devuan/etc uses for the root CA stores underneath. Modern packages that already talk to the root CA store with the new way will continue to do so, older FOSS packages that we are keeping (if any) get ported to use the new way and those binary packages we are keeping per point #5 in my original post will use the shim library (e.g. we will need the shim library if we dont clone and replace location-proxy)

Being API/ABI compatible with Fremantle is probably not going to be as hard as everyone thinks it will be assuming we intend to keep the whole Hildon UI and things (and if we don't then what's this whole project about?). I suspect the appropriate current version of many libraries will be ABI compatible when build with the right compiler options (armel etc) without any work required by us. (of course if Nokia forked these libraries and specifically changed their API/ABI, then that is an issue but even there we could very well be able to get away with a shallow patch set on top of upstream and just port that patch set every time we move to a new upstream version)

Points #1 and #2 from my initial post probably mean we can replace a lot of the core Maemo system with things straight from upstream somewhere. (e.g we dont need microb for web browsing anymore we just need some sort of modern up-to-date maintained browser that can run on our hardware)

Oh and in regards to the comment about idiots and extras-devel/cssu-devel, even really smart people who have been around long enough to know better sometimes screw up and install broken packages (at least its fairly easy to fix things when something does go wrong assuming you have enough battery power to get RescueOS to run :)

Re: My vision for the future of Maemo Fremantle
 

It still keeps core elements stuck in GTK2 though and that is my biggest issue for the future. XFCE is nearly all GTK3 now and even Mate has switched over. That being said, with GTK4 around the corner with GSK it won't be long till they switch again, although the changes required are a lot smaller.

I'm all for creating an updated version of Maemo 5 first. Gives a working base, identifies areas to be replaced that need maintaining ourselves, sorts out init structure as iirc it's a mess of scripts and upstart units at the moment. Update SDK and replace/ update scratchbox. What's the plan then?

Re: My vision for the future of Maemo Fremantle
 

Ho, I didn't explained myself correctly... Hamming distance is an abstract mathematical concept, not something you use directly. But it is the theory behind checksums.
And as said, I don't know how btrfs does the recovery in particular, only that this particular sentence was not that off from what I understood.
RAID is not directly related to Btrfs, as he answered a few messages later.
So it looks like to be too technical to be answered in a few messages, so I propose to close this and not hijack any more this thread :D.

Re: My vision for the future of Maemo Fremantle
 

Agreed, let's move on, however I feel I should point out that RAID is directly related because Btrfs is not only a file system but it is also a volume manager. Btrfs checksumming is used to detect errors but then it's the RAID method that does the error correction. The confusion here is whether or not the checksum itself is used for error correction as well as detection. I'd be surprised if the checksum is used for correction because, as we've already established, it can only repair trivial amounts of data. It seems almost pointless when we have other methods for correcting errors. If data integrity is important, use RAID. I'll shut up now. :o

Personally, I believe the only long-term solution is to build on top an existing base like Debian or Devuan. Most of the pieces of the puzzle are already in place to make this happen. Backporting packages to Fremantle is an endless task and I don't believe our community has the required manpower to do a good job of this. Take KRACK for example, how long will it be before someone ports wpa_supplicant to Fremantle and adds it to CSSU? In the meantime we all get pwned.

That said, the beauty of our community is that everyone is free to do their own thing. If someone for whatever reason doesn't like the idea of using a Debian/Devuan base and feels they can do a good job of backporting packages in the meantime, by all means go for it. The way I see it is that even if people are working in different directions, most of the work being done will be mutually beneficial for everyone in some way or other.

Re: My vision for the future of Maemo Fremantle
 

Sorry, I was referring to after we have a working, up to date Debian/Debian based system. Stick with what we have then, look at GTK upgrade or Qt switch, Wayland support, libhybris to support other devices. That kind of stuff.

I would like to have a roadmap in place with where we are, where we need to go next and what we plan to do after as the later helps in choosing how to approach each step.

Re: My vision for the future of Maemo Fremantle
 

I'm looking for a way to enable libhybris with X11 (Droid 4, OnePlus 2 and Moto Z Play as testing devices). Currently I can get 3D acceleration (https://github.com/NotKit/libhybris/...34fba8fcbaf69b), but screen output isn't very fast. Implementing Xorg DDX using hwcomposer API (see https://github.com/ssvb/xf86-video-fbturbo/issues/55) should make it more usable, in theory.

Re: My vision for the future of Maemo Fremantle
 

Really? Not one?

Re: My vision for the future of Maemo Fremantle
 

Hello Wizzup_! So I stumbled onto a little something you seem to be working on. ;)

Re: My vision for the future of Maemo Fremantle
 

I did quick and dirty xorg driver for hwcomposer, based on xf86-video dummy. It's not ideal, but works faster then fbdev on same device and no tearing with hildon-desktop
https://i.imgur.com/7z4aEr8.jpg

Re: My vision for the future of Maemo Fremantle
 

Seems to me that a backend that allows traditiional Linux graphics stuff (x, egl, whatever else desktops use these days) to run on top of graphics drivers meant for Android is a project a bunch of different mobile linux efforts would fund useful...

Re: My vision for the future of Maemo Fremantle
 

There is EGL/Wayland integration in libhybris, used by SailfishOS, Plasma Mobile, LuneOS, etc it's just that they don't use X server.

Re: My vision for the future of Maemo Fremantle
 

Seems like there are 2 things needed, one is an xorg ddx to do the same job as xserver-xorg-video-omapofb on the N900 and then some glue to link x and egl doing the same job as the wsegl dri2 blob on the N900 (a modern OS would presumably be using wayland and xwayland instead)

Re: My vision for the future of Maemo Fremantle
 

I am sure anything I say will be disregarded by systemd afficiandos but I still will open up about the issue.

As an end user you probably have no problems with systemd, it is just like any other init system to start up your computer so you can get to the point of using your thingy, whether it be a desktop, a phone, a television, a washing machine, a car or whatever.

However for a developer who is actually creating the end user experience these things are pretty important. My work pretty much falls between the phase when the kernel first stage loader starts and when the init process has fired up the final set of daemons setting up the box to behave like an user wants.

Now my gripes against systemd are because it tries to be too much! It contains duplicity of functions normally handled by trusty unix pieces, and hides the internals to try to smooth things up. But when you are building a system you want to be in control of how and when things happen, systemd gets in the way of that work.

Also journal is everything but optimized; there are severe problems with it and debugging those are real pain. It might sound like a good idea to integrate logging to the initializing system but take my word for it, it has caused considerable pain. (timing changes cause journal to mixup or miss lines, lots of writing blocks parts of the system for ages, races in places where it doesn't block, integrity failures in reboots and as the bloody piece is comprised of binary records! handling those when rotating logs takes *time*!...)

Re: My vision for the future of Maemo Fremantle
 

Can we stop arguing over whether systemd is good or bad and get back to charting the future of Maemo?

Re: My vision for the future of Maemo Fremantle
 

X and wayland on the same hw is like crossing the streams.
Either you have wayland + x support, or you only have x.
So how your wsegl dri2/whatnot should look like heavily depends on the way you take.

EDIT : one could wonder how it comes there's no wayland support in X..

Re: My vision for the future of Maemo Fremantle
 

At this point it would be better for all the targets (including N900) to standardise on a modern version of xorg. N900 would use xserver-xorg-video-fbdev ported to modern xorg along with the reverse engineered wsegl dri2 blob modified as necessary. (and maye be changed to use omapdrm later) Android targets could use a hwcompositor ddx plus appropriate egl glue. And so on
.

Re: My vision for the future of Maemo Fremantle
 

What is the wsegl dri2 blob? Some EGL implementation? In that case, any implementation should be able to replace it?

Re: My vision for the future of Maemo Fremantle
 

How exactly do you want to talk about the future of something and avoid talking about the merits of one of that something's potential future components? :D

Re: My vision for the future of Maemo Fremantle
 

I agree with @pichlo on at least this point wholeheartedly; Choosing the appropriate init system is of utmost importance to the project!