Difference between revisions of "Leste FAQ"

From Maemo Leste Wiki
Jump to navigationJump to search
(10 intermediate revisions by 2 users not shown)
Line 18: Line 18:


Fremantle is ancient, and quite a few packages are [https://wiki.maemo.org/Fremantle_closed_packages closed source] and also outdated.
Fremantle is ancient, and quite a few packages are [https://wiki.maemo.org/Fremantle_closed_packages closed source] and also outdated.
Many are in dire need of a replacement, either for interopability sake (browser, closed wifi stack, closed phone stack) or need a lot of updates to be even reasonably secure: ancient (vulnerable) browser, unsupported crypto libraries, ancient Linux kernel are just a few.
Many are in dire need of a replacement, either for interoperability sake (browser, closed wifi stack, closed phone stack) or need a lot of updates to be even reasonably secure: ancient (vulnerable) browser, unsupported crypto libraries, ancient Linux kernel are just a few.


Beyond that, Fremantle was never truly "Debian" -- although it used a lot of the debian ecosystem. We realise that we do not have the time to maintain all kinds of core packages, so it made a lot of sense to base Maemo Leste on a modern and community-run distribution. We can't run an entire distribution without a good base distribution like Debian.
Beyond that, Fremantle was never truly "Debian" -- although it used a lot of the Debian ecosystem. We realise that we do not have the time to maintain all kinds of core packages, so it made a lot of sense to base Maemo Leste on a modern and community-run distribution. We can't run an entire distribution without a good base distribution like Debian.


Furthermore, adding lots of updated and new packages mixed together with the old Fremantle packages is likely to become a big hell. Old packages need an older glibc (even though it claims to be backwards compatible, it isn't always), other libraries might depend on other specific libraries). That will also make it very hard to keep track of what old and new packages are in place, we would still be stuck with many other outdated packages - permanently frozen kernel interface, and so forth.
Furthermore, adding lots of updated and new packages mixed together with the old Fremantle packages is likely to become a big hell. Old packages need an older glibc (even though it claims to be backwards compatible, it isn't always), other libraries might depend on other specific libraries). That will also make it very hard to keep track of what old and new packages are in place, we would still be stuck with many other outdated packages - permanently frozen kernel interface, and so forth. This only gets more complicated with the new C++ ABI with newer GCC, and so on. We'd also ideally have all packages be Position Independent Executables (PIE), further complicating mixing with Fremantle.


We went for a distribution based on Debian because would provide a clean base; and Fremantle already used a large part of the Debian ecosystem. Right now it is very easy to figure out what packages Maemo Leste adds on top of Devuan/Debian, which also makes the life if developers (and even users) easier.
We went for a distribution based on Debian because it would provide a clean base; and Fremantle already used a large part of the Debian ecosystem. Right now it is very easy to figure out what packages Maemo Leste adds on top of Devuan/Debian, which also makes the life of developers (and even users) easier.


=== Does Maemo Leste use Halium? ===
=== Does Maemo Leste use Halium? ===
No.  Halium aims to build a common base for mobile GNU/Linux distributions.  This is great idea in principle but their choice of components leaves a lot to be desired. Mobile GNU/Linux distributions which use Android kernels will always be playing catch-up.  We will never see a new device developed from the ground up for those distributions as they rely on Android running on them firstThose distributions are at the mercy of the device manufacturers to provide kernel updates.  By embracing the use of Android kernels, Halium can provide a working device ports fairly quickly but this may have a negative effect in the long run.  A developer who has a fully working device running GNU/Linux with an Android kernel, may be less inclined to help get that device running on mainline Linux, thus the reliance on Android continues.  The shortage of mainline Linux kernel contributions from Halium and other libhybris-based Linux distributions is evident.
No.  Halium aims to build a common base for mobile GNU/Linux distributions.  This is great idea in principle but their choice of components leaves a lot to be desired.
Halium's choice of systemd is also contentious.  Whilst most mainstream Linux distributions have adopted systemd, it has left a significant number users discontented and unsatisfied, proving not to be the ''be all and end all'' solution it had hoped to be.
 
Halium uses Linux kernels from Android.  See [[#What.27s_wrong_with_Android_.28vendor.29_Linux_kernels.3F|below]] for a description of some of the problems of Android kernels.  By embracing the use of Android kernels, Halium can provide a working device ports fairly quickly but this may have a negative effect in the long run.  A developer who has a fully working device running GNU/Linux with an Android kernel, may be less inclined to help get that device running on mainline Linux, thus the reliance on Android continues.  The shortage of mainline Linux kernel contributions from the developers of Halium and other libhybris-based Linux distributions is evident.


=== What is mainline Linux? ===
=== What is mainline Linux? ===
Line 34: Line 35:


=== What's wrong with Android (vendor) Linux kernels? ===
=== What's wrong with Android (vendor) Linux kernels? ===
The Android Open Source Project (AOSP) leeches off Linux.  It makes little effort to contribute back to mainline Linux.  This not only hurts the Linux development ecosystem but we as users also suffer as a consequence of this.  There are thousands of different Android devices with kernels based on Linux on the market, yet only a handful of those devices run on mainline Linux, most of those with very limited hardware support.  Linux kernels are forked once by AOSP, and then forked again by the device manufacturer which results in kernels that have diverged significantly from mainline.  This means that it is not possible to install an up-to-date mainline kernel on any given Android device.  Also, it often means that kernel updates are not timely, nor frequent.  When the device manufacturer decides to stop supporting the device, no further kernel updates are provided.  This allow the manufacturers of Android devices to practise ''planned obsolescence''.  This practice is a huge contributor to our society's ''throw-away culture'' forcing consumers to replace their devices every year or two and has a big impact on our planet.  The vast majority of users of Android devices are not even made aware when their kernel has reached end-of-life leaving them vulnerable to known exploits.
The Android Open Source Project (AOSP) leeches off Linux.  It makes little effort to contribute back to mainline Linux.  This not only hurts the Linux development ecosystem but we as users also suffer as a consequence of this.  There are thousands of different Android devices with kernels based on Linux on the market, yet only a handful of those devices run on mainline Linux, most of those with very limited hardware support.  Linux kernels are forked once by AOSP, and then forked again by the device manufacturer which results in kernels that have diverged significantly from mainline.  This means that it is not possible to install an up-to-date mainline kernel on any given Android device.  Also, it often means that kernel updates are not timely, nor frequent.  When the device manufacturer decides to stop supporting the device, no further kernel updates are provided.  This allow the manufacturers of Android devices to practise ''planned obsolescence''.  This practice is a huge contributor to our society's ''throw-away culture'' forcing consumers to replace their devices every year or two and has a [https://www.fastcodesign.com/90165365/smartphones-are-wrecking-the-planet-faster-than-anyone-expected big impact on our planet].  The vast majority of users of Android devices are not even made aware when their kernel has reached end-of-life leaving them vulnerable to known exploits.


=== Why is it important to run mainline Linux? ===
=== Why is it important to run mainline Linux? ===
Line 45: Line 46:
Purism's PureOS is currently in development for the anticipated Librem phone.  Purism have stated their plans to upstream all work to parent projects.  This naturally presents another opportunity for collaboration, especially with PureOS also being based on Debian.  We look forward to any future collaborations, as well as a possible Maemo Leste port for Librem phone.
Purism's PureOS is currently in development for the anticipated Librem phone.  Purism have stated their plans to upstream all work to parent projects.  This naturally presents another opportunity for collaboration, especially with PureOS also being based on Debian.  We look forward to any future collaborations, as well as a possible Maemo Leste port for Librem phone.


=== How about other alternatives (Sailfish, Nemo, UBPorts, LuneOS, Tizen, etc)? ===
=== How about other alternatives (Sailfish, Nemo, Ubuntu Touch, LuneOS, Tizen, etc)? ===
* Android kernels (Sailfish, Nemo, UBPorts, LuneOS)
* Android kernels (Sailfish, Nemo, Ubuntu Touch, LuneOS)
* Unmaintained/vulnerable GPL v2 packages for the purpose of Tivoisation (Sailfish/Nemo)
** They prioritise device compatibility and ports over software freedoms
* Proprietary application framework (Silica components)
* Proprietary GUI (Sailfish)
* Built for profit which means they may not have the best interests of the end-user at heart, especially those which purposely include closed components where it could have been avoided (Sailfish/Tizen)
* Built for profit which means they may not have the best interests of the end-user at heart, especially those which purposely include closed components where it could have been avoided (Sailfish/Tizen)
* Mir (UBPorts)
** Proprietary application framework (Sailfish Silica components)
* Prioritise device compatibility and ports over software freedoms
** Proprietary GUI (Sailfish)
** Unmaintained/vulnerable GPL v2 packages for the purpose of Tivoisation (Sailfish/Nemo)
* Mir debacle (Ubuntu Touch)


=== Why is Maemo Leste based on Devuan rather than Debian? ===
=== Why is Maemo Leste based on Devuan rather than Debian? ===
Line 64: Line 65:


=== Are there any technical merits in using System V init with OpenRC instead of systemd? ===
=== Are there any technical merits in using System V init with OpenRC instead of systemd? ===
Not wanting to turn this into a systemd debate, [http://without-systemd.org there are already plenty of places on the internet where you can read up on the pros and cons of systemd].  Both init systems have their merits.  System V init with OpenRC does not provide as many features as systemd, but perhaps its main advantage is architectural.  Although traditional init is flawed in several aspects, we believe that its loose coupling of components help to provide better reliability, stability and security.
Not wanting to turn this into a systemd debate, there are already plenty of places on the internet where you can read up on the pros and cons of systemd.  Both init systems have their merits.  System V init with OpenRC does not provide as many features as systemd, but perhaps its main advantage is architectural.  Although traditional init is flawed in several aspects, we believe that its loose coupling of components help to provide better reliability, stability and security.


=== Does Maemo Leste have a process supervisor? ===
=== Does Maemo Leste have a process supervisor? ===

Revision as of 22:07, 4 June 2018

This page or section is a stub. Ask how you can help improve leste.maemo.org by visiting #maemo-leste, look at the bugtracker (https://github.com/maemo-leste/bugtracker) or if you are able to contribute to the current page, then you are welcome to do so.

What is Maemo Leste?

Maemo Leste is a GNU/Linux distribution aimed at mobile devices with touch screens: smartphones, tablets and PDAs. Maemo Leste is based on Devuan (and thus indirectly based on Debian), while it inherits a lot of packages from (the new very old) "Maemo Fremantle", the Nokia OS for the Nokia N900 internet tablet/phone. The mobile user interface is based on "Hildon" from Fremantle, as are various other packages (from Fremantle) -- some have been reversed engineered, others which were already open source have been updated to newer libraries and APIs.

Maemo Leste aims to provide an unconstrained and free mobile distribution for hackers, developers and even just casual users.

Why do we need another mobile operating system?

What Maemo Leste hopes to bring to the table is a streamlined but otherwise unrestrained mobile OS. User freedom and hackability of the devices, while still having a usable OS.

We aim to provide a "true" GNU/Linux experience by providing up to date packages, do not use vendor Linux kernels (only "vanilla").

Why not add/extend new packages to Fremantle instead?

Fremantle is ancient, and quite a few packages are closed source and also outdated. Many are in dire need of a replacement, either for interoperability sake (browser, closed wifi stack, closed phone stack) or need a lot of updates to be even reasonably secure: ancient (vulnerable) browser, unsupported crypto libraries, ancient Linux kernel are just a few.

Beyond that, Fremantle was never truly "Debian" -- although it used a lot of the Debian ecosystem. We realise that we do not have the time to maintain all kinds of core packages, so it made a lot of sense to base Maemo Leste on a modern and community-run distribution. We can't run an entire distribution without a good base distribution like Debian.

Furthermore, adding lots of updated and new packages mixed together with the old Fremantle packages is likely to become a big hell. Old packages need an older glibc (even though it claims to be backwards compatible, it isn't always), other libraries might depend on other specific libraries). That will also make it very hard to keep track of what old and new packages are in place, we would still be stuck with many other outdated packages - permanently frozen kernel interface, and so forth. This only gets more complicated with the new C++ ABI with newer GCC, and so on. We'd also ideally have all packages be Position Independent Executables (PIE), further complicating mixing with Fremantle.

We went for a distribution based on Debian because it would provide a clean base; and Fremantle already used a large part of the Debian ecosystem. Right now it is very easy to figure out what packages Maemo Leste adds on top of Devuan/Debian, which also makes the life of developers (and even users) easier.

Does Maemo Leste use Halium?

No. Halium aims to build a common base for mobile GNU/Linux distributions. This is great idea in principle but their choice of components leaves a lot to be desired.

Halium uses Linux kernels from Android. See below for a description of some of the problems of Android kernels. By embracing the use of Android kernels, Halium can provide a working device ports fairly quickly but this may have a negative effect in the long run. A developer who has a fully working device running GNU/Linux with an Android kernel, may be less inclined to help get that device running on mainline Linux, thus the reliance on Android continues. The shortage of mainline Linux kernel contributions from the developers of Halium and other libhybris-based Linux distributions is evident.

What is mainline Linux?

Mainline Linux is pure Linux, taken and built from Linus Torvalds' Git tree (kernel.org). It has an organic development model which provides new releases approximately every six weeks and also less frequent long term supported stable releases.

What's wrong with Android (vendor) Linux kernels?

The Android Open Source Project (AOSP) leeches off Linux. It makes little effort to contribute back to mainline Linux. This not only hurts the Linux development ecosystem but we as users also suffer as a consequence of this. There are thousands of different Android devices with kernels based on Linux on the market, yet only a handful of those devices run on mainline Linux, most of those with very limited hardware support. Linux kernels are forked once by AOSP, and then forked again by the device manufacturer which results in kernels that have diverged significantly from mainline. This means that it is not possible to install an up-to-date mainline kernel on any given Android device. Also, it often means that kernel updates are not timely, nor frequent. When the device manufacturer decides to stop supporting the device, no further kernel updates are provided. This allow the manufacturers of Android devices to practise planned obsolescence. This practice is a huge contributor to our society's throw-away culture forcing consumers to replace their devices every year or two and has a big impact on our planet. The vast majority of users of Android devices are not even made aware when their kernel has reached end-of-life leaving them vulnerable to known exploits.

Why is it important to run mainline Linux?

Using mainline Linux keeps us in touch with cutting-edge kernel development whilst also giving us the option of providing stable kernels. Mainline Linux does not suffer from any of the problems associated with Android kernels. Linux kernel development does not accept regressions and ensures kernel-to-userspace ABI stability meaning that once a device is supported, we can be sure that it will continue to work and will receive regular updates for decades to come, just like running Linux on your PC.

How does Maemo Leste compare with postmarketOS?

postmarketOS is mobile GNU/Linux distribution which runs Android kernels but also mainline Linux kernels. We share several goals in common with postmarketOS, particularly the use of mainline Linux. This presents a great opportunity for collaboration. Both Maemo Leste and postmarketOS have great working relationship and have already benefited from each other's work.

How does Maemo Leste compare with PureOS?

Purism's PureOS is currently in development for the anticipated Librem phone. Purism have stated their plans to upstream all work to parent projects. This naturally presents another opportunity for collaboration, especially with PureOS also being based on Debian. We look forward to any future collaborations, as well as a possible Maemo Leste port for Librem phone.

How about other alternatives (Sailfish, Nemo, Ubuntu Touch, LuneOS, Tizen, etc)?

  • Android kernels (Sailfish, Nemo, Ubuntu Touch, LuneOS)
    • They prioritise device compatibility and ports over software freedoms
  • Built for profit which means they may not have the best interests of the end-user at heart, especially those which purposely include closed components where it could have been avoided (Sailfish/Tizen)
    • Proprietary application framework (Sailfish Silica components)
    • Proprietary GUI (Sailfish)
    • Unmaintained/vulnerable GPL v2 packages for the purpose of Tivoisation (Sailfish/Nemo)
  • Mir debacle (Ubuntu Touch)

Why is Maemo Leste based on Devuan rather than Debian?

Convenience for developers, and a little bit of politics (but this is not really noticable in the project).

Fremantle used the (now abandoned) upstart init system. We initially chose Devuan because we figured Devuan might (and it does, afaik) support upstart to some degree as well, so we would not have to deal with rewriting the init scripts. But we ended up doing it anyway, and now Maemo Leste uses OpenRC. Another reason is that some people who initiated the project are either working on Devuan or are close with people who work on Devuan.

Although Debian can be installed without systemd, Devuan provides a much more stable and tested system in this regard. Key system components such as PolicyKit, UPower and udisks2 are broken in Debian when it is used without systemd, whereas Devuan provides working replacements.

Are there any technical merits in using System V init with OpenRC instead of systemd?

Not wanting to turn this into a systemd debate, there are already plenty of places on the internet where you can read up on the pros and cons of systemd. Both init systems have their merits. System V init with OpenRC does not provide as many features as systemd, but perhaps its main advantage is architectural. Although traditional init is flawed in several aspects, we believe that its loose coupling of components help to provide better reliability, stability and security.

Does Maemo Leste have a process supervisor?

Maemo Leste currently uses dsme from Fremantle which provides supervision over certain processes. It's possible that this may eventually be replaced with a modern process supervisor.

What devices does Maemo Leste work on?

Our currently list of (semi) supported devices can be found here: Category:Device

Maemo Leste could work on your device, and we'd like to link you to a porting guide here, but we don't have one yet.

Maemo Leste focuses on providing support for devices that can run on mainline Linux, with an emphasis on supporting mobile/cellular phones. There are a limited number of mobile phones supported by mainline Linux at present, all with varying degrees of hardware support. Although you may be disappointed by the lack of devices currently supported by Maemo Leste, we hope this will expand and we strongly believe that running on top of mainline Linux is the right way forward for building a mobile OS that respects software freedoms.

Maemo Leste has also been shown to run on the Gemini PDA which uses an Android kernel with libhybris. It should be possible to run Maemo Leste on other Android devices using this method, however this falls outside of the scope of this project and what we are trying to achieve, As such, only limited support would be provided.

Can I run an alternative desktop environment or window manager instead of Hildon?

The Devuan base of Maemo Leste provides a variety of desktop environments and window managers. There are some issues at the moment with running these whilst Hildon is installed, however it has been proven that it is possible to run them after making a few minor hacks. There are plans to make this process easier, however don't expect any alternatives to provide the same level of device integration and optimisation that Hildon provides.