Subscribe other folders then INBOX for checking for new mail?

while I can understand and also miss a little bit a self created folder structure and moving mails around, I have no clue why I should subscribe other folders than inbox for new mails. Maybe you can explain that. I'm honestly interested.

For example because you may read your emails on more than one device. And perhaps organize them into folders as you read them. Then you would like to have them synchronized on all devices.

Not to mention server side filtering directly sorting your new emails into folders when them come in.

So could zero phone be a good plan B?

https://www.zdnet.com/article/raspbe...wered-handset/

Which nowadays is entirely done from within the browser using standards (even the chatting part, using WebRTC, etc.)
Which means that, as long as you can get a browser that follows all the latest HTML/Javascript standards including bells and whistle, you should be fine.

Firefox (even the android version) tends to follow standards and more or less fills the bills (though newest latest HTML standards tend to be enabled first on the desktop).

On the other hand, even the Android version of Firefox supports extensions so you can get uBlock, PrivacyBadger, Decentraleyes, etc. even on Android.

If you watch closely, you'll notice that a lot of the popular Apps are actually stand alone wrapper (à la Electron) around web apps, that mostly use HTML standards (the "new" Skype is a nice example of that).

Bascially, the browser is the new OS.
So as long as you can get a decent web browser, you're not left alone.

Saddly, that's not the case of Sailfish whose native browser is showing age, at best. Luckily Firefox Android work.

The next blocker is CPU/RAM. Librem could very likely run a recent version of Firefox. BUT modern websites tend to be giant Katarmi balls of every single popular JS library used at the same time.
To the point that you need multiple core and GBs of memory, just to display the weather.



Which has nothing to do with the OS, and everything to do with the infrastructure used by the service.

(BTW, this actually works with youtube between a Linux desktop and a Sailfish smartphone, as long as they are all logged in with the same google account. Been there done that)

It's just so that the current only half-decent sever infrastructure for games on a portable device is the Google Play service, used *only* on official Android handset.
(So, on Sailfish, to sync games, you would need to use the Android compatibility layer, and you would need to manually install the Google services).

There isn't much else currently on the market (so even on Chinese Android handset, that use AOSP with a different (non-Google) set of services, it doesn't work. Nor on Amazon's own services)

Hypothetically, this could work if Steam services started to appear on ARM-class hardware (e.g.: for indie games on ultrabooks, chromebooks, etc)
Nothing technical would prevent that (in fact, Google enabling custom Linux chroots on ChromeOS could open the door to such a hypothetical easy-to-install "Steam chroot (based on bits of SteamOS)") for Chromebooks, directly from the official shop).
And Steam is definitely a platform that has enough gamedev attention to bring game-progress synching between portable devices on their platform.
But it's definitely not a Valve priority for now. Even more so attacking a new arch like AArch64. Even more so it that means head butting with Google on their own home turf (on Google Play Service's territory).

The Raspberry Zero is even more meager in term of CPU/RAM (it's still a first gen Broadcom CPU inside. It's not even ARMv7, but only ARMv6. It's single core CPU, with a very limited RAM - 512MB with no physical way to go beyond 1GB due to limited address pins).

I should be okay-ish for a feature-phone (think the new Nokia 3310), given its spec (think the same, but with a crappier screen).
But forget about running anything close to a "smartphone experience".
Android app compatibility is partically impossible.

*Maybe* running the pure WebApps-version of some apps that are planned for KaiOS could be possible.

Forget about games (I means, beside Frozen Bubble and other low-spec Linux classics).

Still, I think an open source & hardware feature phone has been in the real of possibility for quite a while already so it's surprising such project has not showed up earlier.

An open device possibly with some room for customization by custom lightweight software could be very welcome for people who carry current aging or low-quality feature phones, either because they don't want a smartphone or have the feature phone as another isolated device just for calling/SMS.

(I think some software customization, say by enabling/disabling modules at firmware build time, similar to for example Linux kernel build, should still be possible. This avoids the "feature phone curse" where due to the fixed phone software it is often hard to find the one feature phone in existence that happens to match what you actually want it to do.)

Also an open easily customizable device in the feature phone class device could find use in various projects where you need a lot of custom end user terminals or even simple SMS/data modems for machines.

I am in the possession of an OpenMoko Neo FreeRunner which begs to disagree with your Chronology ! :-D


But indeed this is a different class of hardware.

Up until recently, most of such project were "open" in the sense that the list of parts and the PCB schematics where available.
It still wasn't something that could be easily replicated despite openness.
(You would need to be able to source the chips, to produce the PCBs, to surface mount everything needed on it, etc. getting the first boot loading firmware flashed required special debug boards, etc.)

More recent project such as this Raspberry Pi phone, basically require easy to obtain and manipulate parts.

Spent an afternoon ordering stuff online, and then your young nephew should be able to assemble it: no SMD-soldering skill required, only being able to plug daughter boards into headers.

Looks like they are going to officially postpone the release date "slightly" (their words) in a big hardware update blog post tomorrow.

Hmmm... I guess I'm fine with that as long as they do not use the word "soon" in the post....