Jolla Phone Pre-Order

📝 Discussion Summary (Click to expand)

The discussion revolves around a new phone running SailfishOS and evokes several strong reactions and points of contention among the users.

Here are the three most prevalent themes:

1. Skepticism and Concern Regarding SailfishOS's Openness and Viability

Many users expressed reservations about the operating system, questioning how "Linux" it truly is, given proprietary components, and whether the platform has overcome past technical shortcomings or business failures. While some praise its Linux heritage and customization, others view its proprietary elements as a deal-breaker or point to its historical instability.

On Openness: > "The Linux phone that's more closed than Android, it's a hard sell for me." @cbolton > > "My one complaint with SailfishOS is that it's not fully FOSS. If it was I'd probably switch to it." @MarsIronPI
On Business/Reliability: > "They have a history of not shipping. They took my money for a tablet pre-order but never shipped anything. Didnt offer refunds either." @dman > > "Seems they still havent figured out a business model for their OS. Hardware at low volumes wont move ala kickstarter." @rzerowan

2. Strong Desire for Physical Keyboards (and subsequent debate on practicality)

Recalling the legacy of devices like the Nokia N900, a segment of users expressed interest in the phone if it featured a physical keyboard, suggesting that the target audience for a non-mainstream Linux OS overlaps with those preferring tactile input. Others argued the market for physical keyboards is too niche.

Desire for Keyboards: > "Add a keyboard, and you would have piqued my interest. I dont understand how ex-Nokia devs could have built a phone like the N900 and then just walked away from it for 15 years" @tetris11
Counterpoint on Practicality: > "Most people aren't willing to sacrifice half their screen real estate 100% of the time, or deal with a significantly thicker phone, just to get a physical keyboard. The market for that is very small." @rafram

3. Controversy Over the Lack of a Headphone Jack and Perceived "Fake" Privacy Features

The removal of the 3.5mm headphone jack was a major point of discussion, with some seeing it as an immediate disqualifier. This led to a related discussion about the new hardware's "privacy switch," which some users distrusted because it seemed to be software-controlled rather than a true hardware cut-off.

Headphone Jack Disappointment: > "Awesome, this has a user replaceable battery! Sadly I do see no headphone jack, so not an option for me. Did I miss it on the pictures?" @onli
Skepticism on Software Kill Switches: > "I don't think it is a good idea to call this a 'privacy switch', obviously it works in software and can't be trusted." @monerozcash > > "If it can be enabled in software, it can be disabled in software, and I don't trust software." @ajsnigrutin

🚀 Project Ideas

Hardware Kill Switch Provisioning Service

Summary

A service that allows users to provision or manage the functionality of physical kill switches (like those requested for Mic, Camera, GPS, etc.) on privacy-focused Linux phones (like the proposed Jolla successor or PinePhone).
Core value proposition: To deliver trust in software-controlled hardware features by providing auditable, user-controlled access to the underlying physical switching mechanism, moving beyond simple "software on/off" toggles.

Details

Key	Value
Target Audience	Privacy advocates, SailfishOS/postmarketOS users, hardware hackers who value true hardware disconnection.
Core Feature	A secure provisioning layer/daemon that translates user requests (via an API or GUI) into permanent, auditable configuration (e.g., flashing firmware/reading eFuses) that governs the external kill switch behaviors, or a tool to manage existing hardware switches like those on the PinePhone.
Tech Stack	Linux kernel module/udev rules, Rust/Go for the daemon, potentially specialized hardware flashing tools (if firmware alteration is needed). Focus on secure shell/local control.
Difficulty	Medium/High (Depends on the depth of interaction with the hardware's switching logic/firmware).
Monetization	Hobby

Notes

Directly addresses the skepticism around software-governed privacy switches: "If it can be enabled in software, it can be disabled in software, and I don't trust software." and "I want to KNOW that the function is off..."
If the new device has minimal/software switches, this product provides the necessary middleware to leverage existing hardware or build trust into the system architecture that they do disconnect power, addressing the security concerns mentioned by users like fsflover.

Keyboard App Compatibility Layer (KACL)

Summary

A compatibility layer/API shim designed to enhance physical keyboard input across applications, especially those primarily written for touchscreen-only mobile OSs (Android compatibility layer or native Linux applications).
Core value proposition: To bridge the gap between power-user demand for physical keyboards (N900 nostalgics, Linux users) and modern app design that ignores keyboard workflow standards.

Details

Key	Value
Target Audience	Users demanding physical keyboards (the vocal N900/SFOS power user segment), developers porting desktop-style applications to mobile Linux.
Core Feature	Intercepts standard key presses (e.g., Enter, Tab, Arrow keys) from a physical keyboard input source and maps them to appropriate touchscreen/UI actions (e.g., 'Enter' maps to the 'Send' button action in messaging apps).
Tech Stack	Python/C++ daemon using `libinput` or equivalent Linux input handling libraries, potentially targeting the Android AppSupport layer for compatibility with sideloaded apps.
Difficulty	Medium
Monetization	Hobby

Notes

Addresses the specific frustration noted by JoshTriplett: "What I would like is apps to pervasively support a keyboard. For instance, in most Android messaging apps, you can't even press "enter" to send a message..."
This satisfies the niche market segment who wants a keyboard but recognizes the trade-offs of size/thickness mentioned by rafram (i.e., they can use a pocket keyboard but need the software to accommodate it).

Cross-Distro SailfishOS/postmarketOS Web Engine Standardization Service (WESS)

Summary

A tool or service that allows users of alternative Linux mobile OSs (SailfishOS, postmarketOS) to easily select, switch, or migrate between mainline, actively maintained web browser engines (like modern Blink/WebKit) without relying on outdated forks (like legacy Gecko forks).
Core value proposition: Solves the long-term sustainability and performance issue plaguing mobile Linux UI components by ensuring web rendering remains modern and secure, independent of the OS vendor's specific resource limitations.

Details

Key	Value
Target Audience	Existing SailfishOS users (`colinstrickland`, `m4rtink` who noted Gecko issues), postmarketOS developers/users looking for better standardization.
Core Feature	A unified configuration/scripting system that pulls the latest stable rendering components (e.g., from Debian/Fedora repositories suitable for ARM) and binds them cleanly to the OS UI framework (Silica or Plasma Mobile). Includes necessary Android Compatibility Layer hooks if applicable.
Tech Stack	Shell scripting, Python for dependency resolution, strong focus on compatibility testing against modern web standards.
Difficulty	Medium
Monetization	Hobby

Notes

Directly tackles the architectural weakness identified by colinstrickland: "the native browser being an old firefox/gecko fork embedded into their own UI framework, giving a poor performance and dated compatibility quirks."
This leverages the Linux user's existing comfort with package management (zypper mentioned by d3Xt3r) to solve a core platform liability, making the phone more viable (as noted by aerique returning to Android due to legacy issues).