I like the self-built approach especially for the learning value.
If you’re using this in a CLI tool you’re writing in Python you might be using the library rich anyway, which provides this functionality as well including some extra features.
What I don't like about rich is that, dependencies and all, its installed size comes out to around 20 MB. 9 MB of that is due to its dependency on pygments for syntax highlighting, which a lot of people probably don't even want/need.
If anyone knows of a smaller, more focused library providing something similar to rich's Live Display functionality, I'd appreciate it.
There is an open issue [1] on GitHub to make it more modular and get rid of markdown and syntax highlighting but I have no hope for rich to get more minimal.
The fact that the EUPL is available in all the official languages of the Member States of the European Union is a very important aspect of the license for me. This means I could reasonably fight for the freedom of my software in the local courts available to me in my home country, which does not have English as an official language.
As the European Commission claims on their site, as one of the reasons they chose to create a new license instead of relying on those already available:
> The licence should have equal legal value in many languages.
In addition, the EUPL is not any license text some (from a legal perspective random) people came up with, but the text of the license was written and voted into law by the EU itself, therefore it can and does rightfully claim the following, which is invaluable to me as a FLOSS author residing in the EU.
> any litigation resulting from the interpretation of this License [...] will be subject to the jurisdiction of the Court of Justice of the European Union [...]
So even if the local courts interpretation in my home country falls short, the Court of Justice of the European Union will surely take into account the intended purpose of this license as laid out by the legislators of the EU.
I've never see that detail, that's incredibly insightful. Granted, for outside the EU it doesn't win much, but I'm guessing most reasonable places would defer to what the host country intended.
That being said, as another commenter pointed out, the "make available as service" language is a bit weaker in EUPL than AGPL.
The functionality exists in the author's implementation. If you search for 'is_draft' you'll come across the places in the code where this is implemented.
Unfortunately I noticed too late that the main domain does not automatically redirect to English based on the browser preferences. If someone can replace the link to add the /en/ at the end I would be super grateful.
OP here. I am not affiliated with this project. Some people have questioned whether the new domain belongs to the original project or not, so here is how I confirmed that they at least cooperate or belong to the same project team.
The older .info domain also referenced by the LTT video links to a Telegram group, whose owners now link to the new .io domain of this post.
As to why the old website does not reference the new domain directly, I have no idea.
As always with scripts that modify your system in fundamental ways, please take great care and do your own research.
In fact there are versions of Android that run on the PinePhone like GloDroid, but it's really not the goal.
The goal behind efforts like the Librem 5 or PinePhone is not to create yet another Android phone, which Open Source or not will strengthen the Duopoly of Google and Apple in the Mobile Phone Operating System market. The goal is to create hardware that can jump-start the development of a true GNU/Linux Mobile Operating System.
With its real world use case, it has brought great advances to Mobile "Desktop" Environments like Plasma Mobile or Phosh by motivating developers who could finally use their creations and improvements on a real phone.
Why is GNU important? toybox's coreutils is a good enough replacement. If you really wanted you could install GNU's core utils. 99% of users don't want to be messing with command line tools anyways.
Android already brought Linux as a mobile operating system to the mainstream.
Having the same OS on my laptop and phone is amazing. Android turns a general-purpose device into a restricted one, without a possibility to run desktop apps.
> Android turns a general-purpose device into a restricted one, without a possibility to run desktop apps.
You should not run desktop apps on a phone, because smartphone have much less power. This is an important design feature. This is why smartphones OS are built differently.
And even then, I don't see how android "restricts" things. It's software. Android does not "restrict". It's an OS.
> You should not run desktop apps on a phone, because smartphone have much less power.
You imply that having large power consumption is fine as long as the app is designed for desktop. I disagree: All apps should be as lightweight as possible to fight with the climate change and slow UI. I am using desktop Firefox on my Librem 5 just fine. All desktop plugins work, too.
> Android does not "restrict". It's an OS.
Android is designed in such a way that you cannot run desktop apps, despite the original Linux kernel.
> Android is designed in such a way that you cannot run desktop apps, despite the original Linux kernel.
What exactly do you mean by "desktop apps"? Of course it's not going to support KDE or GTK or QT or win32 or some other windowing API. But it's an OS, it can run software. And since it's open source, I don't see any reason why it would not run something.
Of course you would need to use the android API to do something, but it makes sense because it's a different OS.
It doesn't behave like a desktop OS, but as opposed to what, exactly? Desktop apps are a subset of software in general, desktop apps are not everything there is about software.
If you mean "I cannot run desktop apps because I need to redesign them so they can work on a phone", then yes, indeed, but a phone is not just "a small desktop".
Why not? It's a general-purpose computer, isn't it? Why intentionally design an OS in such a way that you must rewrite all software for it from scratch?
Yes, the UI is very different, but changing the UI is much easier than rewriting the program from scratch. Why is there no full Firefox on Android? It was already adapted for GNU/Linux phones and runs fine there, but not on Android. Same for LibreOffice AFAIK. Isn't it due to the design on this OS?
You don't have to rewrite everything from scratch, you can already use C++ or other languages, only the front end of software must be rewritten. And it's also possible to use other ways, like a graphics renderer or wrapper.
> Why not?
As I said, much less energy thus less processor cycles, much less L2 cache memory, no x86. The main reason it's entirely different is to force developers to make an app that doesn't drain battery, which is why it's very much different: it can do a single thing at a time, the software must be pause-able at any time, it can only run when the OS is okay with it, it can only animate in certain way, only use a very small subset of opengl capabilities, etc
The ways smartphones' OS work is a fundamental part of how it can save battery. It is painful for developers so that in the end, batteries last longer. Desktop software is millions years away from being energy-efficient, most of desktop or server software is generally ruled by the law of Wirth: "software is getting slower more rapidly than hardware is becoming faster."
Of course it's a big constraint of how developers can make their software work, but they don't need to rewrite "everything", they just have to adapt.
> Android turns a general-purpose device into a restricted one
Android still runs the Linux kernel and the only reason you can't have shell access on it is user-hostile restrictions, which an open-source build wouldn't have.
I think it would be a lot easier to add desktop apps capability to Android for the minority that actually wants to run Linux apps on their phone than building a touch-optimized userspace from scratch.
If your desire is to run Linux desktop apps on Android I bet you can already do it if you find an X Server APK and got your Linux app to use it as your X display - that would've been a quick, pragmatic solution to satisfy the "Linux desktop" requirement while taking advantage of Android's mature & battle-tested touch-optimised userspace.
It's the minority, because people didn't realize yet how convenient and logical it is. There should be no difference between a phone and a desktop, except for the screen size. You don't need to develop independent apps. You don't need to learn independent tools.
That's kind of irrelevant because they are currently developing a lot of apps to replace the functionality they'd get in Android for free. They'd save an insane amount of time and actually deliver a product competitive with mainstream phones right now, which would give them funding & marketshare to continue refining it down the line (potentially replacing it with non-Android components one at a time).
> There should be no difference between a phone and a desktop, except for the screen size
And the input method, which is a massive difference - touch and mouse are completely different, and so are the contexts in which phone vs desktop apps are used. If you try to merge the two, you'd look like the idiots who gave us Windows 8. So there's still effort in making specific UIs for different mediums.
> I can connect a screen and keyboard to my phone and use it as desktop
I'm not sure there's an actual need for it? This has even been tried by large companies such as Samsung and Microsoft and didn't go anywhere - in practice this isn't a problem the vast majority of people has and seems like an absurd thing to start with for a resource-constrained company in a very competitive market.
> That's kind of irrelevant because they are currently developing a lot of apps to replace the functionality they'd get in Android for free.
This is not true. They are stuck with hardware-specific things like power management, camera, and LTE calls. "Calls" application itself was developed very quickly, for example.
I think my point still stands if you replace "apps" with "functionality" - they're still reimplementing from scratch and without much resources nor expertise something that Android has a (correct me if I'm wrong) permissively-licensed, mature & battle-tested implementation of they could just use.
I don't think using permissively-licensed Android components wouldn't compromise user freedom and would actually increase it because it would put a non-user-hostile, freedom-respecting, usable phone in the market right now. You can just patch out or choose to not include the user-hostile bits (though most of those wouldn't be part of the open-source release in the first place).
Of course, this only applies if the objective is to deliver a usable, competitive product rather than practice effectively useless ideological bikeshedding similar to the war on systemd and refuse the admit that the typical GNU/Linux userspace is at this point prehistoric and significantly lacking compared to other alternatives (whether proprietary or open-source such as Android).
