Axiomtek’s rugged “eBOX560-52R-FL” runs Linux or Win 10 on Intel’s 8th Gen UE-series with up to 32GB DDR4, 2x GbE, 2x USB 3.1 Gen2, HDMI, DP++, SATA, and M.2.

The eBOX560-52R-FL is a more compact, scaled-down alternative to Axiomtek’s similarly fanless, rugged, and Whiskey Lake based eBOX630-528-FL. The system measures only 141.6 x 106 x 55mm.

A defective livepatch for kernel 4.4 in Ubuntu 16.04 LTS (Xenial) was not caught in internal testing processes because the defect was a race condition, triggered by workload-specific behaviour, under load.

The livepatch would cause the madvise system call to block indefinitely, and thus cause lockup to the processes using the call. These conditions were not replicated in our test environment.

After passing internal testing, the livepatch was published to our free tier users (typically personal systems). Canonical services also run in this tier as an early warning system, and the defect was noticed at that stage. Customers with systems configured for this tier were also impacted. The livepatch causing the defect was retracted one and a half hours after publication, however the standard update process is designed to patch all online systems within one hour.

The faulty livepatch was addressing a Medium severity CVE (CVE-2020-29372). This CVE fix came in as part of our normal SRU processes. The livepatch was tested in combination with an embargoed high severity CVE, and at no time did we see any issues with systems as we tested the combined livepatch. As part of the analysis of the lockup we have found that systems that are running under load may obtain a lock that is not handled correctly after the livepatch is applied. If the lock was obtained after the livepatch was applied then all is fine. Linux kernel livepatching is a complex process that we stabilize through our testing, and our tier deployment process. 

In addition to our internal testing processes, we follow a tiered deployment policy that releases livepatches to our customers, to reduce the risks associated with kernel livepatching. Customers should only receive a livepatch after all the internal embargoed test systems and the free tier, successfully apply it.

In our everyday lives, we have the means to fix many of the tools we use on a daily basis. Even though many still choose to hire professionals, taking apart your blender, bike, or even your car takes only some simple tools and curiosity to find out how things work. When it comes to consumer electronics, however, the landscape is very different. Here at System76, we believe the right to repair your computer should be the same as the right to repair anything else—sadly, many of our representatives in government don’t feel the same way.

Yesterday, the state of Colorado held a hearing on Right to Repair legislation, known as the Consumer Digital Repair Bill of Rights (HB21-1199). According to the Colorado General Assembly, the bill would require electronics manufacturers to provide people with the resources needed to repair their equipment. This includes, “parts, embedded software, firmware, tools, or documentation, such as diagnostic, maintenance, or repair manuals, diagrams, or similar information.” As part of this effort, System76 Founder/CEO Carl Richell and Principal Engineer Jeremy Soller traveled to the Capitol to speak in support of this legislation.

Wildfires are among the most common forms of natural disasters in some regions, including Siberia, the United States, and Australia. It is important to improve forecasting for wildfires to help firefighters to prepare and respond, and to help to mitigate wildfires in the future. In the Call for Code Spot Challenge for Wildfires, teams both outside and within IBM (internal challenge) worked on predicting wildfires in Australia using data sets extracted from the Weather Operations Center Geospatial Analytics component (PAIRS Geoscope).

[...]

No IBM or Red Hat employees could participate in the public challenge.

DevOps transformation is more important now that ever. In today’s world, the challenges we face and the opportunities the market has presented — the path has never been clearer. But how does that journey start? This is the question that many companies face. A DevOps organization isn’t built in a day. At IBM, we believe that the DevOps transformation is a journey best walked together with our customers. That’s why we have made available our DevOps Acceleration Program, a team of experts, evangelists, and practitioners, all focused on one thing: success with DevOps transformations.

Every piece of an enterprise-level DevOps transformation is essential: Identifying the resources, putting the tooling in place, building a rollout strategy — it’s all necessary for you to reap the greatest rewards. This includes quality training that enables developers to seamlessly transition over to DevOps practices and tools.

Red Hat has announced the availability of Red Hat Integration, a comprehensive set of integration and messaging technologies to connect applications and data across hybrid infrastructures.

Most of my career I’ve been working on a text editor product in either a hobby or professional capacity. Years ago I had an idea to combine a B+Tree with a PieceTable and put together a quick prototype. However, it didn’t do the nasty part which was removal and compaction of the B+Tree (so just another unfinished side-project).

Now that we’re between GNOME cycles, I had the chance to catch up on that data structure and finish it off.

Just for a bit of background, a B+Tree is a B-Tree (N-ary tree) where you link the leaves (and often the branches) in a doubly-linked list from left-to-right. This is handy when you need to do in-order/reverse-order table-scans as you don’t need to traverse the internal nodes of the tree. Unsurprisingly, editors do this a lot. Since B+Trees only grow from the root, maintaining these linked-lists is pretty easy.

[...]

Anyway, here it is, and it seems to work. Finally I can move on from having that bit of data-structure on my mind.

Spacebase Startopia sells players the galactic dream: managing their very own donut-shaped space station. It's out officially today along with full Linux support from Realmforge Studios and Kalypso Media.

Overseen and assisted (when she feels like it) by the base's sarcastic on-board AI, players will play Commander to their floating home-away-from-home on the station's three unique decks with a variety of gadgetry while tending to the wants and needs of a diverse array of vacationing extra-terrestrial lifeforms. In multiplayer, up to 4 players can work together to build the galaxy's greatest getaway, or seek oblivion unto their rivals with daring feats of economic sabotage.

[...]

No review key was available for us before release but we have a request in, so a more traditional review / thoughts article may come in future. From a few reviews gone up by more traditional Windows-focused websites, it sadly sound like it's not been a great release and fails to live up to the original but hopefully we will see for ourselves. Doesn't seem like it's bad, just alright.

Last week we noted how a kernel driver for NZXT's Kraken AIO liquid cooling devices was under review for the mainline kernel. Shortly after that point the driver did get successfully picked up for hwmon-next and thus should be appearing in the upcoming Linux 5.13 cycle.

For those with an KZXT Kraken X42 / X52 / X62 / X72 all-in-one liquid cooling setup, Linux 5.13 should be mainlining this community-maintained driver. This driver was developed via reverse-engineering the NZXT Kraken USB protocol. This has been years in the making with the NZXT Kraken support for Linux with this "nzxt-kraken2" kernel driver previously maintained out-of-tree as part of the Liquidctl project.