Live data from Hacker News

FSF announces Librephone project

fsf.org

521–530 of 669 posts

Re: FSF announces Librephone project

#521
post #332
post #255

Earlier quoted context omitted.

Phones aren't x86, each is own snowflake, and on Android the nature of being a managed userspace, means there is a certain freedom regarding which ARM designs that Samsung, Qualcomm, Mediatek, and whatever else is out there comes up with. Then there is everything else that happens to be on the motherboard.

The camera is also surprisingly software dependent. Using the pixel camera vs using default configuration with an app called open camera, the difference is so clear. The camera is basically all software — the images are pure trash before processing.

Can you access the camera, though? I thought full access to the camera sensor was locked down only to awful Samsung apps?

Re: FSF announces Librephone project

#523

Earlier quoted context omitted.

Can you provide such an example? Because of bugs in the new version? A lot of the time old versions can still be loaded.

Just in the last couple of days: https://news.ycombinator.com/item?id=45568700 There are by now thousands of examples of this, I wonder why you would ask for an example, this is about as uncontroversial as the sun going up tomorrow.

The number of times that Linux distros, free software, has made my computer unusable, requiring me to manually fix it, is uncountable. Bugs from OS updates is still entirely possible even without updating firmware blobs.

Re: FSF announces Librephone project

#524

Earlier quoted context omitted.

> It was exactly "Open source" that enabled Google to dominate the smartphone landscape. The financial interest may have preferred a licensing model, but either way, it was the financial interest that actually built a ton of this software. Linux isn't unpopular with businesses because of its license model. It is healthy because it found ways to plug into financial interest. The FSF will always push licensing models w…

This is the one big flaw I've seen in Stallman's philosophy on software. He's been thoroughly proven right I think about the dangers of closed-source (unmodifiable) software to user freedom. But I think his insistence that Free Software also needs to be freely redistributable with no payment to the author in order to be Free has greatly limited the resources available to build such software. The FSF will argue "you c…

> It's not a viable business model.

> You can do it obviously, but it's effectively just a different way of soliciting donations at that point; the fair market value of the software is ~$0

It is a viable business model. At XWiki SAS¹, they do this for their "Pro apps" [1] which are paid extensions for XWiki targeted to businesses and that are free software (under the LGPLv2 license) with license checks.

Businesses won't bother removing the license checks, it's easy enough to pay, and far easier than donating.

It is not XWiki SAS's only business strategy nor the one that brings the most money, but still, that's not a possibility to discard too fast.

You can also find paid open source Android apps on the Play store, and people (individuals!) will totally pay for them even if you can have them for free from F-Droid, like OsmAnd+ [2] or Conversations [3].

[1] https://store.xwiki.com/

[2] https://osmand.net/

[3] https://conversations.im/

¹ I work for them

Re: FSF announces Librephone project

#525

Earlier quoted context omitted.

Just in the last couple of days: https://news.ycombinator.com/item?id=45568700 There are by now thousands of examples of this, I wonder why you would ask for an example, this is about as uncontroversial as the sun going up tomorrow.

The number of times that Linux distros, free software, has made my computer unusable, requiring me to manually fix it, is uncountable. Bugs from OS updates is still entirely possible even without updating firmware blobs.

To a driver whose car just died on I 405 in heavy traffic that is a distinction without a difference.

Re: FSF announces Librephone project

#526
post #515
post #509

Earlier quoted context omitted.

I see "... and permitting our official release signing keys" there, which means you are swapping Google Android for GrapheneOS Android, and you can't use bogwog Android if you wanted to. There is a list of apps banning GrapheneOS keys here, including govt apps, ticket apps, and McDonalds for some reason: https://grapheneos.org/articles/attestation-compatibility-gu...

> you are swapping Google Android for GrapheneOS Android No? You're adding support for Graphene's keys, not replacing Google's. Obviously, the main barrier is convincing developers of these apps to add support for Graphene's keys. However, this is only a problem for apps that opted to implement the Play Integrity API at all, which doesn't seem to be very common. All the recent monopoly rulings against Google may be d…

Android has a hardware attestation API that is compatible with GrapheneOS (if the app accepts GOS's keys), but nobody uses it. Everyone uses the Play Integrity API; GrapheneOS can't pass the "strong" (hardware-backed) level of Play Integrity, though it passes the weaker ones.

Re: FSF announces Librephone project

#527
post #350

Earlier quoted context omitted.

Either software is free or it isn't. You can't have single-vision-central control and freedom. Android is an example of an effort that took something free and made a usable mobile operating system ontop of it - but lead straight back to the problem that it isn't fully free.

Hm, there is also an option to avoid creating yet another fork the moment someone said something unpopular, or to try helping improve existing solutions instead of creating yet another cool project that achieves nothing. Of course no one can be forced to do so, but that's the problem - FOSS crowd would have to actually forced to cooperate, because otherwise petty dramas sabotage any common effort.

Graceful forking is different than .. what too often happens with keyboard warrioring.

Re: FSF announces Librephone project

#528

Ugh, I don't know. From a practical standpoint, I can see why basing on Android makes sense. But I really wish we can "somehow" extend an existing Linux distribution (or an Android kernel, even) with a user space reworked to function well on small screens. Maybe that's a pipe dream. What I'd really, really prefer is to be able to program the device with the same ease as developing a local Linux application. If I need…

i agree, except the web part. Purism did a lot of work to build Phosh, based on Gnome, with GTK apps that had fluid layout. on a phone-size screen, the UI was suited for touch; but connect it to a screen and everything seamlessly switches to a standard Gnome UI. i would rather see this get mainlined into Gnome, and for it to be common-practice to design desktop apps with a fluid layout that can adapt to phone screens…

I'm rooting for the web because it's all plain text technologies. And UIs live high up in the stack that one benefits from quick feedback, and also isn't forced to use a low-level language to develop them. But I suppose there can be language bindings from Python etc.

Re: FSF announces Librephone project

#529

Earlier quoted context omitted.

You're right about the drivers, but you don't need to reverse engineer them for Librem 5: They are already free. You only need to do it for the firmware, which AFAIK doesn't depend on the OS.

"Non-free driver blobs" in the librephone context means anything needed to drive the hardware. i.e. kernel drivers, HAL modules, firmware images, user-space vendor libs, etc. But sure, librem5 probably has most of that already.

> But sure, librem5 probably has most of that already.

So it would be less work and would benefit more operating systems to work on it. Yet the FSF chose another hardware - I don't understand why.

Re: FSF announces Librephone project

#530

Earlier quoted context omitted.

The listed distributions have already been created. The OP didn't suggest to create a distribution but to collaborate with existing ones not relying on the Google's OS.

Graphene and Lineage both rely on Google's OS, so this is not what the OP was saying.

Did you miss postmarketOS in the OP's post?
Post reply on HN