Hacker News new | past | comments | ask | show | jobs | submit login
Librem 5 Docs (puri.sm)
120 points by petethomas on April 11, 2018 | hide | past | favorite | 47 comments



I've always had an iPhone (since 3g) and recently picked up an Android phone for testing, and played with that. While I can't really complain about either phone, all I've really wanted is Linux on my phone.

This is the phone I want. The appeal of Linux on the phone is too much for me. As long as it can make and receive calls and somehow deal with SMS, I can take care of the rest.

I've entertained the idea of building a PiPhone [0] and trying it out for a few days.

[0] http://www.davidhunt.ie/piphone-a-raspberry-pi-based-smartph...


Linux on a phone (true Linux) is like my holy grail device. If it's able to seamlessly transition between a "desktop" mode when docked and a "phone" mode when not, even better. I have a Gemini PDA on order (dual boots Android and Linux) which is close but not quite there. Maybe 2019 will be the year of the Linux phone.


Yeah I sometimes really wonder where Ubuntu would have gotten if they'd held on for another year. And If they would have produced a simple but nice dock... But I guess you and me are part of a very small group. I feel I have that more often, I also loved my Pebble Time Steel and I'm still waiting for a good quality ARM notebook (with Dell XPS build quality but much cheaper) which could run Linux.


The problem with the ubuntu phone is that they built a special phone UI. None of the GUI desktop software ran and neither did software from any other OS. On top of that the battery life was awful.


I also think it's a pity that Canonical dropped the Ubuntu phone. Clearly, there was big interest in such a device.


Have you looked at postmarketOS, It's running alpine linux on existing android phones and in a few cases even running mainline linux.


Yeah, I think it's one of the more interesting "Linux on a phone" projects out there. The hardware differences between phone generations aren't as pronounced anymore. An OS that let's you run a device with updates for 5-10 years is a great idea.


Android is true Linux. The FSF wants people to use the term "GNU/Linux" for a reason.


The Nokia N900 was (is) already a Debian based GNU/Linux Phone.


Have you tried termux? It lets you run a shell on your phone (and even install and run various compilers).


Termux is awesome and a godsend to trivially shell out on android. But what I'd really want is boot to linux, choice of kernel and distribution, eventually pulling out an android layer on top of that if its UX is needed.

Basically an ARM(v8 64b) desktop-like experience in a phone sized chassis.


What makes this a non-starter is that normal linux applications are not written to be pre-emptable. Hence a default port of a linux system to a phone will kill the battery.

Hence the need for a from scratch effort where the SDK incorporates preemptability as a policy, and applications work off of that. Sadly, this means you cannot use the existing vast application ecosystem.

Librem is an effort in the above direction. It also seems like Fuschia is going this way.


> linux applications are not written to be pre-emptable.

I think I don't understand the way you're using this word.

Are you talking about wake-locks? Linux has opportunistic sleep/suspend and mechanisms for controlling that.


Closest I can explain is mobile applications have to be written to understand "pause" and "resume", and the application is running from "resume" to "pause".

Your typical linux application does not. It expects to be "started" and "stopped", and running the whole time in-between.


Linux processes can understand that already: SIGTSTP/SIGSTOP, and SIGCONT. There are many signals a Linux process can respond to.


I'm sure some adjustments will be necessary, but I'd actually like to fully stop mobile apps, desktop style, quite often.


Oh that, no. That should die with android, it's horribly difficult to understand and unhelpful.


Here's their blog post that provides some context around these documents: https://puri.sm/posts/librem5-progress-report-10/


I like that they have a head of documentation. Good documentation is so important for open source projects, but most projects don’t have it.


Postgres has never failed to amaze me in the documentation department. It is a refreshing exception to the rule.


And SQLite. And, on the more hip side, re-frame – Mike Thompson's writing has a personal, witty style.


While we’re highlighting quality examples, I’d like to call out the OpenBSD man pages for being superb.


I've been following the Librem. Interesting stuff.

I am a bit worried about this thing being very overpowered and just big. Like a huge screen and the works. But this is basically the same as every top-end Android + Apple phone?

I would love to see a real competitor to the iPhone SE. Not top of the line but very performant at its tasks. And 4 inches. Not sure if this can be achieved if everything is being designed for almost-phablets.


I own an Xperia X compact. They basically just killed what the line stands for with the newest models, but this phone is still pretty neat. Got mine for just about 250 Euros.

I think that's good competition to the SE.


While I'm very enthusiastic about the Librem 5, I think it would be better if they recommended a non-C language for app development. Gnome Builder, the IDE they recommend, has support for Vala, Rust, and Python, all of which should provide a much better developer experience, not to mention should enable more reliable apps.


Technically you can use any of those languages. It's just running their flavor to Debian (which runs today on their laptops).

I'm super excited for doing mobile app development in something that doesn't require Android's overly complex toolchains.


Less people know Vala than C, the Qt crate for Rust is some autogenerated thing that doesn't look very well-supported (not sure about GTK), and Python might not be the right choice for an embedded platform.

I'm fine with letting the platform mature a little before the scope of the project is broadened.


> Python might not be the right choice for an embedded platform.

I use micropython in several of my projects for CPUs that are waaaay less powered than the thing they're putting in the Librem5 and, despite not being a 100% feature full implementation of python, it's still a very capable platform. Granted, I don't drive any UIs (yet), but those components would be handled by some native libraries anyways on the Librem5, and the choice of python vs C would not matter from that respect.


But it's not micropyhon, you have many apps running on a phone and want them to be as efficient as possible.

From my experience with Vala (compiles to C) it would have been a much better choice.


GTK is re-writing bits in Rust, so it’s a pretty robust option overall. Lots of work left to do!


I only dabbled with Gtk-rs for a bit, and Rust does not really fit my UI/UX workflows, but I would still suggest as major improvement a better way to being able to reference struct fields from callbacks without the current Option<Rc<>> workarounds.


There are already some projects that let you do that, consider Relm for example: https://github.com/antoyo/relm/blob/master/examples/http/src...


Is Qt with Rust usable already, or it's still very experimental?


I don't have personal experience, but my understanding is that GTK is much easier since it's in C; QT makes use of some C++ features like inheritance that don't have a direct analogue in Rust that makes it hard. I've heard of several people doing things, but am not sure there's a particular go-to amazing solution at the moment.


The last time I looked into it, there was this project: https://phabricator.kde.org/source/rust-qt-binding-generator...

But it was in the prototype stage then.


I'm excited C is supported, creating a hello world app is a few lines in a main.c (http://www.levien.com/gimp/hello.html) file and calling GCC. That's immediately so much simpler than complete and utter mess that is android development.

As for rust, I'd prefer they get a stable ABI so my phone doesn't end up with statically compiled bloat.


I'm really glad they chose C-language for this, personally. The reason is, I've been solving the mobile dilemna for the last few years by focusing on one policy: Lua is the platform.

So as soon as I can access a Libre-phone, I'll put my favourite Lua-based engines on this thing, work out a toll-free-bridge for any of the nice OS things, and put all my apps on it as a target platform.

Just a matter of having the hardware.

(That said, there is absolutely no reason one could not do the same thing: use your language-of-choice, with a bridging layer. The use of C makes this a lot more tenable than, say, other systems languages.. at least in terms of tooling and methodology.)



I'd really like one of these but I don't foresee it being able to run Whatsapp, which all my friends and family use.



Convert them to Matrix. IMO, Whatsapp's privacy invasion has no place on this phone.


Can't all your friends and family also send and receive text message ? Apart from huge media file, there is not much difference.


There is an another big difference: groups


Isn't the point that we wouldn't need app vendors to present these things, if the OS were a little more intelligently exposed to the user, who is expected to own it and not just use it?

I think there is something about a "Linux phone" which makes apps like WhatsApp, and so on .. quite obsolete. These apps fix holes in iOS/Android - they extend the features of what should be, operating system functions.

I find it repugnant that I have, for example, ~15 apps that basically do the same thing, organized in a folder, and which I maintain as a common suite of messaging inboxes.

This, to me, indicates that the OS is not doing something it should be doing, intrinsically. Yes, it means eventually deleting all those competing protocols - and independently weak sources of dataleak - and putting it all back under the users control.

With a Linux-based phone/communications device, isn't it going to be the case that the open nature of Linux ecosystems is going to have that sort of effect? i.e. - the user really is in control of their machine, and thus their own personal data.

I predict that there will be an IPFS'ish revolution on Libre, when it gets out there, which will mean that the one place vendors should set up shop, is the ol' SMS gateway.

'ipfs pubsub sub fridaynightcrew && ipfs pubsub pub fridaynightcrew "wheres the party?"' is but a gateway from being accessible by existing users, of the aforementioned ~15 messaging apps ..


Fair enough. I forgot about this because I hate those so much. I mute all my groups on telegram/discord/slack and only go there when I'm pinged.


How is OpenGL support with Etnaviv progressing? For KWin to work, it will need some usable form. I wonder if anyone is planning to work on Vulkan support for it too.


OpenGL support is good now, and still seeing very active development.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: