Another short status update of what happened on my side last
month. The larger blocks are the Phosh
0.44 release and landing the
initial Cell Broadcast support in phosh. The rest is all just small
bits of bug, fallout/regression fixing here and there.
phosh
Fix notification regression and release 0.43.1 (MR), 0.43.1
Make notifiction banner take less vertical space (MR)
Reviews
This is not code by me but reviews on other peoples code. The list is
incomplete, but I hope to improve on this in the upcoming
months. Thanks for the contributions!
git-buildpackage: Add import-ref to gbp(1) ([MR (https://salsa.debian.org/agx/git-buildpackage/-/merge_requests/31))
Help Development
Thanks a lot to all the those who supported my work on this in 2024. Happy new year!
If you want to support my work see donations.
Comments?
Join the Fediverse thread
As in 2023 I took another look back at what changed in Phosh in 2024 and instead of just updating my notes why not again share it here.
The Phosh developers focus from day one was to make devices running Phosh daily drivable without having to resort to any proprietary OSes as a fallback. So the past years were often dominated by adding essential features to make that possible and reliable at all.
Another short status update of what happened on my side last
month. The larger blocks are the Phosh 0.43
release, the initial file chooser portal, phosh-osk-stub now handling
digit, number, phone and PIN input purpose via special layouts as
well as Phoc mostly catching up with wlroots 0.18 and the current
development version targeting 0.19.
phosh
When taking a screenshot via keybinding or power button long press
save screenshots to clipboard and disk (MR)
Unbreak tests on non intel/amd architectures (e.g. arm64) (MR)
Reviews
This is not code by me but reviews I did on other peoples code. The
list is incomplete, but I hope to improve on this in the upcoming
months. Thanks for the contributions!
Help Development
If you want to support my work see donations. This includes
a list of hardware we want to improve support for. Thanks a lot to all current and past donors.
Comments?
Join the Fediverse thread
Another short status update of what happened on my side last month. Besides a phosh bugfix release improving text input and selection
was a prevalent pattern again resulting in improvements in the compositor, the OSK and some apps.
phosh
Install gir (MR). Needed for e.g. Debian to properly package the Rust bindings.
Try harder to find an app icon when showing notifications (MR)
Consistent focus style on lock screen and settings (MR). Improves the visual appearance
as the dotted focus frame doesn't match our otherwise colored focus frames
Don't focus buttons in settings (MR). Improves the visual appearance as
attention isn't drawn to the button focus.
Close Phosh's settings when activating a Settings panel (MR)
Collect some of the QCom workarounds in a package (MR). This is not meant to go into Debian proper but it's nicer than doing all the mods by hand and forgetting which files were modified.
Don't take focus when sending messages, adding emojis or attachments (MR). Makes typing faster (as the OSK
won't hide) and thus using those buttons easier
xdg-desktop-portal
Use categories that work for both xdg-spec and the portal (MR)
Reviews
This is not code by me but reviews on other peoples code. The list is
fairly incomplete, hope to improve on this in the upcoming months:
Help Development
If you want to support my work see donations. This includes
a list of hardware we want to improve support for. Thanks a lot to all current and past donors.
Another short status update of what happened on my side last
month. Besides the usual amount of housekeeping last month was a lot
about getting old issues resolved by finishing some stale merge
requests and work in pogress MRs. I also pushed out the Phosh 0.42.0
Releasephosh
Mark mobile-data quick setting as insensitive when modem is off (MR)
Sanitize versions as this otherwise breaks the libphosh-rs build (MR)
lockscreen: Swap deck and carousel to avoid triggering the plugins page when entering pin and let the lockscreen shrink to smaller sizes (MR) (two more year old usability issues out of the way)
Ensure we send enough feedback when phone is blanked/locked (MR). This should be way easier now for apps as they
don't need to do anything and we can avoid duplicate feedback sent from e.g. Chatty.
Fix possible use after free when activating notifications on the lock screen (MR)
Don't lose preedit when switching applications, opening menus, etc (MR). This fixes the case (e.g. with word completion in phosh-osk-stub enabled) where it looks to the user as if the last typed word would get lost when switching from a text editor to another app or when opening a menu
Fix word salad with presage completer when entering cursor navigation mode (and in some other cases)
(MR 1). Presage
has the best completion but was marked experimental due to that.
Submit preedit on changes to terminal and emoji layout (MR)
Unbreak and modernize CI a bit (MR). A passing CI is so much more motivating for contributers and reviewers.
Fotema
Fix app-id and hence the icon shown in Phosh's overview (MR)
Help Development
If you want to support my work see donations. This includes
a list of hardware we want to improve support for. Thanks a lot to all current and past donors.
Another short status update of what happened on my side last month.
Quite a bit of time went
into helping organize the FrOSCon FOSS on Mobile dev room (day 1, day 2, summary) but that was all worth it and fun - so was releasing Phosh 0.41.0 (which incidetally happened right before FrOScon). A three years old MR to xdg-spec to add call categories landed (thanks Matthias) allowing us to finally provide proper feedback for e.g. IM calls too. The rest was some OSK improvements (around Indic language support via varnam and layout configuration), some Cell Broadcast advancements (thanks to NGI0 for supporting this) but also some fixes. Here's the details:
Phosh
Debug crash when swiping away keyboard on lockscreen (MR).
Fix outdated clock when swiping back from lockscreen plugins (MR)
Allow to select OSK layouts (MR). This ensures only actually available layouts can be selected. Currently used by phosh-osk-stub but can easily be extended to squeekboard once it provides the information.
Rework most bits of Cell Broadcast to move it closer to undraft status (MR).
(Remaining bits affect enabling of unsolicited messages and setting channels).
Help Development
If you want to support my work see donations. This includes
a list of hardware we want to improve support for. Thanks a lot to all current and past donors.
A short status update on what happened on my side last month. Looking
at unified push support for Chatty prompted some libcmatrix fixes and
Chatty improvements (benefiting other protocols like SMS/MMS as well).
The Bluetooth status page in Phosh was a slightly larger change code
wise as we also enhanced our common widgets for building status pages,
simplifying the Wi-Fi status page and making future status pages
simpler. But as usual investigating bugs, reviewing patches (thanks!)
and keeping up with the changing world around us is what ate most of
the time.
Phosh
A Wayland Shell for mobile devices
A short status update of what happened on my side last month. Was able
to test our Cellbroadcast bits, feedbackd became more flexible
regarding LEDs, Phosh 0.40 is out, and some more.
Phosh
A short status update of what happened on my side last month. A broken
gcovr in Debian triggered a bit of busy work but 0.39.0 came out
nicely nevertheless. We also reduced build time quiet a bit in phosh
and phoc.
Since phoc 0.39.0 it is possible to configure which keys unidle your phone (which results in unblanking the screen).
The current default is that all keys unblank which is usually fine for e.g. laptops but not the desired result for phones and tablets where this depends on the position and function of keys. Volume keys and other exposed keys usually shouldn t unblank - maybe with the exception of some Home buttons on devices that have those.
We are very excited to announce that Debian has selected seven contributors to work
under mentorship on a variety of
projects with us during the
Google Summer of Code.
Here are the list of the projects, students, and details of the tasks to be performed.
Project: Android SDK Tools in Debian
Deliverables of the project: Deliver an automated method for Debian maintainers
to test selected numerical Debian packages for their parallel performance in
clusters, in particular to catch performance regressions from updates, and to
verify expected performance gains, such as Amdahl s and Gufstafson s law, from
increased cluster resources.
Project: Debian MobCom
Student: Nathan D
Deliverables of the project: Update the outdated mobile packages and recreate aged
packages due to new dependencies. Bring in more mobile communication tools by
adding about 5 new packages.
Project: Improve support of the Rust coreutils in Debian
Deliverables of the project: Building, packaging, and uploading missing ROCm
software into Debian repositories, starting with simple tools and progressing to
high-level applications like PyTorch, with the final deliverables comprising a
series of ROCm packages meeting community quality assurance standards.
Project: procps: Development of System Monitoring, Statistics and Information Tools in Rust
Student: Krysztal Huang
Deliverables of the project: Improve the usability of the entire Rust-based
implementation of the procps utility on Linux.
Congratulations and welcome to all the contributors!
The Google Summer of Code program is possible in Debian thanks to the efforts of
Debian Developers and Debian Contributors that dedicate part of their free time to
mentor contributors and outreach tasks.
Join us and help extend Debian! You can follow the contributors' weekly reports on the
debian-outreach mailing-list, chat with us on our
IRC channel or reach out to the individual projects' team
mailing lists.
Improve introspection data and documentation (Merge Request 1, Merge Request 2).
Besides better docs (we now also fail on new warnings and errors (Merge Request) this allows to use parts of phosh in e.g. display managers in languages
using introspection (Rust, JS, ). See this issue
how this could become useful.
Add night light quick settings toggle: Merge Request
Fix power menu rendering without Cantarell: Merge Request
Track settings state (Merge Request) in shell state flags
too. This will be useful to make tests more robust.
phoc: A wlroots based Wayland compositor mostly used on mobile phones
Fix Doc build and make sure more methods end up there: Merge Request
systemd:
Discuss hwdb and udev rules so we can track unidle/wakup keys: hwdb Merge Request,
udev Merge Request to better handle device tree devices. As it turns out we'll do
most of this in phoc initially and then open another merge request once we have more data.
A short status update of what happened on my side last month. I spent
quiet a bit of time reviewing new, code (thanks!) as well as
maintenance to keep things going but we also have some improvements:
Phosh
Add support for progress indicator and counts to lockscreen launcher entries: Merge request,
Demo using Phosh-EV's charge status as example (Merge request)
Tightening the feedback loop Link to heading One thing we notice ever so often is that although Phosh s source code is publicly available and upcoming changes are open for review the feedback loop between changes being made to the development branch and users noticing the change can still be quiet long.
This can be problematic as we ideally want to catch a regression or broken use case triggered by a change on the development branch (aka main) before the general availability of a new version.
As in 2022 I took another look back at what changed in Phosh in 2023 and instead of just updating my notes why not share it here. In short: While collecting these bits I became really impressed about the progress we made :
Some numbers Link to heading We were discussing at this years Phosh Community Get Together at Froscon if we should lengthen the Phosh release cycle a bit but we kept the one release per month schedule to get improvements out to users quickly.
I wanted to look back at what changed in phosh in 2022 and figured I
could share it with you. I'll be focusing on things very close to the
mobile shell, for a broader overview see Evangelos upcoming FOSDEM
talk.
Some numbers
We're usually aiming for a phosh release at the end of each month. In
2022 We did 10 releases like that, 7 major releases (bumping the
middle version number) and three betas. We skipped the April and
November releases. We also did one bug fix relesae out of line
(bumping the last bit of the version number). I hope we can keep that
cadence in 2023 as it allows us to get changes to users in a timely
fashion (thus closing usability gaps as early as possible) as well as
giving distributions a way to plan ahead. Ideally we'd not skip any
release but sometimes real life just interferes.
Those releases contain code contributions from about 20 different
people and translations from about 30 translators. These numbers
are roughly the same as 2021 which is great. Thanks everyone!
In phosh's git repository we had a bit over 730 non-merge commits
(roughly 2 per day), which is about 10% less than in 2021. Looking
closer this is easily compensated by commits to phoc (which needed
quite some work for the gestures) and phosh-mobile-settings which
didn't exist in 2021.
User visible features
Most notable new features are likely the swipe gestures for top and
bottom bar, the possibility to use the quick settings on the lock
screen as well as the style refresh driven by Sam Hewitt that
e.g. touched the modal dialogs (but also sliders, dialpads, etc):
We also added the possibility to have custom widgets via loadable
plugins on the lock screen so the user can decide which information
should be available. We currently ship plugins to show
information on upcoming calendar events
emergency contact information
PDFs like bus or train tickets
the current month (as hello world like plugin to get started)
These are maintained within phosh's source tree although out of
tree plugins should be doable too.
There's a settings application (the above mentioned
phosh-mobile-settings) to enable these. It also allows those plugins
to have individual preferences:
Speaking of configurability: Scale-to-fit settings (to work around
applications that don't fit the screen) and haptic/led feedback are
now configurable without resorting to the command line:
We can also have device specific settings which helps to temporarily
accumulate special workaround without affecting other phones.
Other user visible features include the ability to shuffle the digits
on the lockscreen's keypad, a VPN quick settings, improved screenshot
support and automatic high contrast theme switching when in bright
sunlight (based on ambient sensor readings) as shown here.
As mentioned above Evangelos will talk at FOSDEM 2023 about the
broader ecosystem improvements including GNOME, GTK, wlroots, phoc,
feedbackd, ModemManager, mmsd, NetworkManager and many others without
phosh wouldn't be possible.
What else
As I wanted a T-shirt for Debconf 2022 in Prizren so I created a logo
heavily inspired by those cute tiger images you often see in Southeast
Asia. Based on that I also made a first batch of stickers mostly
distributed at FrOSCon 2022:
That's it for 2022. If you want to get involved into phosh testing, development
or documentation then just drop by in the matrix room.
If you ve done anything in the Kubernetes space in recent years, you ve most likely come across the words Service Mesh . It s backed by a set of mature technologies that provides cross-cutting networking, security, infrastructure capabilities to be used by workloads running in Kubernetes in a manner that is transparent to the actual workload. This abstraction enables application developers to not worry about building in otherwise sophisticated capabilities for networking, routing, circuit-breaking and security, and simply rely on the services offered by the service mesh.In this post, I ll be covering Linkerd, which is an alternative to Istio. It has gone through a significant re-write when it transitioned from the JVM to a Go-based Control Plane and a Rust-based Data Plane a few years back and is now a part of the CNCF and is backed by Buoyant. It has proven itself widely for use in production workloads and has a healthy community and release cadence.It achieves this with a side-car container that communicates with a Linkerd control plane that allows central management of policy, telemetry, mutual TLS, traffic routing, shaping, retries, load balancing, circuit-breaking and other cross-cutting concerns before the traffic hits the container. This has made the task of implementing the application services much simpler as it is managed by container orchestrator and service mesh. I covered Istio in a prior post a few years back, and much of the content is still applicable for this post, if you d like to have a look.Here are the broad architectural components of Linkerd:The components are separated into the control plane and the data plane.The control plane components live in its own namespace and consists of a controller that the Linkerd CLI interacts with via the Kubernetes API. The destination service is used for service discovery, TLS identity, policy on access control for inter-service communication and service profile information on routing, retries, timeouts. The identity service acts as the Certificate Authority which responds to Certificate Signing Requests (CSRs) from proxies for initialization and for service-to-service encrypted traffic. The proxy injector is an admission webhook that injects the Linkerd proxy side car and the init container automatically into a pod when the linkerd.io/inject: enabled is available on the namespace or workload.On the data plane side are two components. First, the init container, which is responsible for automatically forwarding incoming and outgoing traffic through the Linkerd proxy via iptables rules. Second, the Linkerd proxy, which is a lightweight micro-proxy written in Rust, is the data plane itself.I will be walking you through the setup of Linkerd (2.12.2 at the time of writing) on a Kubernetes cluster.Let s see what s running on the cluster currently. This assumes you have a cluster running and kubectl is installed and available on the PATH.
On most systems, this should be sufficient to setup the CLI. You may need to restart your terminal to load the updated paths. If you have a non-standard configuration and linkerd is not found after the installation, add the following to your PATH to be able to find the cli:
export PATH=$PATH:~/.linkerd2/bin/
At this point, checking the version would give you the following:
$ linkerd version Client version: stable-2.12.2 Server version: unavailable
Setting up Linkerd Control PlaneBefore installing Linkerd on the cluster, run the following step to check the cluster for pre-requisites:
kubernetes-api -------------- can initialize the client can query the Kubernetes API
kubernetes-version ------------------ is running the minimum Kubernetes API version is running the minimum kubectl version
pre-kubernetes-setup -------------------- control plane namespace does not already exist can create non-namespaced resources can create ServiceAccounts can create Services can create Deployments can create CronJobs can create ConfigMaps can create Secrets can read Secrets can read extension-apiserver-authentication configmap no clock skew detected
linkerd-version --------------- can determine the latest version cli is up-to-date
Status check results are
All the pre-requisites appear to be good right now, and so installation can proceed.The first step of the installation is to setup the Custom Resource Definitions (CRDs) that Linkerd requires. The linkerd cli only prints the resource YAMLs to standard output and does not create them directly in Kubernetes, so you would need to pipe the output to kubectl apply to create the resources in the cluster that you re working with.
$ linkerd install --crds kubectl apply -f - Rendering Linkerd CRDs... Next, run linkerd install kubectl apply -f - to install the control plane.
customresourcedefinition.apiextensions.k8s.io/authorizationpolicies.policy.linkerd.io created customresourcedefinition.apiextensions.k8s.io/httproutes.policy.linkerd.io created customresourcedefinition.apiextensions.k8s.io/meshtlsauthentications.policy.linkerd.io created customresourcedefinition.apiextensions.k8s.io/networkauthentications.policy.linkerd.io created customresourcedefinition.apiextensions.k8s.io/serverauthorizations.policy.linkerd.io created customresourcedefinition.apiextensions.k8s.io/servers.policy.linkerd.io created customresourcedefinition.apiextensions.k8s.io/serviceprofiles.linkerd.io created
Next, install the Linkerd control plane components in the same manner, this time without the crds switch:
$ linkerd install kubectl apply -f - namespace/linkerd created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-identity created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-identity created serviceaccount/linkerd-identity created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-destination created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-destination created serviceaccount/linkerd-destination created secret/linkerd-sp-validator-k8s-tls created validatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-sp-validator-webhook-config created secret/linkerd-policy-validator-k8s-tls created validatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-policy-validator-webhook-config created clusterrole.rbac.authorization.k8s.io/linkerd-policy created clusterrolebinding.rbac.authorization.k8s.io/linkerd-destination-policy created role.rbac.authorization.k8s.io/linkerd-heartbeat created rolebinding.rbac.authorization.k8s.io/linkerd-heartbeat created clusterrole.rbac.authorization.k8s.io/linkerd-heartbeat created clusterrolebinding.rbac.authorization.k8s.io/linkerd-heartbeat created serviceaccount/linkerd-heartbeat created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created serviceaccount/linkerd-proxy-injector created secret/linkerd-proxy-injector-k8s-tls created mutatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-proxy-injector-webhook-config created configmap/linkerd-config created secret/linkerd-identity-issuer created configmap/linkerd-identity-trust-roots created service/linkerd-identity created service/linkerd-identity-headless created deployment.apps/linkerd-identity created service/linkerd-dst created service/linkerd-dst-headless created service/linkerd-sp-validator created service/linkerd-policy created service/linkerd-policy-validator created deployment.apps/linkerd-destination created cronjob.batch/linkerd-heartbeat created deployment.apps/linkerd-proxy-injector created service/linkerd-proxy-injector created secret/linkerd-config-overrides created
Kubernetes will start spinning up the data plane components and you should see the following when you list the pods:
kubernetes-api -------------- can initialize the client can query the Kubernetes API
kubernetes-version ------------------ is running the minimum Kubernetes API version is running the minimum kubectl version
linkerd-existence ----------------- 'linkerd-config' config map exists heartbeat ServiceAccount exist control plane replica sets are ready no unschedulable pods control plane pods are ready cluster networks contains all pods cluster networks contains all services
linkerd-config -------------- control plane Namespace exists control plane ClusterRoles exist control plane ClusterRoleBindings exist control plane ServiceAccounts exist control plane CustomResourceDefinitions exist control plane MutatingWebhookConfigurations exist control plane ValidatingWebhookConfigurations exist proxy-init container runs as root user if docker container runtime is used
linkerd-identity ---------------- certificate config is valid trust anchors are using supported crypto algorithm trust anchors are within their validity period trust anchors are valid for at least 60 days issuer cert is using supported crypto algorithm issuer cert is within its validity period issuer cert is valid for at least 60 days issuer cert is issued by the trust anchor
linkerd-webhooks-and-apisvc-tls ------------------------------- proxy-injector webhook has valid cert proxy-injector cert is valid for at least 60 days sp-validator webhook has valid cert sp-validator cert is valid for at least 60 days policy-validator webhook has valid cert policy-validator cert is valid for at least 60 days
linkerd-version --------------- can determine the latest version cli is up-to-date
control-plane-version --------------------- can retrieve the control plane version control plane is up-to-date control plane and cli versions match
linkerd-control-plane-proxy --------------------------- control plane proxies are healthy control plane proxies are up-to-date control plane proxies and cli versions match
Status check results are
Everything looks good.Setting up the Viz ExtensionAt this point, the required components for the service mesh are setup, but let s also install the viz extension, which provides a good visualization capabilities that will come in handy subsequently. Once again, linkerd uses the same pattern for installing the extension.
$ linkerd viz install kubectl apply -f - namespace/linkerd-viz created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-viz-metrics-api created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-viz-metrics-api created serviceaccount/metrics-api created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-viz-prometheus created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-viz-prometheus created serviceaccount/prometheus created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-viz-tap created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-viz-tap-admin created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-viz-tap created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-viz-tap-auth-delegator created serviceaccount/tap created rolebinding.rbac.authorization.k8s.io/linkerd-linkerd-viz-tap-auth-reader created secret/tap-k8s-tls created apiservice.apiregistration.k8s.io/v1alpha1.tap.linkerd.io created role.rbac.authorization.k8s.io/web created rolebinding.rbac.authorization.k8s.io/web created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-viz-web-check created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-viz-web-check created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-viz-web-admin created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-viz-web-api created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-viz-web-api created serviceaccount/web created server.policy.linkerd.io/admin created authorizationpolicy.policy.linkerd.io/admin created networkauthentication.policy.linkerd.io/kubelet created server.policy.linkerd.io/proxy-admin created authorizationpolicy.policy.linkerd.io/proxy-admin created service/metrics-api created deployment.apps/metrics-api created server.policy.linkerd.io/metrics-api created authorizationpolicy.policy.linkerd.io/metrics-api created meshtlsauthentication.policy.linkerd.io/metrics-api-web created configmap/prometheus-config created service/prometheus created deployment.apps/prometheus created service/tap created deployment.apps/tap created server.policy.linkerd.io/tap-api created authorizationpolicy.policy.linkerd.io/tap created clusterrole.rbac.authorization.k8s.io/linkerd-tap-injector created clusterrolebinding.rbac.authorization.k8s.io/linkerd-tap-injector created serviceaccount/tap-injector created secret/tap-injector-k8s-tls created mutatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-tap-injector-webhook-config created service/tap-injector created deployment.apps/tap-injector created server.policy.linkerd.io/tap-injector-webhook created authorizationpolicy.policy.linkerd.io/tap-injector created networkauthentication.policy.linkerd.io/kube-api-server created service/web created deployment.apps/web created serviceprofile.linkerd.io/metrics-api.linkerd-viz.svc.cluster.local created serviceprofile.linkerd.io/prometheus.linkerd-viz.svc.cluster.local created
A few seconds later, you should see the following in your pod list:
The viz components live in the linkerd-viz namespace.You can now checkout the viz dashboard:
$ linkerd viz dashboard Linkerd dashboard available at: http://localhost:50750 Grafana dashboard available at: http://localhost:50750/grafana Opening Linkerd dashboard in the default browser Opening in existing browser session.
The Meshed column indicates the workload that is currently integrated with the Linkerd control plane. As you can see, there are no application deployments right now that are running.Injecting the Linkerd Data Plane componentsThere are two ways to integrate Linkerd to the application containers:1 by manually injecting the Linkerd data plane components 2 by instructing Kubernetes to automatically inject the data plane componentsInject Linkerd data plane manuallyLet s try the first option. Below is a simple nginx-app that I will deploy into the cluster:
Back in the viz dashboard, I do see the workload deployed, but it isn t currently communicating with the Linkerd control plane, and so doesn t show any metrics, and the Meshed count is 0:Looking at the Pod s deployment YAML, I can see that it only includes the nginx container:
Let s directly inject the linkerd data plane into this running container. We do this by retrieving the YAML of the deployment, piping it to linkerd cli to inject the necessary components and then piping to kubectl apply the changed resources.
Back in the viz dashboard, the workload now is integrated into Linkerd control plane.Looking at the updated Pod definition, we see a number of changes that the linkerd has injected that allows it to integrate with the control plane. Let s have a look:
At this point, the necessary components are setup for you to explore Linkerd further. You can also try out the jaeger and multicluster extensions, similar to the process of installing and using the viz extension and try out their capabilities.Inject Linkerd data plane automaticallyIn this approach, we shall we how to instruct Kubernetes to automatically inject the Linkerd data plane to workloads at deployment time.We can achieve this by adding the linkerd.io/inject annotation to the deployment descriptor which causes the proxy injector admission hook to execute and inject linkerd data plane components automatically at the time of deployment.
This annotation can also be specified at the namespace level to affect all the workloads within the namespace. Note that any resources created before the annotation was added to the namespace will require a rollout restart to trigger the injection of the Linkerd components.Uninstalling LinkerdNow that we have walked through the installation and setup process of Linkerd, let s also cover how to remove it from the infrastructure and go back to the state prior to its installation.The first step would be to remove extensions, such as viz.
Since people are sometimes slightly surprised that you can go onto a
multi week trip with a smartphone running free sofware so only I
wanted to share some impressions from my recent trip to Prizren/Kosovo
to attend Debconf 22 using a Librem 5. It's a mix of things that
happend and bits that got improved to hopefully make things more fun
to use. And, yes, there won't be any big surprises like being stranded
without the ability to do phone calls in this read because there
weren't and there shouldn't be.
After two online versions Debconf 22 (the annual Debian Conference)
took place in Prizren / Kosovo this year and I sure wanted to go.
Looking for options I settled for a train trip to Vienna, to meet
there with friends and continue the trip via bus to Zagreb,
then switching to a final 11h direct bus to Prizren.
When preparing for the trip and making sure my Librem 5 phone has all the
needed documents I noticed that there will be quite some PDFs to show
until I arrive in Kosovo: train ticket, bus ticket, hotel reservation,
and so on. While that works by tapping unlocking the phone, opening
the file browser, navigating to the folder with the PDFs and showing
it via evince this looked like a lot of steps to repeat. Can't we have
that information on the Phone Shell's lockscreen?
This was a good opportunity to see if the upcoming plugin
infrastructure for the lock screen (initially meant to allow for a
plugin to show upcoming events) was flexible enough, so I used some
leisure time on the train to poke at this and just before I reached
Vienna I was able to use it for the first
time. It was the
very last check of that ticket, it also was a bit of cheating since
I didn't present the ticket on the phone itself but from phosh (the
phones graphical shell) running on my laptop but still.
This was possible since phosh is written in GTK and so I could
just leverage evince's EvView. Unfortunately the hotel check in
didn't want to see any documents .
For the next day I moved the code over to the Librem 5 and (being a
bit nervous as the queue to get on the bus was quite long) could
happily check into the Flixbus by presenting the barcode to the
barcode reader via the Librem 5's lockscreen.
When switching to the bus to Prizren I didn't get to use that feature
again as we bought the tickets at a counter but we got a nice krem
banana after entering the bus - they're not filled with jelly, but
krem - a real Kosovo must eat!).
Although it was a rather long trip we had frequent breaks and I'd
certainly take the same route again. Here's a photo of Prizren
taken on the Librem 5 without any additional postprocessing:
What about seeing the conference schedule on the phone? Confy(a
conferences schedule viewer using GTK and libhandy) to the rescue:
Since Debian's confy maintainer was around too, confy saw a bunch of
improvements over the conference.
For getting around Puremaps(an application to display maps and
show routing instructions) was very helpful, here geolocating me
in Prizren via GPS:
Puremaps currently isn't packaged in Debian but there's work
onging to fix that (I used the flatpak for the moment).
We got ourselves sim cards for the local phone network. For some
reason mine wouldn't work (other sim cards from the same operator
worked in my phone but this one just wouldn't). So we went to the sim card
shop and the guy there was perfectly able to operate the Librem 5
without further explanation (including making calls, sending USSD codes
to query balance, ).
The sim card problem turned out to be a problem on the operator side
and after a couple of days they got it working.
We had nice, sunny weather about all the time. That made me switch
between high contrast mode (to read things in bright sunlight) and
normal mode (e.g. in conference rooms) on the phone quite
often. Thankfully we have a ambient light sensor in the phone so we
can make that automatic.
See here for a video.
Jathan kicked off a DebianOnMobile sprint during the conference
where we were able to improve several aspects of mobile support in
Debian and on Friday I had the chance to give a talk about the state
of Debian on smartphones. pdf-presenter-console is a great
tool for this as it can display the current slide together with
additional notes. I needed some hacks to make it fit the phone screen
but hopefully we figure out a way to have this by default.
I had two great weeks in Prizren. Many thanks to the organizers of
Debconf 22 - I really enjoyed the conference.
phosh is graphical shell for mobile, touch based devices like
smart phones. It's the default graphical shell on Purism's
Librem 5 (and that's where
it came to life) but projects like postmarketOS,
Mobian and
Debian have picked it up
putting it into use on other devices as well and contributing patches.
This post is meant as a short overview how things are tied together so
further posts can provide more details.
A PHone SHell
As mobile shell phosh provides the interface components commonly
found on mobile devices to
launch applications
switch between running applications and close them
lock and unlock the screen
display status information (e.g. network connectivity, battery level)
provide quick access to things like torch or Bluetooth
show notifications
It uses
GObject object system and
GTK to build up the user
interface components. Mobile specific patterns are brought in via
libhandy.
Since phosh is meant to blend into GNOME as seamlessly as possible it
uses the common interfaces present there via
D-Bus like
org.gnome.Screensaver or org.gnome.keyring.SystemPrompter and
retrieves user configuration like keybindings via
GSettings from preexisting
schema.
The components of a running graphical session roughly look like this:
The blue boxes are the very same found on GNOME desktop sessions
while the white ones are currently only found on
phones.
feedbackd is explained
quickly: It's used for providing haptic or visual user feedback and
makes your phone rumble and blink when applications (or the shell)
want to notify the user about certain events like incoming phone calls
or new messages. What about phoc and squeekboard?
phoc and squeekboard
Although some stacks combine the graphical shell with the display server
(the component responsible for drawing applications and handling user
input) this isn't the case for phosh. phosh relies on a
Wayland
compositor to be present for that. Keeping shell and compositor apart
has some advantages like being able to restart the shell without
affecting other applications but also adds the need for some
additional communication between compositor and shell. This additional
communication is implemented via Wayland protocols. The Wayland
compositor used with phosh is called
phoc for PHone
Compositor.
One of these additional protocols is wlr-layer-shell.
It allows the shell to reserve space on the screen that is not used
by other applications and allows it to draw things like the top and
bottom bar or lock screen. Other protocols used by phosh (and hence implemented by phoc) are
wlr-output-management
to get information on and control properties of monitors or
wlr-foreign-toplevel-management
to get information about other windows on the display. The later
is used to allow to switch between running applications.
However these (and other) Wayland protocols are not implemented in
phoc from scratch. phoc leverages the
wlroots library for that. The library
also handles many other compositor parts like interacting with the
video and input hardware.
The details on how phoc actually puts things up on the screen deserves
a separate post. For the moment it's sufficient to note that phosh
requires a Wayland compositor like phoc.
We've not talked about entering text without a physical keyboard yet -
phosh itself does not handle that either.
squeekboard is the on
screen keyboard for text (and emoji) input. It again uses Wayland
protocols to talk to the Wayland compositor and it's (like phosh) a
component that wants exclusive access to some areas of the screen
(where the keyboard is drawn) and hence leverages the layer-shell
protocol. Very roughly speaking it turns touch input in that area into
text and sends that back to the compositor that then passes it back to
the application that currently gets the text input. squeekboard's main
author dcz has some more details
here.
The session
So how does the graphical session in the picture above come into existence?
As this is meant to be close to a regular GNOME session it's done via
gnome-session that is
invoked somewhat like:
phoc -E 'gnome-session --session=phosh'
So the compositor phoc is started up, launches gnome-session which
then looks at phosh.session for the session's components. These are
phosh, squeekboard and gnome-settings-daemon.
These then either connect to already running services via D-Bus
(e.g. NetworkManager, ModemManager, ...) or spawn them via D-Bus
activation when required (e.g. feedbackd).
Calling conventions
So when talking about phosh it's good to keep several things apart:
phosh - the graphical shell
phoc - the compositor
squeekboard - the on screen keyboard
phosh.session: The session that ties these and GNOME together
On top of that people sometimes refer to 'Phosh' as the software
collection consisting of the above plus more components from GNOME
(Settings, Contacs, Clocks, Weather, Evince, ...) and components that
currently aren't part of GNOME but adapt to small screen sizes, use
the same technologies and are needed to make a phone fun to use
e.g. Geary for email, Calls for making phone calls and Chats for SMS
handling.
Since just overloading the term Phosh is confusing GNOME/Phosh
Mobile Environment or Phosh Mobile Environment have been used
to describe the above collection of software and I've contacted GNOME on how to name
this properly, to not infringe on the GNOME trademark but also give proper credit
and hopefully being able to move things upstream that can live upstream.
That's it for a start. phosh's development documentation can be
browsed here but is
also available in the source code.
Besides the projects mentioned above credits go to
Purism for allowing me and others to work on the
above and other parts related to moving Free Software on mobile Linux
forward.