Aside in 2022-05-22. it's not the same.. but there is a renewed push by Pebble creator Eric Migicovsky to show demand for a SmallAndroidPhone. It's currently at about 29,000.
Update 2022-02-26: Only got 12 responses which likely means there isn't that much demand for this product at this time (or it wasn't interesting enough to spread). Here are the results as promised:
What's the most you would be willing to spend on this? 7 - $200, 4 - $400. But that doesn't quite capture it. Some wanted even cheaper than $200 (which isn't doable) and others were will to spend a lot more.
Of the priority's that got at least 2 people agreeing (ignoring rating): 4 - Openness of components, Software Investments 3 - Better Modem, Headphone Jack, Cheaper Price 2 - Convergence Capable, Color eInk, Replaceable Battery
I'd guess about half of the respondents would likely be happy with a PinePhone (Pro) that got better battery life and "Just Works".
Would you be interested in crowdfunding a small E Ink Open Phone? If yes, check out the specs and fill out the form below.
If I get 1000 interested people, I'll approach manufacturers. I plan to share the results publicly in either case. I will never share your information with manufacturers but contact you by email if this goes forward.
- Small sized for 2021 (somewhere between 4.5 - 5.2 inches)
- E Ink screen (Maybe Color) - battery life over playing videos/games
- To be shipped with one of the main Linux phone OSes (Manjaro with KDE Plasma, etc).
- Low to moderate hardware specs
- Likely >6 months from purchase to getting device
Minimum goal specs (we might be able to do much better than these, but again might not):
- 4 Core
- 32 GB Storage
- USB Type-C (Not necessarily display out capable)
- ~8 MP Front camera
- GSM Modem (US)
- Only open source apps pre-installed
- Phone calls
- View websites / webapps including at least 1 rideshare/taxi service working (may not be official)
- 2 day battery life (during "normal" usage)
I'd bet the Steam Deck (and other changes) will have the following impacts on Linux overall by the end of 2022.
- The majority of Linux users will run Wayland over X11.
- Valve’s Steamdeck is going to double the number of Linux gamers per Valve's Hardware Survey.
- Flatpak/Flathub will ride the Deck wave - usage will double.
- Distros will ride the Deck wave - gaming usage will increase by about 20% (1% -> 1.20%).
1 Majority Wayland
Currently we are at less than 10% running wayland per Firefox telemetry stats on Phoronix but there are a lot of movers, namely:
- Ubuntu 22.04 LTS will be the first Ubuntu LTS release defaulting to Wayland.
- Nvidia drivers explicitly improving Wayland support.
- Although this is still a big list, KDE wayland support has been getting a lot of improvements recently and it's the default on some installs.
- Steam Deck will be using Wayland.
2 Double Steam Linux users
Right now for January 2022 1.06% of Steam users are running Linux. I estimate about 340-460k Steam Linux users (Valve published Flatpak installs for November at about 5%. There are approximately 17000-23000 users for each update).
We don't have current numbers for Steam deck reservations, but near launch it was > 100k. Selling 300k-500k seems quite within the realm of possibilities. I would also not be surprised if they sold more.
3 Flathub usage doubles
Flatpak is the easiest way to install non-Steam software on a Steam deck - "Yes. You'll be able to install external apps via Flatpak or other software without going into developer mode" - Steam Deck FAQ
Valve has avoided picking sides regarding Flatpak vs Snap vs AppImage so far. They still offer a deb from their own download page. Given Steam's user base just making the Flatpak the default would likely more than double Flatpak usage.
There are more wildcards here:
- How actually easy will flatpak be?
- How hard are other options - snaps (requires dev mode?), AppImage (seems like it might work fine), etc?
4 Distros ride the wave
I'm expecting at least 20% increase on the Steam Hardware Survey (so 1% to 1.20%) not including Steam Deck. Right now, the Steam Linux usage is less than half what you get from other sources. That could mean multiple things:
- Linux is less likely to be used by gamers
- Linux users prefer playing awesome open source games (or otherwise don't use Steam)
- Users switch to game on other platforms. Many users might take a fresh look at Steam on their existing Linux boxes with all the press from the Steam Deck.
All are likely true to some extent.
Linux distros have many options to further ride the wave:
- Encourage Linux consumer focused pre-installs with similar AMD chips to what's in the Steam Deck (I know many have asked for more AMD preinstalls for a long while)
- Enable Flathub/flatpak by default for easier finding apps (Steam itself is not discoverable on Ubuntu unless you enable flatpak. If flatpak takes off more, this will be quite essential)
- Gaming on Linux has been discussed more on mainstream tech shows than at any point in my memory. This is a marketing opportunity to not pass up.
- Help support Game studios with Linux porting and compatibility. (or show other stores they can come!)
Do you think these will all come to pass? Was I way off? Add a comment via Gitlab
Lines of code (LOC) has some known flaws, but one of its advantages is that it lets humans visualize it for a small enough number. For bigger numbers like 100,000 vs 200,000 lines of code it really doesn't help us humans picture it.
For big enough changes, you could switch to just compressing the diff and measuring that. That also nicely tracks what developers would have to actually download to get the new changes. It also helps with understanding the bandwidth requirements of contributing to a project.
Here is what it looks like for the Linux kernel since 4.1. (For Rc1s only - the other rcs are in the 30-100 KiB range)
Here is a comparison of how far apart the LOC numbers are from the compressed diff numbers - the longer the line is the further apart they are. The numbers are normalized to 0-1. As you can see, they generally line up.
(You can get the raw spreadsheet here )
Let's get some numbers from another project - say systemd.
$ git tag --list --sort=creatordate | tail #Pick the last two major releases.. $ git diff v247 v248 | xz -c -q | wc -c | numfmt --to=iec-i --round=nearest 1.1MiB
This isn't ground breaking, but it may prove to be slightly more useful than using LOCs. At the very least as an alternative, it could help put less emphasis on LOCs.
Some interesting future things to look at:
- Better comparisons between software projects using different languages?
- Tracking other changes to software projects in a similar way (Wikis, MLs).
- Compare with other kinds of projects. For instance Wikipedia does track changes monthly by the GB.
Comments and Feedback
Feel free to make a PR to add comments!
Where win means becomes the universal way to get apps on Linux.
In short, I don't think either current iteration will. But why?
I started writing this a while ago, but Disabling snap Autorefresh reminded me to finish it. I also do not mean this as a "hit piece" against my former employer.
Here is a quick status of where we are:
|Command Line apps||☑️||🚫|
|Full independence option||🚫||☑️|
|Build a complete desktop||🚫||☑️|
Both Flatpaks and Snaps are pretty good at desktop apps. They share some bits and have some differences. Flatpak might have a slight edge because it's focused only on Desktop apps, but for the most part it's a wash.
Service/Server / Embedded / Command Line apps
Flatpak doesn't target these at all. Full stop.
Snap wins these without competition from Flatpak but this does show a security difference. sudo snap install xyz will just install it - it won't ask you if you think it's a service, desktop app or some combination (or prompt you for permissions like Flatpak does).
With Embedded using Ubuntu Core it requires strict confinement which is a plus (Which you read correctly, means "something less" confinement everywhere else).
Aside: As Fedora SilverBlue and Endless OS both only let you install Flatpaks, they also come with the container based Toolbox to make it possible to run other apps.
Full independence option / Build a complete desktop
You can not go and (re)build your own distro and use upstream snapd.
Snaps are generally running from one LTS "core" behind what you might expect from your Ubuntu desktop version. For example: core18 is installed by default on Ubuntu 21.04. The embedded Ubuntu Core option is the only one that is using just one version of Ubuntu core code..
With Flatpak you can choose to use one of many public bases like the Freedesktop platform or Gnome platform. You can also build your own Platform like Fedora Silverblue does. All of the default flatpak that Silverblue comes with are derived from the "regular" Fedora of the same version. You can of course add other sources too. Example: The Gnome Calculator from Silverblue is built from the Fedora RPMs and depends on the org.fedoraproject.Platform built from that same version of Fedora.
Aside: I should note that to do that you need OSTree to make the Platforms.
Flatpak itself does not do any updates automatically. It relies on your software application to do it (Gnome Software). It also has the ability for apps to check for their own updates and ask to update itself.
Snaps are more complicated, but why? Let's look at the Ubuntu IoT and device services that Canonical sells:
Dedicated app store ...complete control of application versions, updates and controlled rollouts for $15,000 per year.
Enterprise app store ...control snap updates and upgrades. Ensure that all device traffic goes through an audited communications channel and determine the precise versions of snaps used inside the business.
Control of the update process is one of the ways Canonical is trying to make money. I don't believe anyone has ever told me explicitly that this is why Snaps update work this way. it just makes sense given the business considerations.
So who is going to "win"?
One of them might go away, but neither is set to become the universal way to get apps on Linux at least not today.
It could change starting with something like:
- Flatpak (or something like it) evolves to support command line or other apps.
- A snap based Ubuntu desktop takes off and becomes the default Ubuntu.
Either isn't going to get it all the way there, but is needed to prove what the technology can do. In both cases, the underlying confinement technology is being improved for all.
Maybe I missed something? Feel free to make a PR to add comments!
If you are in the USA - Please use my new site KeepSummerTime.com to write to your congresspeople asking for summer time all year long.
The USA has an active bill in congress to keep us from changing the clocks and stay on time like it is in the summer year round (also called permanent DST). Changing the clocks has not been shown to have substantial benefits and the harms have been well documented.
For global communities - like FLOSS -
- It makes it that much harder to schedule across the world.
- The majority of the world does not do clock switching. It's generally EU/US specific.
If you are in the USA - Please use my new site KeepSummerTime.com to write to your congresspeople asking for summer time all year long.
If you want to help out
- the site is all available on Github although the actual contact congress bit is from ActionNetwork.
- I'd be very happy to make this site global in nature for all of us stuck with unstable time. Please get in touch!
I used 2 of the variants supported by mmdebstrap to illustrate the different small build options.
Thanks to Dan at EndlessOS for showing me the much easier way:
$ grep-aptavail -n -s Package -F Essential yes $ grep-aptavail -n -s Package -F Priority required $ grep-aptavail -n -s Package -F Priority important
Uncompressed tarball size 94M
For when you don't even want to have apt.
base-files base-passwd bash bsdutils coreutils dash debconf debianutils diffutils dpkg findutils gcc-10-base:amd64 grep188M init-system-helpers libacl1:amd64 libattr1:amd64 libaudit-common libaudit1:amd64 libblkid1:amd64 libbz2-1.0:amd64 libc-bin libc6:amd64 libcap-ng0:amd64 libcom-err2:amd64 libcrypt1:amd64 libdb5.3:amd64 libdebconfclient0:amd64 libgcc-s1:amd64 libgcrypt20:amd64 libgmp10:amd64 libgpg-error0:amd64 libgssapi-krb5-2:amd64 libk5crypto3:amd64 libkeyutils1:amd64 libkrb5-3:amd64 libkrb5support0:amd64 liblz4-1:amd64 liblzma5:amd64 libmount1:amd64 libnsl2:amd64 libpam-modules:amd64 libpam-modules-bin libpam-runtime libpam0g:amd64 libpcre2-8-0:amd64 libpcre3:amd64 libselinux1:amd64 libsmartcols1:amd64 libssl1.1:amd64 libsystemd0:amd64 libtinfo6:amd64 libtirpc-common libtirpc3:amd64 libudev1:amd64 libuuid1:amd64debian-requirements.md zlib1g:amd64
Added in minbase
Uncompressed tarball size 123M
adduser apt debian-archive-keyring e2fsprogs gcc-9-base:amd64 gpgv libapt-pkg6.0:amd64 libext2fs2:amd64 libffi7:amd64 libgnutls30:amd64 libhogweed6:amd64 libidn2-0:amd64 libnettle8:amd64 libp11-kit0:amd64 libseccomp2:amd64 libsemanage-common libsemanage1:amd64Added in minbase libxxhash0:amd64 logsave mount passwd tzdata
Added in default variant
Uncompressed tarball size 188M
Theoretically all Priority: Important packages.
This is where items start to get a bit redundant IMHO. Mostly because I prefer the built-in systemd options as opposed to ifupdown, rsyslog/logrotate and cron.
apt-utils cpio cron debconf-i18n dmidecode dmsetup fdisk ifupdown init iproute2 iputils-ping isc-dhcp-client isc-dhcp-common kmod less libapparmor1:amd64 libargon2-1:amd64 libbpf0:amd64 libbsd0:amd64 libcap2:amd64 libcap2-bin libcryptsetup12:amd64 libdevmapper1.02.1:amd64 libdns-export1110 libedit2:amd64 libelf1:amd64 libestr0:amd64 libfastjson4:amd64 libfdisk1:amd64 libip4tc2:amd64 libisc-export1105:amd64 libjansson4:amd64 libjson-c5:amd64 libkmod2:amd64 liblocale-gettext-perl liblognorm5:amd64 libmd0:amd64 libmnl0:amd64 libncurses6:amd64 libncursesw6:amd64 libnewt0.52:amd64 libnftables1:amd64 libnftnl11:amd64 libpopt0:amd64 libprocps8:amd64 libreadline8:amd64 libslang2:amd64 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libxtables12:amd64 logrotate nano netbase nftables procps readline-common rsyslog sensible-utils systemd systemd-sysv systemd-timesyncd tasksel tasksel-data udev vim-common vim-tiny whiptail xxd
I run Steam in a flatpak for convenience and confinment reasons. One day my Steam install failed with
My first instinct is to check to make sure libc6:i386 is actually installed - it is. Then I check to see if there are flatpak updates, but with the 32-bit libraries I find more errors:
ID Branch Op Remote Download 1. [✗] org.freedesktop.Platform.GL32.nvidia-460-39 1.4 i flathub 178.7 MB / 178.7 MB Error: While trying to apply extra data: apply_extra script failed, exit status 40704 error: Failed to install org.freedesktop.Platform.GL32.nvidia-460-39: While trying to apply extra data: apply_extra script failed, exit status 40704
Feb 26 08:18:24 desktop polkitd(authority=local): Registered Authentication Agent for unix-process:3535:65589 (system bus name :1.75 [flatpak install org.freedesktop.Platform.GL32.nvidia-460-39], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Feb 26 08:18:26 desktop flatpak: libostree pull from 'flathub' for runtime/org.freedesktop.Platform.GL32.nvidia-460-39/x86_64/1.4 complete security: GPG: summary+commit security: SIGN: disabled http: TLS delta: parts: 1 loose: 3 transfer: secs: 0 size: 349.8 kB Feb 26 08:18:54 desktop flatpak: system: Pulled runtime/org.freedesktop.Platform.GL32.nvidia-460-39/x86_64/1.4 from flathub Feb 26 08:18:55 desktop audit: SECCOMP auid=1000 uid=0 gid=0 ses=2 subj==unconfined pid=3583 comm="apply_extra" exe="/app/bin/apply_extra" sig=31 arch=40000003 syscall=122 compat=1 ip=0x80a933d code=0x0
This is where I remember that I've been testing a lot of systemd confinement changes (including limiting SystemCalls) and one of the services I modified was gpg-agent. However, reverting that change doesn't help but I'm getting closer. (Aside: Great time to guess what config change I made that caused the errors..)
I then run:
sudo flatpak repair
to verify all the files in flatpak but nothing needed fixing.
I then ran:
$ sudo dpkg -V ... /etc/systemd/system.conf ...
Oh, shoot I did setup
This is saying I only want native syscalls to be run, but why is it applying to an application! I would have thought it just applied to services or other things systemd runs.
Sure enough disabling that option fixes it, Steam works, and the 32-bit NVidia via Flatpak install too.
Flatpak runs apps in a systemd scope (if available).
$ systemctl status --user app-flatpak-com.valvesoftware.Steam-6702.scope ● app-flatpak-com.valvesoftware.Steam-6702.scope Loaded: loaded (/run/user/1000/systemd/transient/app-flatpak-com.valvesoftware.Steam-6702.scope; transient) Transient: yes Active: active (running) since Wed 2021-03-03 12:16:23 PST; 1min 2s ago Tasks: 113 (limit: 38415) Memory: 352.0M CPU: 16.066s CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/app-flatpak-com.valvesoftware.Steam-6702.scope ├─6702 bwrap --args 41 /app/bin/steam-wrapper ├─6706 bwrap --args 4But what does 1 xdg-dbus-proxy --args=43 ├─6707 xdg-dbus-proxy --args=43 ├─6711 bwrap --args 41 /app/bin/steam-wrapper ├─6713 bash /home/bryan/.local/share/Steam/steam.sh ....etc
I want to explore inside this scope more and I stumble upon some Sandbox docs, but using flatpak run just creates it's own scope:
$ systemctl status --user app-flatpak-com.valvesoftware.Steam-7616.scope ● app-flatpak-com.valvesoftware.Steam-7616.scope Loaded: loaded (/run/user/1000/systemd/transient/app-flatpak-com.valvesoftware.Steam-7616.scope; transient) Transient: yes Active: active (running) since Wed 2021-03-03 12:20:21 PST; 33s ago Tasks: 6 (limit: 38415) Memory: 2.8M CPU: 61ms CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/app-flatpak-com.valvesoftware.Steam-7616.scope ├─7616 bwrap --args 42 bash ├─7620 bwrap --args 42 xdg-dbus-proxy --args=44 ├─7621 xdg-dbus-proxy --args=44 ├─7624 bwrap --args 42 bash └─7626 bash
But this is an awesome way to see what the Flatpak actually has access to (and the package icon is just such a nice touch)
$ flatpak run --command=bash com.valvesoftware.Steam [📦 com.valvesoftware.Steam ~]$ ls Music Pictures cache config data [📦 com.valvesoftware.Steam ~]$ pwd /home/bryan
I totally forgot that Steam has a built-in music player. Let's turn that off.
flatpak permissions-show or list doesn't seem to do anything.
flatpak info --show-permissions com.valvesoftware.Steam is the right answer (thanks!)
I then decide to just install Flatseal to review those and end up disabling all the default file permissions.
$ flatpak run --command=bash com.valvesoftware.Steam [📦 com.valvesoftware.Steam ~]$ ls Music Pictures cache config data
Hmm.. Did I do something wrong?
$ ls Music/ Pictures/ Music/: Pictures/:
Nope, those directories are now empty. Previosly they were my actual music and pictures. Better confinement and a better understanding of how it works. Nice!
Have a comment or did I make a mistake? Add it via Gitlab.
I'm running Debian 11 (testing) with XFCE and getting PipeWire up and running was relatively easy - although explicitly unsupported for Debian 11.
sudo apt install pipewire pipewire-audio-client-libraries sudo apt remove pulseaudio pulseaudio-utils sudo apt autoremove
At some future point there will be something like pipewire-pulse which will do the rest, but for now you must:
sudo touch /etc/pipewire/media-session.d/with-pulseaudio sudo cp /usr/share/doc/pipewire/examples/systemd/user/pipewire-pulse.* /etc/systemd/user/ systemctl --user enable pipewire-pulse pipewire
I suggest a reboot after, but a logout may be enough. Then try playing some music. If it worked, it should play just like it has before.
1456 bryan 20 0 1023428 102436 50396 S 1.7 2.6 0:02.06 quodlibet 690 bryan 9 -11 898044 27364 20932 S 1.0 0.7 0:00.31 pulseaudio
PipeWire runs as 3 separate processes compared to PulseAudio above. Of note, apparently PipeWire does want to adjust it's nice level, but in it's current state it doesn't depend on it - and I haven't seen any need for it.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 936 bryan 20 0 826812 100484 50472 S 1.3 2.5 0:02.71 quodlibet 692 bryan 20 0 94656 12480 5928 S 0.7 0.3 0:00.38 pipewire-pulse 693 bryan 20 0 107408 15228 7192 S 0.3 0.4 0:00.39 pipewire 701 bryan 20 0 225340 22756 17280 S 0.0 0.6 0:00.06 pipewire-media-
What's works? Everything so far..
- Playing music locally
- Playing videos locally
- Playing music/videos on the web
- Video calls via Jitsi
- Changing volume using xfce's pulseaudio applet
Except I can't change individual application volumes because pavucontrol was removed. I belive pavucontrol could actually control it, but I haven't tried it.
So worth switching?
If you want to be an early adopter, jump on in. If not Fedora and Ubuntu will both be including it this year (although I'm not sure if Ubuntu will replace PulseAudio with it).
This is my favorite line from the Fedora proposal: "...with both the PulseAudio and JACK maintainers and community. PipeWire is considered to be the successor of both projects."
It's generally a lot of work to get three projects to agree on standards between them, much less to have general agreement on a future path. I'm very impressed with all three groups to figure out a path to improve Linux audio together.
A couple years ago I was a part of a discussion about encrypted messaging.
- I was in the Signal camp - we needed it to be quick and easy to setup for users to get setup. Using existing phone numbers makes it easy.
- Others were in the Matrix camp - we need to start from scratch and make it distributed so no one organization is in control. We should definitely not tie it to phone numbers.
I was wrong.
Signal has been moving in the direction of adding PINs for some time because they realize the danger of relying on the phone number system. Signal just mandated PINs for everyone as part of that switch. Good for security? I really don't think so. They did it so you could recover some bits of "profile, settings, and who you’ve blocked".
If you lose your phone your profile is lost and all message data is lost too. When you get a new phone and install Signal your contacts are alerted that your Safety Number has changed - and should be re-validated.
If you lost your phone you can use your PIN to recover some parts of your profile and other information. I am unsure if Safety Number still needs to be re-validated or not.
Your profile (or it's encryption key) is stored on at least 5 servers, but likely more. It's protected by secure value recovery.
There are many awesome components of this setup and it's clear that Signal wanted to make this as secure as possible. They wanted to make this a distributed setup so they don't even need to tbe only one hosting it. One of the key components is Intel's SGX which has several known attacks. I simply don't see the value in this and it means there is a new avenue of attack.
By mandating user chosen PINs, my guess is the great majority of users will reuse the PIN that encrypts their phone. Why? PINs are re-used a lot to start, but here is how the PIN deployment went for a lot of Signal users:
- Get notification of new message
- Click it to open Signal
- Get Mandate to set a PIN before you can read the message!
That's horrible. That means people are in a rush to set a PIN to continue communicating. And now that rushed or reused PIN is stored in the cloud.
Hard to leave
They make it easy to get connections upgraded to secure, but their system to unregister when you uninstall has been down Since June 28th at least (tried last on July22nd). Without that, when you uninstall Signal it means:
- you might be texting someone and they respond back but you never receive the messages because they only go to Signal
- if someone you know joins Signal their messages will be automatically upgraded to Signal messages which you will never receive
In summary, Signal got people to hastily create or reuse PINs for minimal disclosed security benefits. There is a possibility that the push for mandatory cloud based PINS despite all of the pushback is that Signal knows of active attacks that these PINs would protect against. It likely would be related to using phone numbers.
I'm trying out the Element which uses the open Matrix network. I'm not actively encouraging others to join me, but just exploring the communities that exist there. It's already more featureful and supports more platforms than Signal ever did.
Maybe I missed something? Feel free to make a PR to add comments
In the XMPP world, Conversastions has been leading the charge to modernize XMPP, with an index of popular public groups (
jabber.network) and a server validator.
XMPP is mobile-battery friendly, and supports server-side logs wrapped in strong, multi-device encryption (in contrast to Signal, your keys never leave your devices!).
Video calling even works now.
It can interact with IRC and Riot (though the Riot bridge is less developed).
There is a beautiful Windows client, a beautiful Linux client and a beautiful terminal client, two good Android clients, a beautiful web client which even supports video calling (and two others).
It is easy to get an account from one of the many servers indexed here or here, or by looking through libreho.st.
You can also set up your own with a little bit of reading.
Snikket is building a one-click Slack-like personal-group server, with file-sharing, welcome channels and shared contacts,
or you can integrate it with NextCloud.
XMPP has solved a lot of problems over its long history, and might just outlast all the centralized services.
I totally forgot about XMPP, thanks for sharing!