fidzu : mobile

Look no further for all the latest Boba Story Lid Recipes. They are all right here!

24 Sep 2026 4:37am GMT

Get the latest Dice Dreams free rolls links, updated daily! Complete with a guide on how to redeem the links.

24 Sep 2026 4:37am GMT

Netflix's new reality show inspired by the infamous Stanford Prison Experiment has sparked widespread outrage online-raising a key…

23 Sep 2026 3:00pm GMT

Posted by Fahd Imtiaz, Senior Product Manager, and Loryn Hairston, Product Marketing Manager, Android Developer

Googlebook introduces a new category of laptops built on a shared Android foundation. High-performance hardware from partners such as HP, Dell, Lenovo, Acer, and Asus, combines mobile convenience with desktop power. Googlebook offers high-resolution OLED touchscreens, dedicated keyboards, and precision trackpads with all-day battery life and OS-level Gemini Intelligence. With Googlebook, users can transition fluidly from quick interactions on their phones to rich, immersive sessions on their laptop.

Bringing your app to Googlebook opens up valuable opportunities for you across the Android ecosystem. Google Play highlights optimized titles with dedicated badging, enhanced search, and featured spots across curated store homepages. Delivering this level of quality also prepares your app for the Apps Experience Program, where you can enroll to unlock a new program rate card designed to drive business growth. Even better, when users set up their new Googlebook using their Android phone, optimized apps are prominently highlighted for easy transfer, giving your app day-one presence on their new device.

Optimized for desktop badging and dedicated collections on Google Play.

The best part? You don't need to build a separate app from the ground up to take advantage of this reach. Adaptive development is how modern Android apps naturally scale across large displays, new device postures, and emerging form factors. If your app already embraces adaptive layouts, it is primed for Googlebooks. By building on your existing foundation of adaptive UI, window size classes, and multi-input support, you can deliver an optimized experience.

Adaptive layouts reorganizing mobile views into a multi-pane experience.

Anchor your app in desktop fundamentals

On a laptop, your app operates within a desktop environment where user expectations shift toward higher information density, precision input, and active multitasking. Following desktop development and design guidance provides the principles needed to make the most of this experience. Instead of simply stretching mobile interfaces across a wide screen, an adaptive layout reorganizes content into functional groupings.

Adopt a multi-pane architecture to allow your UI to expand, reflow, or reveal richer detail as window boundaries change. With Navigation 3, you can implement adaptive scene strategies to coordinate multi-pane layouts directly from your back stack. Use ListDetailSceneStrategy and SupportingPaneSceneStrategy to enable side-by-side layouts when expanded window space is available. Scene decorators let you wrap screens with persistent desktop navigation rails. Pair these patterns with layout primitives like Grid and FlexBox, and soon alongside experimental MediaQuery and Styles APIs, to organize complex content and adjust visual styles dynamically for desktop displays.

Representations of width-based window size classes.

In free-form desktop windowing, app windows can be resized dynamically at any time. Your layout decisions should respond directly to the available window space using window size classes rather than the physical display dimensions.

Desktop design also accounts for ergonomic viewing distances and precise pointer targets. Adjust your type scale for comfortable viewing across larger displays, set layout max widths to keep line lengths readable, and define explicit click targets to prevent misclicks. Explore complete design patterns in our design principles guide and discover real world inspiration in the desktop design gallery.

Deliver differentiated experiences for Googlebooks

Once your core layout is adaptive, you can enrich your app with differentiated features that take full advantage of a desktop environment. Everyday productivity in these setups relies on versatile input methods. Jetpack Compose natively supports physical keyboard navigation and pointer selection. Elevate your app's usability by integrating contextual cursors that provide visual feedback for text entry, pane resizing, and tool selection. Implement right click context menus and hover states; make your shortcuts discoverable through the Keyboard Shortcuts Helper.

Task switcher displaying multiple open windows and app instances.

On Googlebook, apps run in free-form windows where users can tackle multiple tasks simultaneously. Unlock side-by-side workflows by enabling multi-instance support, giving users the ability to launch independent windows for comparing content or managing multiple documents. Pair this with drag and drop to let users move text, images, and files fluidly between windows or even drop items onto an empty workspace to spin up a new task.

Multi-window multitasking with cross-window drag and drop.

Go all in and customize your window frame. In desktop windowing, apps include a caption header bar that you can style with custom backgrounds, search bars, or tabs while respecting system window controls.

Beyond individual app windows, Continue On keeps experiences connected across phones, tablets, and Googlebooks with bidirectional handoff that lets users start a task on one screen and pick up seamlessly on another. Passing state through HandoffActivityData preserves context such as document position or active tabs, with optional web fallbacks to ensure smooth transitions.

Complement this by surfacing actionable information at a glance with customizable widgets. And, as you refine your app experience, benchmark against our comprehensive desktop app quality guidelines.

Developers are already bringing these patterns to life across the ecosystem. When bringing Notability to Googlebook, prior investments in tablets and foldables gave the team an immediate head start. Because their layout already relied on window size classes and adaptive scene strategies, their canvas and toolbars reflowed naturally during window resizing, while existing keyboard and trackpad support carried straight over.

"We had already been targeting first-class experiences for tablets and foldables," explains Ryan Shea, Android Engineering Manager at Notability. "So by the time Googlebook came along, scaling Notability up to a laptop-class experience was mostly turning a dial we had already built. That left us free to spend our time on the things that only make sense on a bigger screen or with the newer APIs, like Continue On, which hands a note off from your phone to the laptop, and optimizing the side-by-side app experience for studying."

Accelerate your workflow with dedicated tooling

Testing and optimizing your app for Googlebook fits naturally into your existing development workflow.

With the desktop emulator in Android Studio, you can run a virtual desktop environment directly on your workstation to test free-form window resizing, verify multi-instance interactions, and debug mouse, trackpad, and keyboard interactions. Download Android Studio Canary to set up your virtual device today.

Help speed up your layout modernization with AI-assisted development. The adaptive skill gives your AI agents the necessary context to help refactor mobile layouts into responsive Compose containers automatically. Install the skill directly through the Android CLI to streamline your implementation.

Realize new possibilities on Googlebook

The Googlebook family of laptops from ecosystem partners.

The Googlebook lineup marks an exciting new chapter for the Android ecosystem, giving your apps a premium platform to deliver richer, more capable experiences. By building adaptively, a single codebase ensures your app looks and performs optimally across phones, foldables, tablets, and Googlebooks while unlocking elevated visibility and badging across Google Play. Explore documentation at our Googlebook developer hub, review the desktop design guide, and start building for Googlebook today!

22 Sep 2026 5:00pm GMT

Posted by Jan Kleinert, Developer Relations Engineer, Android for Cars

Today, the games category for Android Auto and cars powered by Android Automotive OS with Google built-in is officially graduating from beta to general availability. Our early access partners have already been bringing games to the parked-only experience for cars, and you can browse these in our latest collections of games for Android Auto and games for Android Automotive OS.

Bringing your game to cars lets you reach users in their vehicles during natural downtime, such as while waiting at a charging station or for a curbside order pickup. Today's milestone means that we're opening up access so developers can now publish games to the open testing and production tracks on Google Play. In this post, we'll cover how to adapt your existing Android game for the car screen, focusing on key technical requirements and publishing criteria.

Implement car support for your game

If you're already following best practices for building adaptive apps, bringing an existing Android game to cars primarily involves configuring your app manifest and ensuring your game respects the vehicle parked state.

Mark your app as a game

To distribute your app in the games category, you need to explicitly declare its category. Add the android:appCategory="game" attribute to the <application> element of your manifest file:

<application ... 
    android:appCategory="game">
    ...
</application>

Declare support for Android Auto

Games are supported on Android Auto on devices running Android 15 and higher. To declare that your game supports Android Auto, include this <category> element in the intent filter of an activity in your manifest file:

<activity ... 
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        ...
        <category android:name="android.intent.category.CAR_LAUNCHER" />
    </intent-filter>
</activity>

Generally, the android.intent.category.CAR_LAUNCHER category element is placed in the same intent filter as the android.intent.category.LAUNCHER element, but it can be in another activity's intent filter if you prefer to launch a different activity.

Declare support for Android Automotive OS

To declare that your game supports Android Automotive OS, include the android.hardware.type.automotive <uses-feature> element in your manifest file.

<manifest ... 
    ...
    <uses-feature android:name="android.hardware.type.automotive"
                  android:required="false" />
    ...
</manifest>

The android:required value has different restrictions depending upon which track you choose to distribute your Android Automotive OS app. If you distribute your Android Automotive OS app on the mobile track, android:required must be set to "false". However, if you distribute on the Android Automotive OS dedicated track, you can set android:required to "true", "false", or leave it unset. Leaving the value unset has the same effect as setting android:required to "true", and means that your app is available only for distribution on Android Automotive OS devices.

Handle the parked state

Cars introduce a unique physical context with a driving state and a parked state. Certain types of apps, like games, are considered parked apps and aren't permitted to run while the vehicle is in motion to avoid driver distraction. By default, Android Auto and Android Automotive OS block activities from being used or launched when the vehicle is in motion or when user experience (UX) restrictions are active. To make sure your game complies with driver distraction guidelines, don't include the distractionOptimized metadata element in any activity in your manifest. You must also ensure that your game audio stops when the user starts driving and can't be unpaused while the vehicle is in motion.

The TrivialKart for Unity sample app running on the Desktop Head Unit while in a parked state.

The behavior of a parked app when UX restrictions are active.

Additionally, when the user relaunches the app from the home screen, your game must restore the app state as closely as possible to the previous state. Test your game for responsiveness and ensure it doesn't freeze or stutter during gameplay.

Declare game controller support

Car screens support touch input, but many users prefer playing with a connected gamepad. If your game supports controller input, declare the android.hardware.gamepad feature in your manifest to help boost the visibility of your app in the Google Play Store to users specifically seeking controller-compatible experiences.

<uses-feature android:name="android.hardware.gamepad" android:required="false"/>

Set the android:required attribute to false to indicate your app supports controllers, but the use of controllers is optional. Don't set the android:required attribute to true unless a controller is mandatory for your game.

Support common screen sizes and aspect ratios

Car displays come in various shapes and aspect ratios, including portrait and wide landscape screens. For a great user experience, make your game fully adaptive to different screen sizes so that it runs full screen without letterboxing or pillarboxing. For Android Auto, refer to the guidance for testing against canonical screen sizes and use bundled hardware profiles when testing with the emulator for Android Automotive OS.

Publish your game to cars

After you've implemented the necessary changes, you can opt in to Android Auto and Android Automotive OS form factors in the Google Play Console. Before submitting to production, test your game against the car app quality guidelines for games.

Use the Desktop Head Unit to test your app's Android Auto compatibility, and use the Android Automotive OS emulator to test the experience on Android Automotive OS. Your game will be reviewed against the car app quality guidelines for the games category before it is approved for open testing or production.

Get your games on the road

With the games category now generally available, it is the perfect time to optimize your titles for cars. To learn more about implementation details, review the documentation at Build games for cars.

21 Sep 2026 4:00pm GMT

Posted by Maunik Shah, Staff Software Engineer, Alec Garcia, Software Engineer, and Joseph Yong, Technical Program Manager

At Android, we are constantly working to provide developers and enterprise partners with the data they need to keep devices protected. Today, we're thrilled to announce the stable release of the AndroidX Security State version 1.1.0 and Security State Provider version 1.0.0 libraries which provides a centralized mechanism designed to bring further transparency to the comprehensive security posture and pending updates across the Android ecosystem.

Whether you develop security-critical, consumer-facing apps (such as banking, fintech, or healthcare) or Mobile Device Management (MDM) solutions, these libraries enable you to programmatically verify the security state of the device per component. Rather than relying on a coarse, monolithic Security Patch Level (SPL), you can evaluate true component-level protection and whether remediations are actively pending via the androidx.security.state library. For OEMs and Over-The-Air (OTA) client developers, the companion androidx.security.state.provider library allows you to expose update availability via standardized mechanisms.

Understanding Security Patch Levels (SPL)

As Android has evolved to deliver rapid, independent component updates through modular systems like Google Play system updates, relying on a single SPL build property is no longer the best way to determine a device's true security posture. To provide component level visibility, the Security State libraries provide APIs for three distinct patch levels:

• Device SPL (DSPL): The security patch level currently installed and running on the device for specific system components, queried from device properties and configs without network calls.
• Published SPL (PSPL): The latest patch level officially published in the Android Security Bulletin for those components.
• Available SPL (ASPL): The patch level ready to be downloaded and installed on the specific device, queried asynchronously via inter-process communication (IPC) with on-device update clients.

The Security State libraries track these patch levels across the following components:

• System: The core Android operating system, updated via standard/OEM system OTA updates.
• System modules: Modular OS subsystems updated seamlessly in the background via Google Play system updates (Project Mainline).
• Kernel: The foundational layer connecting the device's hardware and software, evaluated via Long-Term Support (LTS) release versions (such as 5.15.159 or 6.1.91) rather than monthly calendar dates.

By surfacing these three distinct patch levels at the component level, developers and enterprises can now understand exactly how secure a device is, identify missing patches, and take proactive remediation steps. One way of doing so can be seen in the example below.

Rather than taking an all-or-nothing approach to device access, developers and enterprises can combine DSPL, PSPL, and ASPL to make smart, contextual security decisions. For example, a banking or enterprise app can compare a device's current security patch (DSPL) against pending updates (ASPL) before initiating sensitive workflows like high-value payments or credential enrollment. If an update is waiting to be installed, developers and enterprises can require the user to update their device first. For even finer control, developers and enterprises can query whether specific high-risk vulnerabilities (CVEs) have been patched on the device, such as verifying that critical NFC or Bluetooth fixes are in place before authorizing tap-to-pay or proximity data sharing.

High-level flow

For app developers and enterprise management

Client applications can use the androidx.security.state library to make informed, context-aware decisions:

• Synchronous Posture Checks (DSPL): Apps can immediately inspect the installed patch levels of the system, system modules, and kernel on app launch and compare with PSPL to verify whether the device meets an organization's required security baseline before unlocking sensitive corporate resources or biometric access.
• Pending Update Prompting (ASPL): Instead of immediately blocking an employee whose device is slightly behind on patches, enterprise apps can query ASPL to check if a pending system update or Google Play system update is staged and ready to install. If so, apps can display tailored in-app guidance directing the user to System Settings to complete the installation.
• Vulnerability-Level Auditing (CVEs): For high-assurance use cases, the library provides ability to download device-specific vulnerability reports from Open Source Vulnerabilities (OSV) to programmatically audit whether specific, critical CVEs have been resolved on the device.

For OEMs & update clients: Standardizing update availability

The companion androidx.security.state.provider library establishes a standardized, Android IPC mechanism for update clients to report update availability directly on the device. Historically, even if proprietary OTA clients surfaced update availability, this information was siloed and not queryable by third-party applications. Going forward, apps can access ASPL details through a single, unified API, regardless of whether the update is delivered via an OEM's dedicated OTA client or Google Play, as long as it is provided by the update client.

• Google Play system updates already expose ASPL across GMS Android devices.
• Google Over-The-Air (GOTA) has also been onboarded and we are working with OEMs worldwide to onboard their OTA clients to this standardized framework.

Incorporating bulletin-level data

Beyond a single SPL string, the Security State libraries provide clarity on what that patch level actually means for the device. By integrating with the Open Source Vulnerabilities (OSV) database to obtain Android Security Bulletin data, the libraries can look deeper than ever before. Instead of just asking if a specific threat, such as a CVE entry, is blocked, this data also allows the libraries to provide the "effective" and granular security state of the device.

Here are two ways this approach benefits enterprises and Android OEMs:

• Sometimes, a monthly security update does not contain any new threats for a specific component. In this case, the libraries automatically increments the security level for that component to reflect its "effective" security state. This ensures that a device is accurately credited for being fully protected against all known security threats.
• A new feature introduced in Android 17 allows OEMs to declare specific security fixes that have been applied above the SPL via a Supplemental Patches XML file. This feature allows OEMs who backport specific security fixes to immediately prove device compliance without having to wait for a full monolithic SPL bump, ensuring continuous patching efforts are properly credited. The Security State libraries surface this granular information to apps and services, ensuring that continuous patching efforts are recognized the moment they are implemented.

Get started

The Security State Libraries are built to empower the entire Android ecosystem.

• App Developers & MDMs: To start protecting your users and evaluating real-time patch posture, explore the official Understand device security state guide.
• OEMs and Update Clients: Onboard your update clients to expose ASPL using the AndroidX Security State Provider library. Claim immediate credit for backported patches by publishing Supplemental Patches XMLs.
• Release Notes: Check out the official AndroidX Release Notes for Security-State and Security-State-Provider libraries for complete changelogs and API signatures.

We value your feedback! Please try out the libraries and let us know your thoughts or report any issues on the public Android Issue Tracker.

17 Sep 2026 7:00pm GMT

Two months, one chair, and a cushion that had to be replaced - twice. This isn't a review in the strict sense. The only other chair I've used long-term is an IKEA Nominell, so I can't offer broad comparisons. What I can offer is an honest account of living with the Omni SE - plus a few observations most reviews skip.

Where I'm coming from

My background shapes what I look for in a chair, so it's worth stating up front.

I never had back problems with my old IKEA chair, but I credit that to regular exercise rather than to the chair. In my experience, exercise is by far the most effective way to prevent back pain - closely followed by changing posture throughout the day: standing up now and then and putting your leg muscles to work.

The upshot: for me, the specific chair matters less than people assume. What I value instead are quality-of-life features - freedom to move and the ability to recline deeply for a quick moment of relaxation. That's the lens I judged the Omni SE through.

The Omni chairs hardly need an introduction; they're among the most aggressively marketed chairs on social media. So rather than rehash the spec sheet (Dan Ahn's YouTube channel covers that well), I'll stick to my own experience.

Ordering

I paid the 10€ deposit, ordered on 16 June for 589€, and received the chair on 23 June - so about two months of use at the time of writing.

The 10€ "deposit" turned out to be a one-year warranty extension rather than a deposit. Fine by me.

The seat cushion problem

The downside of ordering early and cheap: at least the first batch shipped with foam that was too soft in the seat cushion.

The Omni cushion combines three foam densities, with the firmest section only near the backrest. Even that section wasn't firm enough - once the foam warmed up, you'd sink through to the plastic pan. Steve, the Anthros CEO, summarises the issue neatly - keep in mind though, that this is coming from a rival.

If you're reading this in a seemingly fine Omni and wonder what this feels like, sit on the front edge for a few minutes: the softer foam lets you bottom out. Sit with your lumbar against the backrest and you're on the firm section, where it should feel comfortable.

Customer support assured me that batches produced after early May went through improved firmness testing - which means my chair was made before that. At the time of writing, it's still unclear whether all new deliveries ship with the updated cushion. So if you'd rather not go through the hassle of getting a replacement, wait until that's confirmed.

How support handled it

Sitting with my lumbar against the backrest was exactly where the problem showed up for me, so after a few uncomfortable weeks I contacted support via email. They replied within 24 hours, and their first suggestion was that I should sit closer to the backrest. Once I confirmed I already was, they promised a revised cushion - and noted that my return window would restart on the day the replacement arrived.

A week later a new cushion arrived - the Pro version, sent by mistake. Since the correct replacement was another month out, I used the Pro cushion in the meantime; its firmer foam didn't bottom out. I also received a small compensation package for the inconvenience, including the StepSync Mat, which turned out to be surprisingly handy - more on that below.

The correct SE cushion arrived at the end of August, so at the time of writing I've used the Pro cushion for about a month and the revised SE cushion for three days.

On the two replacement cushions

The revised SE cushion is noticeably stiffer than the one my chair originally shipped with, across all three foam zones.

The Pro uses Gabriel Atlantic fabric, which the active ventilation requires because it allows more airflow. It's also more durable. The trade-off is the coarser weave: less soft and slightly scratchy compared to the standard fabric.

In terms of firmness, the two replacement cushions feel about the same to me - the fabric is the main difference. Upgrading to the Pro just for the fabric isn't worth it in my view.

Backrest and recline

The backrest is what LiberNovo builds its marketing around, and deservedly so. Sitting down for the first time, it was the most noticeable difference to my IKEA chair: it hugs you around the lumbar region and you immediately feel supported, without limiting your range of motion.

The second standout is the recline. If you've ever wanted to lie back for a moment of relaxation and quick back relief, that's what the 160° position gives you. Even at maximum recline the chair feels stable - but to be genuinely comfortable, you'll want to raise your legs. Whether that calls for the official footrest is up to you; I put the StepSync Mat on the subwoofer under my desk and called it a day.

Day to day, though, I keep the chair locked at 135° with the tension tightened up - that lets me move freely back and forth while still getting the back support.

Armrests

These get called out as a weak point, so I'll say plainly that I like them. Yes, they slide forward and backward very easily - but for me that's an advantage: I can pull up to the desk and the armrests simply move out of the way. If you prefer them to stay put, I can see it being annoying.

The one real drawback: at the two narrowest width settings they collide with the backrest unless fully extended forward.

Material-wise, the firmness and smooth surface are pleasant. Keep in mind, though, that my old chair had no armrests at all.

The standout: parts availability

The cushion swap points to what I consider LiberNovo's real strength - not the chair itself, but what you can do with it after you buy it.

Competing brands may advertise a 12-year warranty instead of six, but their spare-parts selection is very limited. With LiberNovo you can order every individual component - and, unusually, at fair prices: building an Omni SE from parts comes to €681, against €679 for the finished chair (current price). Most brands price their spares steeply enough to make that comparison absurd.

What that enables is customization: want a headrest in a different colour? Order that spare part. Worried about the motorized lumbar? Swap in the manual one from the SE.

Verdict

After two months, I'm happy with the upgrade. The Omni SE is far more comfortable than my IKEA chair, and I use the recline often - reading a book, or just taking the load off my back.

The biggest drawback is probably the fixed seat depth. You can change it later by buying the 45 cm / 48 cm cushion replacement, but that still doesn't let different people share the same chair.

LiberNovo recently extended the warranty to six years for everyone, which makes seven with my deposit. Since the SE has no electronic components, that covers the whole chair in my case.

My cushion wasn't right out of the box, and it still took two months and two shipments to sort out. But the parts availability and the support response mean you're not stuck with a problem you can't fix - and that, more than any spec, is what won me over.

I'll update this post if anything changes.

0 0

29 Aug 2026 11:27am GMT

It all started innocently enough: sometime last summer, I ran into the blog post Start your own Internet Resiliency Club on Hacker News.

…communicate with each other across a few kilometers without any centralized infrastructure using cheap, low-power, unlicensed LoRa radios and open source Meshtastic text messaging software.

The idea of a local, infrastructure-free communications mesh sounded useful, especially as we were about to sail into the Pacific.

Meshtastic

While conflicts and natural disasters are hopefully far away, on the smaller atolls there is no cellular network. With Meshtastic we could communicate over LoRa.

Over the hurricane season, the Meshtastic setup became quite extensive. Our boat has a Meshtastic node, plus a mast-mounted solar repeater. We both have Meshtastic cards that we carry with us. With these we can communicate with text messages over quite a long distance. And we get telemetry and alerts from the boat.

In Cartagena, Colombia we could hear the boat pretty much across the city. And since some of our buddy boats also run Meshtastic, we've even had conversations while offshore.

While the existing Meshtastic setup is serving us well, there is always room for improvement and new ideas.

Reticulum

Reticulum is a project that seeks to take this to a whole new level. It is a whole decentralized networking stack that allows anything from instant messaging and voice calls to full-on SSH sessions to be carried over a multitude of different interfaces. You can transport Reticulum over LoRa, Bluetooth, and also over regular TCP/IP networks. And if authorities didn't take a dim view on encryption in ham radio, it would also work over our HF radio. With store-and-forward mechanisms it can deal with intermittent connectivity.

Because your identity is portable, your connectivity can be fluid. You can be sitting at a desk connected to a fiber backbone one moment, and walking through a field connected only to a long-range LoRa mesh the next. To the rest of the network, nothing has changed. Your friends do not need to update your contact info. The messages they send do not bounce back. The network senses the shift in the medium and reroutes the flow of data automatically.
You are no longer a stationary node in a fixed grid. You are a wanderer in a fluid medium.
- The Zen of Reticulum

As it stands now, Reticulum is still quite an early system with rudimentary and tech-heavy user interfaces. But that seems to be about to change: the Columba app for Android seems about as user-friendly as Meshtastic or something like Signal. There's a lot of potential in that once it reaches a stable version.

Distributed development over Reticulum

In the meanwhile, there is one aspect of Reticulum we developers can benefit from immediately: Distributed development. With it, any rngit node running on Reticulum can be your "GitHub". Git history, issue tracking, release distribution is already there.

I recently switched my various programming projects over. We have rngit running on the boat NAS, and VPS running a mirror behind more consistent connectivity. And for now I also mirror the work periodically to GitHub for backwards compatibility.

Reticulum for software

What I think is worthwhile to explore is having machines interface with Reticulum. Just like we can tell our boat to switch lights on via a Meshtastic message, we should be able to do the same with Reticulum. And maybe there should be a NomadNet "site" for the boat showing status of the various systems.

Going further, maybe boats could share chart data, depth soundings, weather information with each other over this. The promise of VDES, but built from the grassroots perspective.

And maybe things like NoFlo should be able to communicate over Reticulum? Reticulum implementations exist for multiple programming languages, but for this we'd need a JavaScript port.

There's still a lot to study and to think about. Watch this space. Last time I noted that something is interesting, it took me to a ten year rabbit hole.

0 0

04 Jul 2026 12:00am GMT

Now that 2025 is over, it's time to look back and feel proud of the path we've walked. Last year has been really exciting in terms of contributions to GStreamer and WebKit for the Igalia Multimedia team.

With more than 459 contributions along the year, we've been one of the top contributors to the GStreamer project, in areas like Vulkan Video, GstValidate, VA, GStreamer Editing Services, WebRTC or H.266 support.

In Vulkan Video we've worked on the VP9 video decoder, and cooperated with other contributors to push the AV1 decoder as well. There's now an H.264 base class for video encoding that is designed to support general hardware-accelerated processing.

GStreaming Editing Services, the framework to build video editing applications, has gained time remapping support, which now allows to include fast/slow motion effects in the videos. Video transformations (scaling, cropping, rounded corners, etc) are now hardware-accelerated thanks to the addition of new Skia-based GStreamer elements and integration with OpenGL. Buffer pool tuning and pipeline improvements have helped to optimize memory usage and performance, enabling the edition of 4K video at 60 frames per second. Much of this work to improve and ensure quality in GStreamer Editing Services has also brought improvements in the GstValidate testing framework, which will be useful for other parts of GStreamer.

Regarding H.266 (VVC), full playback support (with decoders such as vvdec and avdec_h266, demuxers and muxers for Matroska, MP4 and TS, and parsers for the vvc1 and vvi1 formats) is now available in GStreamer 1.26 thanks to Igalia's work. This allows user applications such as the WebKitGTK web browser to leverage the hardware accelerated decoding provided by VAAPI to play H.266 video using GStreamer.

Igalia has also been one of the top contributors to GStreamer Rust, with 43 contributions. Most of the commits there have been related to Vulkan Video.

In addition to GStreamer, the team also has a strong presence in WebKit, where we leverage our GStreamer knowledge to implement many features of the web engine related to multimedia. From the 1739 contributions to the WebKit project done last year by Igalia, the Multimedia team has made 323 of them. Nearly one third of those have been related to generic multimedia playback, and the rest have been on areas such as WebRTC, MediaStream, MSE, WebAudio, a new Quirks system to provide adaptations for specific hardware multimedia platforms at runtime, WebCodecs or MediaRecorder.

We're happy about what we've achieved along the year and look forward to maintaining this success and bringing even more exciting features and contributions in 2026.

0 0

26 Jan 2026 9:34am GMT

I've mentioned some of my various retronetworking projects in some past blog posts. One of those projects is Osmocom Community TDM over IP (OCTOI). During the past 5 or so months, we have been using a number of GPS-synchronized open source icE1usb interconnected by a new, efficient but strill transparent TDMoIP protocol in order to run a distributed TDM/PDH network. This network is currently only used to provide ISDN services to retronetworking enthusiasts, but other uses like frame relay have also been validated.

So far, the central hub of this OCTOI network has been operating in the basement of my home, behind a consumer-grade DOCSIS cable modem connection. Given that TDMoIP is relatively sensitive to packet loss, this has been sub-optimal.

Luckily some of my old friends at noris.net have agreed to host a new OCTOI hub free of charge in one of their ultra-reliable co-location data centres. I'm already hosting some other machines there for 20+ years, and noris.net is a good fit given that they were - in their early days as an ISP - the driving force in the early 90s behind one of the Linux kernel ISDN stracks called u-isdn. So after many decades, ISDN returns to them in a very different way.

Side note: In case you're curious, a reconstructed partial release history of the u-isdn code can be found on gitea.osmocom.org

But I digress. So today, there was the installation of this new OCTOI hub setup. It has been prepared for several weeks in advance, and the hub contains two circuit boards designed entirely only for this use case. The most difficult challenge was the fact that this data centre has no existing GPS RF distribution, and the roof is ~ 100m of CAT5 cable (no fiber!) away from the roof. So we faced the challenge of passing the 1PPS (1 pulse per second) signal reliably through several steps of lightning/over-voltage protection into the icE1usb whose internal GPS-DO serves as a grandmaster clock for the TDM network.

The equipment deployed in this installation currently contains:

• a rather beefy Supermicro 2U server with EPYC 7113P CPU and 4x PCIe, two of which are populated with Digium TE820 cards resulting in a total of 16 E1 ports

• an icE1usb with RS422 interface board connected via 100m RS422 to an Ericsson GPS03 receiver. There's two layers of of over-voltage protection on the RS422 (each with gas discharge tubes and TVS) and two stages of over-voltage protection in the coaxial cable between antenna and GPS receiver.

• a Livingston Portmaster3 RAS server

• a Cisco AS5400 RAS server

For more details, see this wiki page and this ticket

Now that the physical deployment has been made, the next steps will be to migrate all the TDMoIP links from the existing user base over to the new hub. We hope the reliability and performance will be much better than behind DOCSIS.

In any case, this new setup for sure has a lot of capacity to connect many more more users to this network. At this point we can still only offer E1 PRI interfaces. I expect that at some point during the coming winter the project for remote TDMoIP BRI (S/T, S0-Bus) connectivity will become available.

18 Sep 2022 10:00pm GMT

Almost one year after my post regarding first steps towards a V5 implementation, some friends and I were finally able to visit Wobcom, a small German city carrier and pick up a lot of decommissioned POTS/ISDN/PDH/SDH equipment, primarily V5 access networks.

This means that a number of retronetworking enthusiasts now have a chance to play with Siemens Fastlink, Nokia EKSOS and DeTeWe ALIAN access networks/multiplexers.

My primary interest is in Nokia EKSOS, which looks like an rather easy, low-complexity target. As one of the first steps, I took PCB photographs of the various modules/cards in the shelf, take note of the main chip designations and started to search for the related data sheets.

The results can be found in the Osmocom retronetworking wiki, with https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS being the main entry page, and sub-pages about

• Node Control Unit

• 16x BRI Uk0 Line Card

• 32x POTS Line Card

• Line Measurement Unit

• Shelf

In short: Unsurprisingly, a lot of Infineon analog and digital ICs for the POTS and ISDN ports, as well as a number of Motorola M68k based QUICC32 microprocessors and several unknown ASICs.

So with V5 hardware at my disposal, I've slowly re-started my efforts to implement the LE (local exchange) side of the V5 protocol stack, with the goal of eventually being able to interface those V5 AN with the Osmocom Community TDM over IP network. Once that is in place, we should also be able to offer real ISDN Uk0 (BRI) and POTS lines at retrocomputing events or hacker camps in the coming years.

08 Sep 2022 10:00pm GMT

If you have ever worked with Digium (now part of Sangoma) digital telephony interface cards such as the TE110/410/420/820 (single to octal E1/T1/J1 PRI cards), you will probably have seen that they always have a timing connector, where the timing information can be passed from one card to another.

In PDH/ISDN (or even SDH) networks, it is very important to have a synchronized clock across the network. If the clocks are drifting, there will be underruns or overruns, with associated phase jumps that are particularly dangerous when analog modem calls are transported.

In traditional ISDN use cases, the clock is always provided by the network operator, and any customer/user side equipment is expected to synchronize to that clock.

So this Digium timing cable is needed in applications where you have more PRI lines than possible with one card, but only a subset of your lines (spans) are connected to the public operator. The timing cable should make sure that the clock received on one port from the public operator should be used as transmit bit-clock on all of the other ports, no matter on which card.

Unfortunately this decades-old Digium timing cable approach seems to suffer from some problems.

08 Sep 2022 10:00pm GMT