An anonymous reader quotes a report from ZDNet: In May 2019, South Korea's Interior Ministry announced plans to look into switching to the Linux desktop from Windows. It must have liked what it saw. According to the Korean news site Newsis, the South Korean Ministry of Strategy and Planning has announced the government is exploring moving most of its approximately 3.3 million Windows computers to Linux. The reason for this is simple. It's to reduce software licensing costs and the government's reliance on Windows. As Choi Jang-hyuk, the head of the Ministry of Strategy and Finance, said, "We will resolve our dependency on a single company while reducing the budget by introducing an open-source operating system."

How much? South Korean officials said it would cost 780 billion won (about $655 million) to move government PCs from Windows 7 to Windows 10. [...] Windows will still have a role to play for now on South Korean government computers. As the Aju Business Daily, a South Korean business news site, explained: Government officials currently use two physical, air-gapped PCs. One is external for internet use, and the other is internal for intranet tasks. Only the external one will use a Linux-based distro. Eventually, by 2026, most civil servants will use a single Windows-powered laptop. On that system, Windows will continue to be used for internal work, while Linux will be used as a virtual desktop via a Linux-powered cloud server. This looks to eventually end up as a Desktop-as-a-Service (DaaS) model. The report notes that the Ministry of National Defense and National Police Agency are already using the Ubuntu Linux 18.04 LTS-based Harmonica OS 3.0.

"Meanwhile, the Korean Postal Service division is moving to TMaxOS," reports ZDNet. "The Debian Linux-based South Korean Gooroom Cloud OS is also being used by Defense and the Ministry of Public Administration and Security."

This week a remotely-exploitable vulnerability (granting root privileges) was discovered in OpenSMTPD (OpenBSD's implementation of server-side SMTP).

ZDNet notes that the library's "portable" version "has also been incorporated into other OSes, such as FreeBSD, NetBSD, and some Linux distros, such as Debian, Fedora, Alpine Linux, and more." To exploit this issue, an attacker must craft and send malformed SMTP messages to a vulnerable server... OpenSMTPD developers have confirmed the vulnerability and released a patch earlier Wednesday -- OpenSMTPD version 6.6.2p1...

The good news is that the bug was introduced in the OpenSMTPD code in May 2018 and that many distros may still use older library versions, not affected by this issue. For example, only in-dev Debian releases are affected by this issue, but not Debian stable branches, which ship with older OpenSMTPD versions.

Technical details and proof of concept exploit code are available in the Qualys CVE-2020-7247 security advisory.
Hackaday has a more detailed description of the vulnerability, while the Register looks at the buggy C code.

Interestingly, Qualys researchers exploited this vulnerability using a technique from the Morris Worm of 1988.

"I've grown quite fond of the docker container runtime. It's easy to install and use, and many of the technologies I write about depend upon this software," writes TechRepublic/Linux.com contributor Jack Wallen.

"But Red Hat has other plans." The company decided -- seemingly out of the blue -- to drop support for the docker runtime engine. In place of docker came Podman. When trying to ascertain why Red Hat split with Docker, nothing came clear. Sure, I could easily draw the conclusion that Red Hat had grown tired of the security issues surrounding Docker and wanted to take matters in their own hands. There was also Red Hat's issue with "no big fat daemons." If that's the case, how do they justify their stance on systemd?

Here's where my tinfoil hat comes into play. Understand this is pure conjecture here and I have zero facts to back these claims up... Red Hat is now owned by IBM. IBM was desperate to gain serious traction within the cloud. To do that, IBM needed Red Hat, so they purchased the company. Next, IBM had to score a bit of vendor lock-in. Using a tool like docker wouldn't give them that lock-in. However, if Red Hat developed and depended on their own container runtime, vendor lock-in was attainable....

Red Hat has jettisoned a mature, known commodity for a less-mature, relatively unknown piece of software -- without offering justification for the migration.... Until Red Hat offers up a sound justification for migrating from the docker container engine to Podman, there's going to be a lot of people sporting tinfoil hats. It comes with the territory of an always-connected world. And if it does turn out to be an IBM grab for vendor lock-in, there'll be a lot of admins migrating away from RHEL/CentOS to the likes of Ubuntu Server, SUSE/openSUSE, Debian, and more.
Red Hat's product manager of containers later touted Podman's ability to deploy containers without root access privileges in an interview with eWeek. "We felt the sum total of its features, as well as the project's performance, security and stability, made it reasonable to move to 1.0. Since Podman is set to be the default container engine for the single-node use case in Red Hat Enterprise Linux 8, we wanted to make some pledges about its supportability."

And a Red Hat spokesperson also shared their position with The New Stack. "We saw our customer base wanting the container runtime lifecycle baked-in to the OS or in delivered tandem with OpenShift."

Long-time Slashdot reader twocows writes: Hyperbola GNU/Linux, a FSF-approved distribution of GNU/Linux, has declared their intent to fork OpenBSD and become HyperbolaBSD..."
The news came earlier this week in a roadmap announcement promising "a completely new OS derived from several BSD implementations" (though Hyperbola was originally based on Arch snapshots and Debian development).

"This was not an easy decision to make, but we wish to use our time and resources to create a viable alternative to the current operating system trends which are actively seeking to undermine user choice and freedom." In 2017 Hyperbola dropped its support for systemd -- but its concerns go far beyond that: This will not be a "distro", but a hard fork of the OpenBSD kernel and userspace including new code written under GPLv3 and LGPLv3 to replace GPL-incompatible parts and non-free ones.

Reasons for this include:

- Linux kernel forcing adaption of DRM, including HDCP.

- Linux kernel proposed usage of Rust (which contains freedom flaws and a centralized code repository that is more prone to cyber attack and generally requires internet access to use.)

- Linux kernel being written without security and in mind. (KSPP is basically a dead project and Grsec is no longer free software)

- Many GNU userspace and core utils are all forcing adaption of features without build time options to disable them. E.g. (PulseAudio / SystemD / Rust / Java as forced dependencies....)

HyperbolaBSD is intended to be modular and minimalist so other projects will be able to re-use the code under free license.

DevNull127 writes: The Debian Project has announced the results of its vote on how much to support non-systemd init systems. The eight options voted on included "Focus on systemd" and "Support for multiple init systems is required" (as well as milder choices like "Support for multiple init systems is Important" and "Support non-systemd systems, without blocking progress.") The winning option?

"Systemd but we support exploring alternatives."

Here's the position for the Debian project described by that option:

The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features.

Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.

Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.

Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.

"It's been five years already since the vote to transition to systemd in Debian over Upstart," reports Phoronix, noting that the Debian developer community has now begun a 20-day ranked-choice vote on eight different proposals for "'init system diversity' and just how much Debian developers care (or not) in supporting alternatives to systemd."

The eight options they're voting on:

• Choice 1: F: Focus on systemd

• Choice 2: B: Systemd but we support exploring alternatives

• Choice 3: A: Support for multiple init systems is Important

• Choice 4: D: Support non-systemd systems, without blocking progress

• Choice 5: H: Support portability, without blocking progress

• Choice 6: E: Support for multiple init systems is Required

• Choice 7: G: Support portability and multiple implementations

• Choice 8: Further Discussion

There's detailed descriptions of each option on the Debian developers mailing list. "This is a non-secret vote," the post explains. "After the voting period is over the details on who voted what will be published."

An anonymous reader writes: Security researchers found a new vulnerability allowing potential attackers to hijack VPN connections on affected *NIX devices and inject arbitrary data payloads into IPv4 and IPv6 TCP streams. They disclosed the security flaw tracked as CVE-2019-14899 to distros and the Linux kernel security team, as well as to others impacted such as Systemd, Google, Apple, OpenVPN, and WireGuard. The vulnerability is known to impact most Linux distributions and Unix-like operating systems including FreeBSD, OpenBSD, macOS, iOS, and Android. A currently incomplete list of vulnerable operating systems and the init systems they came with is available below, with more to be added once they are tested and found to be affected: Ubuntu 19.10 (systemd), Fedora (systemd), Debian 10.2 (systemd), Arch 2019.05 (systemd), Manjaro 18.1.1 (systemd), Devuan (sysV init), MX Linux 19 (Mepis+antiX), Void Linux (runit), Slackware 14.2 (rc.d), Deepin (rc.d), FreeBSD (rc.d), and OpenBSD (rc.d).

This security flaw "allows a network adjacent attacker to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website," according to William J. Tolley, Beau Kujath, and Jedidiah R. Crandall, Breakpointing Bad researchers at University of New Mexico. "Additionally, we are able to determine the exact seq and ack numbers by counting encrypted packets and/or examining their size. This allows us to inject data into the TCP stream and hijack connections," the researchers said.

Long-time Slashdot reader jaromil (Denis "Jaromil" Roio) writes: A few days ago Devuan ASCII 2.1 was announced and one update has been overlooked by most media outlets: our dbus patch to re-generate machine-id at every boot.

This patch matters for everyone's privacy and I hope more distributions will follow our example, let alone Debian. We are dealing with important privacy implications: non-consensual user tracking is illegal in many countries and is not even mentioned in the machine-id documentation so far.
"In theory, the machine-id should be a persistent identifier of the current host," explains the README documentation. "In practice, this causes some privacy concerns..."

Debian "is heading toward a new general resolution to decide at what level init systems other than systemd should be supported," reports LWN.net.

"I'm absolutely convinced we've reached a point where in order to respect the people trying to get work done, we need to figure out where we are as a project," writes Debian project leader Sam Hartman. "We can either decide that this is work we want to facilitate, or work that we as a project decide is not important."

LWN.net reports: The immediate motivation for a reconsideration would appear to be the proposed addition of elogind, a standalone fork of the systemd-logind daemon, to Debian. Elogind would provide support for systemd's D-Bus-based login mechanism -- needed to support small projects like the GNOME desktop -- without the need for systemd itself. The addition of elogind has been controversial; it is a difficult package to integrate for a number of reasons. Much of the discussion has evidently been carried out away from the mailing lists, but some context on the problem can be found in this bug report. In short: merging elogind appears to be complex enough that it would be hard to justify in the absence of a strong commitment to the support of non-systemd init systems. It seems possible that this commitment no longer exists across the distribution as a whole; the purpose of a general resolution would be to determine whether that is the case or not.

Unsurprisingly, Debian developers have a variety of opinions on this issue. This response from Russ Allbery is worth reading in its entirety. He argues that the 2014 decision (of which he was a part) never really nailed down the project's position toward other init systems. That was a necessary compromise at the time, he said, but it is causing stress now: "while I feel somewhat vindicated by the fact that this didn't immediately fall apart and has sort of worked, I think it's becoming increasingly untenable".... Josh Triplett zeroed in on one of the issues that is testing the init-system peace now. There is, he said, an increasingly long list of features that are only available with systemd, and application developers want to use those features... The responses to this argument took a couple of different approaches. Ted Ts'o described those features as "the 'embrace, extend, and extinguish' phenomenon of systemd which caused so much fear and loathing."
There's much more information in LWN.net's 1,600-word article -- but where do things stand now? Hartman posted a draft general resolution last week with three choices.

• Affirm init diversity
• Support "exploring" alternatives to systemd, "but believing sysvinit is a distraction in achieving that." [Marco d'Itri later noted that less than 1% of new installs use sysvinit]
• "Systemd without diversity as a priority." There would be no requirement to support anything but systemd in Debian.

"It should be noted, though, that this is explicitly a draft," concludes LWN.net. "It is likely to evolve considerably before it reaches the point where the project will vote on it."

Long-time Slashdot reader ttsiod works for the European Space Agency as an embedded software engineer. He writes: After reading an interesting article from an NVIDIA engineer about how he used a dirt-cheap field-programmable gate array board to code a real-time ray-tracer, I got my hands on the same board -- and "compiled" a dual-core SPARC-compatible CPU inside it... Basically, the same kind of design we fly in the European Space Agency's satellites.

I decided to document the process, since there's not much material of that kind available. I hope it will be an interesting read for my fellow Slashdotters -- showcasing the trials and tribulations faced by those who prefer the Open-Source ways of doing things... Just read it and you'll see what I mean.
This is the same Slashdot reader who in 2016 reverse engineered his Android tablet so he could run a Debian chroot inside it. "Please remember that I am a software developer, not a HW one," his new essay warns.

"I simply enjoy fooling around with technology like this."

On Tuesday Purism announced their first Librem 5 smartphones were rolling off the assembly line and heading to customers. "Seeing the amazing effort of the Purism team, and holding the first fully functioning Librem 5, has been the most inspirational moment of Purism's five year history," said their founder and CEO Todd Weaver.

On Wednesday they posted a video announcing that the phones were now shipping, and Friday they posted a short walk-through video. "The crowdsourced $700 Linux phone is actually becoming a real product," reports Ars Technica: Purism's demand that everything be open means most of the major component manufacturers were out of the question. Perhaps because of the limited hardware options, the internal construction of the Librem 5 is absolutely wild. While smartphones today are mostly a single mainboard with every component integrated into it, the Librem 5 actually has a pair of M.2 slots that house full-size, off-the-shelf LTE and Wi-Fi cards for connectivity, just like what you would find in an old laptop. The M.2 sockets look massive on top of the tiny phone motherboard, but you could probably replace or upgrade the cards if you wanted...

[Y]ou're not going to get cutting-edge hardware at a great price with the Librem 5. That's not the point, though. The point is that you are buying a Linux phone, with privacy and open source at the forefront of the design. There are hardware kill switches for the camera, microphone, WiFi/Bluetooth, and baseband on the side of the phone, ensuring none of the I/O turns on unless you want it to. The OS is the Free Software Foundation-endorsed PureOS, a Linux distribution that, in this case, has been reworked with a mobile UI. Purism says it will provide updates for the "lifetime" of the device, which would be a stark contrast to the two years of updates you get with an Android phone.

PureOS is a Debian-based Linux distro, and on the Librem 5, you'll get to switch between mobile versions of the Gnome and KDE environments. If you're at all interested in PureOS, Purism's YouTube page is worth picking through. Dozens of short videos show that, yes, this phone really runs full desktop-class Linux. Those same videos show the dev kit running things like the APT package manager through a terminal, a desktop version of Solitaire, Emacs, the Gnome disk utility, DOSBox, Apache Web Server, and more. If it runs on your desktop Linux computer, it will probably run on the Librem 5, albeit with a possibly not-touch-friendly UI. The Librem 5 can even be hooked up to a monitor, keyboard, and mouse, and you can run all these Linux apps with the normal input tools...

Selling a smartphone is a cutthroat business, and we've seen dozens of companies try and fail over the years. Purism didn't just survive long enough to ship a product -- it survived in what is probably the hardest way possible, by building a non-Android phone with demands that all the hardware components use open code. Making it this far is an amazing accomplishment.

"Debian Project Leader Sam Hartman has shared his August 2019 notes where he outlines the frustrations and issues that have come up as a result of init system diversity with some developers still aiming to viably support systemd alternatives within Debian," reports Phoronix: Stemming from elogind being blocked from transitioning to testing and the lack of clarity into that, Hartman was pulled in to try to help mediate the matter and get to the bottom of the situation with a lack of cooperation between the elogind and systemd maintainers for Debian as well as the release team. Elogind is used by some distributions as an implementation of systemd's logind, well, outside of systemd as a standalone daemon. Elogind is one of the pieces to the puzzle for trying to maintain a modern, systemd-free Linux distribution.

Various issues were raised that are trying to be worked through albeit many Debian developers face time limitations and other factors like emotional exhaustion. Hartman noted in his August notes, "I think we may be approaching a point where we need to poll the project -- to have a GR and ask ourselves how committed we are to the different parts of this init diversity discussion. Reaffirming our support for sysvinit and elogind would be one of the options in any such GR. If that option passed, we'd expect all the maintainers involved to work together or to appoint and empower people who could work on this issue. It would be fine for maintainers not to be involved so long as they did not block progress. And of course we would hold the discussions to the highest standards of respect."

diegocg writes: Linux 5.2 has been released. This release includes Sound Open Firmware, a project that brings open source firmware to DSP audio devices; open firmware for many Intel products is also included. This release also improves the Pressure Stall Information resource monitoring to make it usable by Android; the mount API has been redesigned with new syscalls; the BFQ I/O scheduler has gained some performance improvements; a new CLONE_PIDFD flag lets clone(2) return pidfs usable by pidfd_send_signal(2); Ext4 has gained support for case-insensitive name lookups; there is also a new device mapper target that simulates a device that has failing sectors and/or read failures; open source drivers for the ARM Mali t4xx and newer 6xx/7xx have been added. Many other new drivers, features and changes can be found in the changelog.
But there's more besides supporting "a handful of extra ARM-powered single-board computers," according to CRN: The biggest feature in 5.2 is probably support for Intel's forthcoming Comet Lake architecture, which will power the tenth generation of its Core desktop and mobile CPUs due. The new silicon is due to ship late in 2019 and appear in products early the next year.

Linux 5.2 also includes many tweaks that improve its performance on laptops.

"After 25 months of development the Debian project is proud to present its new stable version 10 (code name 'buster'), which will be supported for the next 5 years thanks to the combined work of the Debian Security team and of the Debian Long Term Support team."

An anonymous reader quotes Debian.org: In this release, GNOME defaults to using the Wayland display server instead of Xorg. Wayland has a simpler and more modern design, which has advantages for security. However, the Xorg display server is still installed by default and the default display manager allows users to choose Xorg as the display server for their next session.

Thanks to the Reproducible Builds project, over 91% of the source packages included in Debian 10 will build bit-for-bit identical binary packages. This is an important verification feature which protects users against malicious attempts to tamper with compilers and build networks. Future Debian releases will include tools and metadata so that end-users can validate the provenance of packages within the archive.

For those in security-sensitive environments AppArmor, a mandatory access control framework for restricting programs' capabilities, is installed and enabled by default. Furthermore, all methods provided by APT (except cdrom, gpgv, and rsh) can optionally make use of "seccomp-BPF" sandboxing. The https method for APT is included in the apt package and does not need to be installed separately... Secure Boot support is included in this release for amd64, i386 and arm64 architectures and should work out of the box on most Secure Boot-enabled machines.
The announcement touts Debian's "traditional wide architecture support," arguing that it shows Debian "once again stays true to its goal of being the universal operating system." It ships with several desktop applications and environments, including the following:

• Cinnamon 3.8

• GNOME 3.30

• KDE Plasma 5.14

• LXDE 0.99.2

• LXQt 0.14

• MATE 1.20

• Xfce 4.12

"If you simply want to try Debian 10 'buster' without installing it, you can use one of the available live images which load and run the complete operating system in a read-only state via your computer's memory... Should you enjoy the operating system you have the option of installing from the live image onto your computer's hard disk."

Microsoft's transformation into a fully paid-up member of the Linux love-train continued this week as the Windows giant sought to join the exclusive club that is the official linux-distros mailing list. From a report: The purpose of the linux-distros list is used by Linux distributions to privately report, coordinate, and discuss security issues yet to reach the general public; oss-security is there for stuff that is already out in the open or cannot wait for things to bounce around for a few days first. Sasha Levin, who describes himself as a "Linux kernel hacker" at the beast of Redmond, made the application for his employer to join the list, which if approved would allow Microsoft to tap into private behind-the-scenes chatter about vulnerabilities, patches, and ongoing security issues with the open-source kernel and related code.

These discussions are crucial for getting an early heads up, and coordinating the handling and deployment of fixes before they are made public. To demonstrate that Microsoft qualifies for membership alongside the likes of Ubuntu, Debian, and SUSE, he cited Microsoft's Azure Sphere and the Windows Subsystem For Linux (WSL) 2 as examples of distro-like builds.

An anonymous reader quotes a report from ZDNet: Russian authorities have moved closer to implementing their plan of replacing the Windows OS on military systems with a locally-developed operating system named Astra Linux. Last month, the Russian Federal Service for Technical and Export Control (FSTEC) granted Astra Linux the security clearance of "special importance," which means the OS can now be used to handle Russian government information of the highest degree of secrecy. Until now, the Russian government had only used special versions of Windows that had been modified, checked, and approved for use by the FSB. Astra Linux is a Debian derivative developed by Russian company RusBITech since 2008, the report says. "RusBITech initially developed the OS for use in the Russian private market, but the company also expanded into the local government sector, where it became very popular with military contractors."

"DEVUAN.ORG HAS BEEN PWNED" reads a new message at the home page for Devuan (a fork of Debian without systemd) -- which re-redirects to a new page named pwned.html, reports Slashdot reader DevNull127: In all capital letters, its carefully-indented message (complete with an ascii-art logo) now informs visitors that "the web sucks -- JavaScript sucks -- browsers suck." Posting the URLs to several gopher sites, it adds that "Gopher is the way -- gopher is the future."

"Kiss port 80 goodbye. Join the revolution on port 70."
The attackers identify themselves as "Green Hat Hackers," a term generally understood to mean ambitious newbie hackers who want to improve their skills. "Stop the madness," continues their message, which appeared just hours before the first day of April.

"Get yourself a gopher client."

Five candidates now are running to be Debian's project leader for the coming year. But earlier this week, Slashdot reader Seven Spirals shared LWN's story about what a difficult election it's been: This year, the call for nominations was duly sent out by project secretary Kurt Roeckx on March 3. But, as of March 10, no eligible candidates had put their names forward... There is nobody there to do any campaigning.

This being Debian, the constitution naturally describes what is to happen in this situation: the nomination period is extended for another week... Should this deadline also pass without candidates, it will be extended for another week; this loop will repeat indefinitely until somebody gives in and submits their name... In the absence of a project leader, the chair of the technical committee and the project secretary are empowered to make decisions -- as long as they are able to agree on what those decisions should be. Since Debian developers are famously an agreeable and non-argumentative bunch, there should be no problem with that aspect of things...

One might well wonder, though, why there seems to be nobody who wants to take the helm of this project for a year. The fact that it is an unpaid position requiring a lot of time and travel might have something to do with it. If that were indeed to prove to be part of the problem, Debian might eventually have to consider doing what a number of similar organizations have done and create a paid position to do this work.

Michael Stapelberg, maintains "a bunch" of Debian packages and services, and says the free software Linux distro "has been in my life for well over 10 years at this point."

Today he released a 2,255-word essay explaining why he's "winding down" his involvement in Debian to a minimum, citing numerous complaints including Debian's complicated build stack, waits of up to seven hours before package uploads can be installed, leading to "asynchronous" feedback -- and Debian's lack of tooling for large changes.
The closest to "sending out a change for review" is to open a bug report with an attached patch... Culturally, reviews and reactions are slow. There are no deadlines. I literally sometimes get emails notifying me that a patch I sent out a few years ago (!!) is now merged. This turns projects from a small number of weeks into many years, which is a huge demotivator for me.

Interestingly enough, you can see artifacts of the slow online activity manifest itself in the offline culture as well: I don't want to be discussing systemd's merits 10 years after I first heard about it.

Lastly, changes can easily be slowed down significantly by holdouts who refuse to collaborate. My canonical example for this is rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference. Granting so much personal freedom to individual maintainers prevents us as a project from raising the abstraction level for building Debian packages, which in turn makes tooling harder.
There's also several complaints about old infrastructure -- for example, "I dread interacting with the Debian bug tracker. debbugs is a piece of software (from 1994) which is only used by Debian and the GNU project these days." Stapelberg also complains that the "painful" experience of developing using Debian "leaves a lot to be desired," and adds that "It baffles me that in 2019, we still don't have a conveniently browsable threaded archive of mailing list discussions."

"My frustration level ultimately exceeded the threshold," Stapelberg writes in the essay, adding "I hope this post inspires someone, ideally a group of people, to improve the developer experience within Debian." He'll soon transition packages to be team-maintained "where it makes sense," but also "orphan packages where I am the sole maintainer... For all intents and purposes, please treat me as permanently on vacation..."

"I will try to keep up best-effort maintenance of the manpages.debian.org service and the codesearch.debian.net service, but any help would be much appreciated."

dryriver writes: A lot of people probably remember the 1990s palmtop computers made by Psion fondly. The clamshell-design palmtops were pocketable, black and white, but had a working stylus and a fantastic tactile foldout QWERTY keyboard that you could type pretty substantial documents on or even write code with. A different company -- Planet Computers -- has now produced a spiritual successor to the old Psion palmtops called the Gemini PDA that is much like an old Psion but with the latest Android smartphone hardware in it and a virtually identical tactile keyboard. It can also dual boot to Linux (Debian, Ubuntu, Sailfish) alongside Android. The technical specs are a MediaTek deca-core processor, 4GB RAM, 64GB storage (plus microSD slot), 4G, 802.11c Wi-Fi, GPS, Bluetooth, eSIM support, and 4,220mAh battery. The screen measures in at 5.99-inches with a 2,160 x 1,080 (403ppi) resolution. The only thing missing seems to be the stylus -- but perhaps that would have complicated manufacturing of this niche-device in its first production run.