Citizen is temporarily suspending sales of its second-gen CZ Smart watch due to a "technical issue." From a report: The Wear OS watch, which launched in May, had a feature based on tech from IBM's Watson and NASA to track a person's alertness. It appears the decision stems from negative experiences from reviewers. Michael Fisher -- better known as MrMobile on YouTube -- noted that Citizen said it would suspend sales after he had reached out to the company about the watch's many issues. That was corroborated by a Wired story, in which reviewer Julian Chokkattu also detailed several bugs, like laggy screens, bad battery life, inaccurate tracking, and watchfaces that can't even tell the correct time.

IBM is introducing the watsonx Code Assistant for Z, a tool that uses generative AI to translate COBOL code to Java. This tool is set to be available in Q4 2023 and aims to speed up the translation of COBOL to Java on IBM's Z mainframes. The Register reports: According to IBM, there are billions of lines of COBOL code out there as potential candidates for modernization (a report last year estimated the total figure at 775-850 billion lines). For this reason, the generative AI features in watsonx Code Assistant for Z are intended to help developers to assess and determine the code most in need of modernization, allowing them to more speedily update large applications and focus on critical tasks.

IBM wants to provide tooling for each step of the modernization process, starting with its Application Discovery and Delivery Intelligence (ADDI) inventory and analysis tool. Other steps include refactoring business services in COBOL, transforming the code to Java code, and then validating the resulting outcome with the aid of automated testing. The resulting Java code emitted by watsonx Code Assistant for Z will be object-oriented, but will still interoperate with the rest of the COBOL application IBM claimed, as well as with key services such as CICS, IMS, DB2, and other z/OS runtimes.

The latest update to the Android Runtime (ART) -- the "engine behind the Android operating system (OS)" -- has resulted in app startup time "improvements of up to 30% on some devices," says Google. 9to5Google reports: Behind the scenes, "ART is the same for all devices" and: "The ART APEX module is a complex piece of software with an order of magnitude more APIs than any other APEX module. It also backs a quarter of the developer APIs available in the Android SDK. In addition, ART has a compiler that aims to make the most of the underlying hardware by generating chipset-specific instructions, such as Arm SVE." The testing process for Android Runtime updates involves "compiling over 18 million APKs and running app compatibility tests, and startup, performance, and memory benchmarks on a variety of Android devices that replicate the diversity of our ecosystem as closely as possible." There's then a very gradual rollout process.

Google also notes developer improvements with every update "like OpenJDK improvements and compiler optimizations that benefit both Java and Kotlin," with ART 13 resulting in the "fastest-ever adoption of a new OpenJDK [11] release on Android devices." ART 14 is rolling out "in the coming months" with "new compiler and runtime optimizations that improve performance while reducing code size," as well as OpenJDK 17.

An anonymous reader shares a column: You can still do a clean install of Windows, and it's arguably easier than ever, with official Microsoft-sanctioned install media easily accessible and Windows Update capable of grabbing most of the drivers that most computers need for basic functionality. The problem is that a "clean install" doesn't feel as clean as it used to, and unfortunately for us, it's an inside job -- it's Microsoft, not third parties, that is primarily responsible for the pile of unwanted software and services you need to decline or clear away every time you do a new Windows install.

The "out-of-box experience" (OOBE, in Microsoft parlance) for Windows 7 walked users through the process of creating a local user account, naming their computer, entering a product key, creating a "Homegroup" (a since-discontinued local file- and media-sharing mechanism), and determining how Windows Update worked. Once Windows booted to the desktop, you'd find apps like Internet Explorer and the typical in-box Windows apps (Notepad, Paint, Calculator, Media Player, Wordpad, and a few other things) installed. Keeping that baseline in mind, here's everything that happens during the OOBE stage in a clean install of Windows 11 22H2 (either Home or Pro) if you don't have active Microsoft 365/OneDrive/Game Pass subscriptions tied to your Microsoft account:

(Mostly) mandatory Microsoft account sign-in.
Setup screen asking you about data collection and telemetry settings.
A (skippable) screen asking you to "customize your experience."
A prompt to pair your phone with your PC.
A Microsoft 365 trial offer.
A 100GB OneDrive offer.
A $1 introductory PC Game Pass offer.

This process is annoying enough the first time, but at some point down the line, you'll also be offered what Microsoft calls the "second chance out-of-box experience," or SCOOBE (not a joke), which will try to get you to do all of this stuff again if you skipped some of it the first time. This also doesn't account for the numerous one-off post-install notification messages you'll see on the desktop for OneDrive and Microsoft 365. (And it's not just new installs; I have seen these notifications appear on systems that have been running for months even if they're not signed in to a Microsoft account, so no one is safe). And the Windows desktop, taskbar, and Start menu are no longer the pristine places they once were. Due to the Microsoft Store, you'll find several third-party apps taking up a ton of space in your Start menu by default, even if they aren't technically downloaded and installed until you run them for the first time. Spotify, Disney+, Prime Video, Netflix, and Facebook Messenger all need to be removed if you don't want them (this list can vary a bit over time).

Yes, Red Hat Enterprise Linux changed its licensing last month — but how will that affect AlmaLinux? The chair of the nonprofit AlmaLinux OS Foundation, benny Vasquez, tells SiliconANGLE that "For typical users, there's very, very little difference. Overall, we're still exactly the same way we were, except for kernel updates." Updates may no longer be available the day a new version of RHEL comes out, but developers still have access to Red Hat's planned enhancements and bug fixes via CentOS Stream, a version of RHEL that Red Hat uses as essentially a test bed for new features that might later be incorporated into its flagship product. From a practical perspective, that's nearly as good as having access to the production source code, Vasquez said. "While there is a generally accepted understanding that not everything in CentOS Stream will end up in RHEL, that's not how it works in practice," she said. "I can't think of anything they have shipped in RHEL that wasn't in Stream first."

That's still no guarantee, but the workarounds AlmaLinux has put in place over the past month should address all but the most outlier cases, Vasquez said. The strategy has shifted from bug-for-bug compatibility to being application binary interface-compatible... ABI compatibility doesn't guarantee that problems will never occur, but glitches should be rare and can usually be resolved by recompiling the source code. "It is sufficient for us to be ABI-compatible with RHEL," Vasquez said. "The most important thing is that this allows our community to feel stability."

In fact, Red Hat's change of direction has been a blessing in disguise for AlmaLinux, she said... "We view this as a release from our bonds of being one-to-one." Patches can be applied without waiting for a cue from Red Hat and "we get to engage with our community in a completely new and exciting way." AlmaLinux has also seen a modest financial windfall from Red Hat's decision. "The outpouring of support has been pretty impressive," Vasquez said. "People have shown up for event staffing and website maintenance and infrastructure management and we've gotten more financial backing from corporations."
Vasquez also told the site that "the number of everyday people throwing in $5 has more than quadrupled."

Debian blog: Over 30 years ago the late Ian Murdock wrote to the comp.os.linux.development newsgroup about the completion of a brand-new Linux release which he named "The Debian Linux Release." He built the release by hand, from scratch, so to speak. Ian laid out guidelines for how this new release would work, what approach the release would take regarding its size, manner of upgrades, installation procedures; and with great care of consideration for users without Internet connection. Unaware that he had sparked a movement in the fledgling F/OSS community, Ian worked on and continued to work on Debian. The release, now aided by volunteers from the newsgroup and around the world, grew and continues to grow as one of the largest and oldest FREE operating systems that still exist today.

Debian at its core is comprised of Users, Contributors, Developers, and Sponsors, but most importantly, People. Ians drive and focus remains embedded in the core of Debian, it remains in all of our work, it remains in the minds and hands of the users of The Universal Operating System. The Debian Project is proud and happy to share our anniversary not exclusively unto ourselves, instead we share this moment with everyone, as we come together in celebration of a resounding community that works together, effects change, and continues to make a difference, not just in our work but around the world. Debian is present in cluster systems, datacenters, desktop computers, embedded systems, IoT devices, laptops, servers, it may possibly be powering the web server and device you are reading this article on, and it can also be found in Spacecraft.

OS News' managing editor calls Firefox "the single most important desktop Linux application," shipping in most distros (with some users later opting for a post-installation download of Chrome).

But "I'm genuinely worried about the state of browsers on Linux, and the future of Firefox on Linux in particular..." While both GNOME and KDE nominally invest in their own two browsers, GNOME Web and Falkon, their uptake is limited and releases few and far between. For instance, none of the major Linux distributions ship GNOME Web as their default browser, and it lacks many of the features users come to expect from a browser. Falkon, meanwhile, is updated only sporadically, often going years between releases. Worse yet, Falkon uses Chromium through QtWebEngine, and GNOME Web uses WebKit (which are updated separately from the browser, so browser releases are not always a solid metric!), so both are dependent on the goodwill of two of the most ruthless corporations in the world, Google and Apple respectively.

Even Firefox itself, even though it's clearly the browser of choice of distributions and Linux users alike, does not consider Linux a first-tier platform. Firefox is first and foremost a Windows browser, followed by macOS second, and Linux third. The love the Linux world has for Firefox is not reciprocated by Mozilla in the same way, and this shows in various places where issues fixed and addressed on the Windows side are ignored on the Linux side for years or longer. The best and most visible example of that is hardware video acceleration. This feature has been a default part of the Windows version since forever, but it wasn't enabled by default for Linux until Firefox 115, released only in early July 2023. Even then, the feature is only enabled by default for users of Intel graphics — AMD and Nvidia users need not apply. This lack of video acceleration was — and for AMD and Nvidia users, still is — a major contributing factor to Linux battery life on laptops taking a serious hit compared to their Windows counterparts... It's not just hardware accelerated video decoding. Gesture support has taken much longer to arrive on the Linux version than it did on the Windows version — things like using swipes to go back and forward, or pinch to zoom on images...

I don't see anyone talking about this problem, or planning for the eventual possible demise of Firefox, what that would mean for the Linux desktop, and how it can be avoided or mitigated. In an ideal world, the major stakeholders of the Linux desktop — KDE, GNOME, the various major distributions — would get together and seriously consider a plan of action. The best possible solution, in my view, would be to fork one of the major browser engines (or pick one and significantly invest in it), and modify this engine and tailor it specifically for the Linux desktop. Stop living off the scraps and leftovers thrown across the fence from Windows and macOS browser makers, and focus entirely on making a browser engine that is optimised fully for Linux, its graphics stack, and its desktops. Have the major stakeholders work together on a Linux-first — or even Linux-only — browser engine, leaving the graphical front-end to the various toolkits and desktop environments....

I think it's highly irresponsible of the various prominent players in the desktop Linux community, from GNOME to KDE, from Ubuntu to Fedora, to seemingly have absolutely zero contingency plans for when Firefox enshittifies or dies...

Microsoft is rolling out a new update for Windows 11 that disables the digital assistant Cortana. The Verge reports: If you attempt to launch Cortana on Windows 11 you'll now be met with a notice about how the app is deprecated and a link to a support article on the change. Microsoft is now planning to end support for Cortana in Teams mobile, Microsoft Teams Display, and Microsoft Teams Rooms "in the fall of 2023." Surprisingly, Cortana inside Outlook mobile "will continue to be available," according to Microsoft.

Microsoft is now working on Windows Copilot, a new sidebar for Windows 11 that is powered by Bing Chat and can control Windows settings, answer questions, and lots more. Windows Copilot is expected to be available this fall as part of a Windows 11 update that will also include native RAR and 7-Zip support.

Google's long-running project to split up ChromeOS and its Chrome browser is currently in beta and should be live in the stable channel later this month. The flags that turn on the feature by default were spotted by Kevin Tofel from About Chromebooks. Ars Technica reports: The project is called "Lacros" which Google says stands for "Linux And ChRome OS." This will split ChromeOS's Linux OS from the Chrome browser, allowing Google to update each one independently. Google documentation on the project says, "On Chrome OS, the system UI (ash window manager, login screen, etc.) and the web browser are the same binary. Lacros separates this functionality into two binaries, henceforth known as ash-chrome (system UI) and lacros-chrome (web browser)." Part of the project involves sprucing up the ChromeOS OS, and Google's docs say, "Lacros can be imagined as 'Linux chrome with more Wayland support.'"

On the browser side, ChromeOS would stop using the bespoke Chrome browser for ChromeOS and switch to the Chrome browser for Linux. The same browser you get on Ubuntu would now ship on ChromeOS. In the past, turning on Lacros in ChromeOS would show both Chrome browsers, the outgoing ChromeOS one and the new Linux one. Lacros has been in development for around two years and can be enabled via a Chrome flag. Tofel says his 116 build no longer has that flag since it's the default now. Google hasn't officially confirmed this is happening, but so far, the code is headed that way.

Managing windows — "even after 50 years, nobody's fully cracked it yet," writes GNOME developer Tobias Bernard: Most of the time you don't care about exact window sizes and positions and just want to see the windows that you need for your current task. Often that's just a single, maximized window. Sometimes it's two or three windows next to each other. It's incredibly rare that you need a dozen different overlapping windows. Yet this is what you end up with by default today, when you simply use the computer, opening apps as you need them. Messy is the default, and it's up to you to clean it up...

We've wanted more powerful tiling for years, but there has not been much progress due to the huge amount of work involved on the technical side and the lack of a clear design direction we were happy with. We now finally feel like the design is at a stage where we can take concrete next steps towards making it happen, which is very exciting! The key point we keep coming back to with this work is that, if we do add a new kind of window management to GNOME, it needs to be good enough to be the default. We don't want to add yet another manual opt-in tool that doesn't solve the problems the majority of people face.
The current concept imagines three possible layout states for windows:

- Floating, the classic stacked windows model
- Edge Tiling, i.e. windows splitting the screen edge-to-edge
- Mosaic, a new window management mode which combines the best parts of tiling and floating

Mosaic is the default — where "you open a window, it opens centered on the screen at a size that makes the most sense for the app." (Videos in the blog post show how this works.) "As you open more windows, the existing windows move aside to make room for the new ones. If a new window doesn't fit (e.g. because it wants to be maximized) it moves to its own workspace. If the window layout comes close to filling the screen, the windows are automatically tiled." You can also manually tile windows. If there's enough space, other windows are left in a mosaic layout. However, if there's not enough space for this mosaic layout, you're prompted to pick another window to tile alongside. You're not limited to tiling just two windows side by side. Any tile (or the remaining space) can be split by dragging another window over it, and freely resized as the window minimum sizes allow.
So what's next? Windows can already set a fixed size and they have an implicit minimum size, but to build a great tiling experience we need more... At the Brno hackfest in April we had an initial discussion with GNOME Shell developers about many of the technical details. There is tentative agreement that we want to move in the direction outlined in this post, but there's still a lot of work ahead... We'd like to do user research to validate some of our assumptions on different aspects of this, but it's the kind of project that's very difficult to test outside of an actual prototype that's usable day to day.
"There's another issue with GNOME's current windowing system," notes 9to5Linux. "If the stacking is interrupted, newly opened windows will be opened from the top, covering the first opened window." For this new windowing system to become a reality, the GNOME devs would have to do a lot of user research and test numerous scenarios so that everyone can be happy. As you can imagine, this could take months or even years, so if you want to get involved and help them do it faster, please reach out to the GNOME team here.

After Red Hat's decision to only share RHEL source code with subscribers, AlmaLinux asked their bug report submitters to "attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place."

Red Hat told Ars Technica they are "eager to collaborate" on their CentOS Stream distro, "even if we ultimately compete in a business sense. Differentiated competition is a sign of a healthy ecosystem."

But Red Hat still managed to ruffled some feathers, reports ZDNet: AlmaLinux Infrastructure Team Leader Jonathan Wright recently posted a CentOS Stream fix for CVE-2023-38403, a memory overflow problem in iperf3. Iperf3 is a popular open-source network performance test. This security hole is an important one, but not a huge problem.

Still, it's better by far to fix it than let it linger and see it eventually used to crash a server. That's what I and others felt anyway. But, then, a senior Red Hat software engineer replied, "Thanks for the contribution. At this time, we don't plan to address this in RHEL, but we will keep it open for evaluation based on customer feedback."

That went over like a lead balloon.

The GitLab conversation proceeded:

AlmaLinux: "Is customer demand really necessary to fix CVEs?"

Red Hat: "We commit to addressing Red Hat defined Critical and Important security issues. Security vulnerabilities with Low or Moderate severity will be addressed on demand when [a] customer or other business requirements exist to do so."

AlmaLinux: "I can even understand that, but why reject the fix when the work is already done and just has to be merged?"

At this point, Mike McGrath, Red Hat's VP of Core Platforms, AKA RHEL, stepped in. He explained, "We should probably create a 'what to expect when you're submitting' doc. Getting the code written is only the first step in what Red Hat does with it. We'd have to make sure there aren't regressions, QA, etc. ... So thank you for the contribution, it looks like the Fedora side of it is going well, so it'll end up in RHEL at some point."

Things went downhill rapidly from there...

On Reddit, McGrath said, "I will admit that we did have a great opportunity for a good-faith gesture towards Alma here and fumbled."

Finally, though the Red Hat Product Security team rated the CVE as "'Important,' the patch was merged.
Coincidentally, last month AlmaLinux announced that its move away from 1:1 compatibility with RHEL meant "we can now accept bug fixes outside of Red Hat's release cycle."

This Thursday AlmaLinux also reiterated that they're "fully committed to delivering the best possible experience for the community, no matter where or what you run." And in an apparent move to beef up compatibility testing, they announced they'd be bringing openQA to the RHEL ecosystem. (They describe openQA as a tool using virtual machines that "simplifies automated testing of the whole installation process of an operating system in a wide combination of software and hardware configurations.")

Last weekend in Portland, Oregon, the Software Freedom Conservancy hosted a new conference called the Free and Open Source Software Yearly.

And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:

• benny Vasquez, the Chair of the AlmaLinux OS Foundation
• Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
• James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances

"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."

One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"

In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."

When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."

AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."

And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."

Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."

Read Slashdot's transcript of highlights from the discussion.

"People are getting increasingly fed up with their car infotainment systems," reports the Verge: According to JD Power's Automotive Performance, Execution and Layout (APEAL) Study, overall satisfaction among car owners is 845 (on a 1,000-point scale), a decrease of two points from a year ago and three points lower than in 2021. That's the first time in the 28-year history of the study that the consumer research firm registered a consecutive year-over-year decline in owner satisfaction...

Only 56 percent of owners prefer to use their vehicle's built-in system to play audio, down from 70 percent in 2020, JD Power found. Less than half of owners said they like using their car's native controls for navigation, voice recognition, or to make phone calls...

[I]t seems like most people are preferring to use smartphone-mirroring systems like Apple CarPlay and Android Auto, which have proven to be incredibly popular over the years... But it seems like people are warming up to native operating systems, as long as they're developed by Google and not the automaker. JD Power found that models that have Android Automotive with Google Automotive's operating system, AAOS, "score higher in the infotainment category than those with no AAOS whatsoever."

But here's where things get kind of weird: AAOS without Google Automotive Services (GAS) receives the lowest scores for infotainment of the three categories. Google Automotive Services refers to all the apps and services that come with the car when Google is built into the car — also known as "Google built-in." Ford, GM, and Volvo have all said they will use GAS for their current and upcoming vehicles... That's surely music to GM's ears, which recently made the controversial decision to block access to CarPlay and Android Auto in its future EV lineup in favor of a native Google infotainment system.

An anonymous reader quotes a report from 9to5Google: Google is rolling out ChromeOS 115 as a bigger-than-usual update with a number of user-facing additions over the coming days. Amidst I/O 2023, Google announced the beta availability of Android App Streaming from your Pixel (4a+) or Xiaomi (12T, 12T Pro, 13, 13 Pro) phone running Android 13 and newer with Cross-Device Services installed. It's now entering stable with ChromeOS 115 so that you can stream apps from your mobile device to your Chromebook. This is framed as letting you "complete quick tasks like replying to a conversation, checking on the status of a rideshare or delivery, and editing your shopping list."

Android apps, which open in a phone-sized window, can be launched via the Phone Hub where you get a row of Recent apps at the bottom of the panel with the ability to browse all compatible "Apps from your phone." Applications can also open when you tap through a messaging notification. When opening PDFs in the Gallery app, ChromeOS 115 adds a signature tool. Appearing next to Draw in the top toolbar, you can add a signature, which is much easier with a touchscreen than a trackpad and save it for future use. You can place it in any document and resize the signature to ensure line fit. Lastly, Google has updated the keyboard Shortcuts app with "new navigation and taxonomy," improved search, and a "refreshed shortcut visualization" that better shows what to press.

Meanwhile, this is unmentioned in the stable release notes, but ChromeOS 115 is testing better windowing options in the beta channel. Hovering over the expand/minimize button in the top-right corner control group will show you a new layout menu. There's Split (half), Partial, Full and Float. That last option is new and makes it so that the window is always on top, just like Picture-in-Picture (PiP) for video. The other options were previously accessed by dragging a window and moving to the left/right side of the screen until an overlay appears. This approach is much more accessible and hopefully sees a wide launch soon. The announcement can be read here.

Ahead of the Oppenheimer release, IMAX's TikTok showed the massive 70mm film print and special IMAX extensions. The video interestingly featured an emulated Palm m130, commonly known as a Palm Pilot, a 2002 device running on a Motorola 33MHz DragonBall VZ processor and Palm OS 4.1. From a report: In an IMAX theater, the m130's job is to control the quick turn reel unit, or QTRU for short. (For many years, it appears, a non-emulated m130 sat holstered in most theaters.) The QTRU's job is to control the platters, which are those large horizontal shelves where all of a film's many reels are stitched together, stored, and then quickly spun out to and from the projector. The IMAX 1570 projector moves film at a little under six feet per second, so it's all happening really fast.

The m130 is apparently crucial to keeping the thing humming -- "PALM PILOT MUST BE ON ALL THE TIME," reads a notice above an image of a different m130 that has since been passed around the internet -- but doesn't often need to be used. "I've never had to interact with the Palm Pilot," says one person familiar with the technology. "It's really just a status screen." Its job is to keep the QTRU moving at a consistent speed and to help keep the film's video in sync with its audio.

Long-time Slashdot reader Amiga Trombone shares a report from Phoronix: With Red Hat now restricting access to the RHEL source repositories, AlmaLinux and other downstreams that have long provided "community" rebuilds of Red Hat Enterprise Linux with 1:1 compatibility to upstream RHEL have been left sorting out what to do. Benny Vasquez, Chair of the Board for the AlmaLinux OS Foundation, wrote in a blog post yesterday: After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*.

We will continue to aim to produce an enterprise-grade, long-term distribution of Linux that is aligned and ABI compatible with RHEL in response to our community's needs, to the extent it is possible to do, and such that software that runs on RHEL will run the same on AlmaLinux.

For a typical user, this will mean very little change in your use of AlmaLinux. Red Hat-compatible applications will still be able to run on AlmaLinux OS, and your installs of AlmaLinux will continue to receive timely security updates. The most remarkable potential impact of the change is that we will no longer be held to the line of "bug-for-bug compatibility" with Red Hat, and that means that we can now accept bug fixes outside of Red Hat's release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream."

According to Statcounter, the Linux share on the desktop has passed 3% for the first time. GamingOnLinux reports: While it has been close a couple of times, the trend according to their stats is pretty clear that Linux use has been slowly rising over the last few years. This does not include ChromeOS, even though it's based on Linux, as they track that separately so this is just plain desktop Linux.

Across this year their stats show for Linux:

January - 2.91%
February - 2.94%
March - 2.85%
April - 2.83%
May - 2.7%
June - 3.07%

An anonymous reader quotes a report from Ars Technica: No one in the Android ecosystem can hold a candle to Apple's software support timeline for the iPhone, but there is one company that comes the closest: Fairphone. Following in the footsteps of the Fairphone 2, the Fairphone 3 is also getting an Android-industry-best seven years of OS support. Fairphone continues to run circles around giant tech companies that have a lot more resources than it does, and it's doing this even in the face of component vendors like Qualcomm dropping support for the phone's core components.

The company announced today that the Fairphone 3, which was released in 2019, has had its support extended to 2026, making for seven years of updates. The company also just released Android 13 for the Fairphone 3. Google's own 2019 phone, the Pixel 4, shut down support in October 2022. Fairphone strives to make sustainable smartphones, designing its products to be repairable and also offering replacement parts for sale online. Part of that sustainability mission is an absolutely herculean effort to keep the Android updates flowing, even when Qualcomm drops critical software support for the SoC. Fairphone says the Snapdragon 632 SoC in the Fairphone 3 was only supported up to Android 11, so continuing to support the Fairphone 3 meant doing the upgrades all by itself.

Long-time Slashdot reader theodp writes: Recalling a past Computer History Museum look at the evolution of programming languages, Doug Meil ponders the age-old question of Why Are There So Many Programming Languages? in a new Communications of the ACM blog post.

"It's worth noting and admiring the audacity of PL/I (1964)," Meil writes, "which was aiming to be that 'one good programming language.' The name says it all: Programming Language 1. There should be no need for 2, 3, or 4. [Meil expands on this thought in Lessons from PL/I: A Most Ambitious Programming Language.] Though PL/I's plans of becoming the Highlander of computer programming didn't play out like the designers intended, they were still pulling on a key thread in software: why so many languages? That question was already being asked as far back as the early 1960's."

One of PL/I's biggest fans was Digital Research Inc. (DRI) founder Gary Kildall, who crafted the PL/I-inspired PL/M (Programming Language for Microcomputers) in 1973 for Intel. But IBM priced PL/I higher than the languages it sought to replace, contributing to PL/I's failure to gain traction. (Along the lines of how IBM's deal with Microsoft gave rise to a price disparity that was the undoing of Kildall's CP/M OS, bundled with every PC in a 'non-royalty' deal. Windows was priced at $40 while CP/M was offered 'a la carte' at $240.) As a comp.lang.pl1 poster explained in 2006, "The truth of the matter is that Gresham's Law: 'Bad money drives out good' or Ruskin's principle: 'The hoi polloi always prefer an inferior, cheap product over a superior, more expensive one' are what govern here."

The Fairphone 4 -- a user-repairable smartphone built using ethically sourced materials -- is finally coming to the US, almost two years after it first debuted back in September 2021. The Verge reports: Fairphone is partnering with Murena, a company best known for de-Googling Android phones, to launch the US pilot of the Murena Fairphone 4 -- a variant of the handset that runs on a privacy-oriented Android-based operating system: /e/OS. There are two configurations available: one with 6GB of RAM and 128GB of storage for $599 and another with 8GB of RAM and 256GB of storage for $679. The storage of both models can be expanded via microSD, and the phone features a modular design that can be easily disassembled using a standard Phillips #00 screwdriver to replace broken components. It also has an IP54 rating, meaning the device is protected against dust and water sprays.

The Murena Fairphone 4 will ship to US customers with 5G and dual SIM support, a removable 3905mAh battery, a 48-megapixel main camera, a 48-megapixel ultrawide, and a 25-megapixel selfie camera. The phones will be available to order exclusively from Murena's webstore starting today. The Murena Fairphone 4 also comes with the /e/ operating system preinstalled, which is described as a privacy-focused, Google-free mobile ecosystem for folks who want to avoid handing any data over to the search giant. Instead of the usual Google apps, the Fairphone 4 will come with a range of default Murena Cloud apps for things like email, calendar, and cloud storage as well as a dedicated app store that highlights the privacy ratings of each app to help users monitor how their online activity is being tracked.

The Fairphone comes unlocked, but the press release mentions that T-Mobile and other operators based on T-Mobile's network are the only US carriers recommended to be used with the device. Fairphone is also providing an extended five-year warranty for the hardware, and /e/OS is similarly committed to fixing bugs and supporting security and feature updates for five years. The Murena version is the only Fairphone 4 model being introduced to the US, and there's no mention of the standard Android OS model joining it anytime soon.