Reply
Thread Tools
Posts: 146 | Thanked: 1,615 times | Joined on Dec 2016
#21
Originally Posted by Venemo View Post
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.
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.
 

The Following 5 Users Say Thank You to Wizzup_ For This Useful Post:
Posts: 567 | Thanked: 2,965 times | Joined on Oct 2009
#22
Originally Posted by Wizzup_ View Post
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?
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
 

The Following User Says Thank You to jonwil For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#23
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?
 

The Following 5 Users Say Thank You to Android_808 For This Useful Post:
Posts: 339 | Thanked: 1,623 times | Joined on Oct 2013 @ France
#24
Originally Posted by wicket View Post
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.
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 .
 

The Following User Says Thank You to Zeta For This Useful Post:
wicket's Avatar
Posts: 634 | Thanked: 3,266 times | Joined on May 2010 @ Colombia
#25
Originally Posted by Zeta View Post
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 .
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.

Originally Posted by Android_808 View Post
What's the plan then?
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.
__________________
DebiaN900 - Native Debian on the N900. Deprecated in favour of Maemo Leste.

Maemo Leste for N950 and N9 (currently broken).
Devuan for N950 and N9.

Mobile devices with mainline Linux support - Help needed with documentation.

"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer
 

The Following 2 Users Say Thank You to wicket For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#26
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.
 

The Following 2 Users Say Thank You to Android_808 For This Useful Post:
Posts: 194 | Thanked: 1,167 times | Joined on May 2016
#27
Originally Posted by Android_808 View Post
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'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.
 

The Following 2 Users Say Thank You to TheKit For This Useful Post:
pichlo's Avatar
Posts: 6,445 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#28
Originally Posted by MartinK View Post
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.
Really? Not one?
__________________
Русский военный корабль, иди нахуй!
 

The Following 4 Users Say Thank You to pichlo For This Useful Post:
wicket's Avatar
Posts: 634 | Thanked: 3,266 times | Joined on May 2010 @ Colombia
#29
Hello Wizzup_! So I stumbled onto a little something you seem to be working on.
__________________
DebiaN900 - Native Debian on the N900. Deprecated in favour of Maemo Leste.

Maemo Leste for N950 and N9 (currently broken).
Devuan for N950 and N9.

Mobile devices with mainline Linux support - Help needed with documentation.

"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer
 

The Following User Says Thank You to wicket For This Useful Post:
Posts: 194 | Thanked: 1,167 times | Joined on May 2016
#30
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
 

The Following 8 Users Say Thank You to TheKit For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 08:43.