Re: My vision for the future of Maemo Fremantle
Quote:
|
Re: My vision for the future of Maemo Fremantle
Quote:
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
Quote:
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
Quote:
Quote:
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
Quote:
|
Re: My vision for the future of Maemo Fremantle
Quote:
|
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 |
All times are GMT. The time now is 17:58. |
vBulletin® Version 3.8.8