Cool, I was just thinking Sailfishos into a lapdock could be a cool combo, I know I’m asking for something quite niche but yeah, was just a general idea!
1 Like
Turbot, if you install Aurora Store, which is the pirate version of Google Play Store, use it anonimously. That works well.
1 Like
- Install F-Droid
- Search for Aurora Store in F-Droid and install it.
NewPipe is a Youtube clone without tracking that you can find in F-Droid.
3 Likes
1 and 2: Yes, that is quite normal for Sailfish users.
Apps from F-Droid are mostly open source, you can search on Github for details.
Openrepos is a reliable source but it needs some trust.
Aurora: a pirate store of Google Play that works through the account of the developer. Only free apps are available.
You can modify the rights of Android apps in Sailfish Settings under ‘apps’.
1 Like
You can also log in to aurora store to buy paid apps.
That I didn’t know. How? Can you buy apps in Google Play if you don’t have a Google account?
You can use google account in Aurora.
1 Like
not at all, aurora can login with an fake account but that one only allows to download free apps.
1 Like
No, you still need a google account, but you could for instance create an account just to buy that single app you want and pay via google gift card. That way google gets only few of your precious data
No thank you. It may be clear to new Sailfish users that we only can have paid apps in Aurora/Google Play if we create a Google account. The same with Vollaphone users.
To be precise: Apps must be licensed under an OSI-approved Open Source Software licence to be accepted at F-Droid, and a developer can only submit an app’s source code to F-Droid, the app is then compiled and packaged at (and by) F-Droid.
Exactly the same is true for the SailfishOS:Chum community repository and the licences it allows (see last bullet point of the SailfishOS:Chum FAQ).
6 Likes
Hello, Does anyone know the maximum size of SD card that the system supports?
There isn’t any. These limitations that you sometimes see are only really about file system, not actual size.
2 Likes
So the follow up question would be, what is the typical file system used for sd cards in SFOS - I guess that would be ext4; and what are its limitations.
Edit: The limitations of the size of ext4 systems seem to be rather theoretical for todays technology
For my brand new 256GB microSDXC card, Sailfish OS appears to have formatted it as exfat (or it came preformatted exfat). exfat has a maximum volume size of 128 PB. You won’t be hitting that limit though 
1 Like
Mine was formated by SFOS in X10 and is mounted by system like that:
/dev/mmcblk1 on /run/media/defaultuser/854788d8-1c33-4193-9cdc-e8a0364c55af type ext4 (rw,nosuid,nodev,relatime,seclabel,errors=remount-ro,uhelper=udisks2)
| Max volume size | 1 EiB |
|---|---|
| Max file size | 16-256 TiB (for 4-64 KiB block size) |
| Max no. of files | 4 billion (specified at filesystem creation time) |
As “the system” probably addresses the Operating System (i.e. SailfishOS / Linux), the correct answer is: The maximum filesystem size of the ext4 file-system, which currently is 1 EiB (one exabyte, i.e. 1024 * 1024 * terabytes).
Usual smartphones supports SD-cards up to 2 TiB (SDXC cards) for at least the past decade (the Jolla 1 from 2013 does), modern smartphones SDUC cards up to 128 TiB.
The file-system (and its capabilities) which is already on the SD card does not matter, as SailfishOS offers you to format a freshly inserted SD card with ext4.
3 Likes
These types of statements is what probably sparked the question in the first place. The difference between SDHC and SDXC is only really about what filesystem they come preformatted with. Despite this, pretty much everyone listed “SDHC only” as a “hardware” spec. Is there an actual (breaking) hardware change with SDUC?
Edit: also, they don’t exist yet, so won’t change the answer even if considering hardware.
Edit2: Sounds a lot like it will be a SW-only update. GPT vs MBR and some new commands. So once again unrelated to hardware, but this would probably take a kernel update.
No, not between SDHC, SDXC and SDUC cards, i.e. SD card specifications since version 2.0.
But there was a backward-incompatible change by redefining the card-specific data register (CSD register in the SD card) by the SD card specification 2.0 (versus v1.x, i.e. from SDSC to SDHC).
Sounds a lot like it will be a SW-only update. GPT vs MBR and some new commands.
Yes, on the host side the device driver for SD cards must support the new register layout for SDHC cards, though this change is rather analogue to the change in the ATA specifications (by the T13 committee) which altered the addressing scheme from CHS- to LBR-addressing in ATA harddisk-drives.
So, as long as solely the aspect “size” is addressed, “requires only software changes” is basically true for the host side and I assume the SD card association will adhere to this in the future. Consequently I shortened “smartphone hardware” twice to “smartphones” in my prior posting.
And while it is also true, that SD cards mimic an MMC card at startup (1 bit data at 20, later 25 / 26 MHz = 2,5 to 3,2 MiB/s), the host must command them into higher speed transfer modes, for some of which the electrical interface (i.e. the “physical layer (PHY)”) is radically different: 1,8 volts operation (originally 3,3 volts only) for UHS-I, -II and -III, LVDS (low voltage differential signalling) for UHS-II and -III which doubles the data pins from 4 to 8, and the SDexpress specification (introduced with SD card specification 7.0) which adds even more mandatory pins, redefines the pins for a PCIe physical layer and uses the NVMe protocol (i.e. an additional, completely different set of registers). All these features must be supported by the host hardware and software to utilise them.
Side note: I believe to remember (but am too lazy to look that up), that SDexpress cards do not need to support the original MMC mode (3.3 V, 20 MHz, 1 bit), but they must at least support UHS-I mode (1,8 V, 100 MHz, 4 bits). In the context of this discussion this would constitute a breaking hardware change, as most older host devices will probe an SD card in MMC mode (which then fails, but the host’s device driver does not retry in UHS-I mode) and very old host device hardware (>> 5 years) might not support UHS-I mode.
But imagine transferring the content of a 2 TB SDXC card via High Speed (HS) mode (3.3 V, 50 MHz, 4 bits), which may be the fastest mode an old host device designed for SDHC cards supports, i.e. with 25 MB/s: 2.000.000 / 25 s = 80.000 seconds = 22,2 hours. Hence it is not practically feasible to handle so much data on an SD card in an old device, IMO.
1 Like
Also where would you take from or put all this data