Monthly Archive:: April 2021
The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 13.0-RELEASE. This is the first release of the stable/13 branch. The announcement and release notes contain more information.
Getting started with developing applications for a mobile platform can be a challenging task, especially when it comes to building and testing the application on the mobile device itself. The Librem 5 makes its application development workflow extremely simple. Among other things, you can develop applications on-device, which is something sorely missing from other platforms.
Over the last few months I have been on and off digging into the history of early PC networking products, especially Ethernet-based ones. In that context, it is impossible to miss the classic NE2000 adapter with all its offshoots and clones. Especially in the Linux community, the NE2000 seems to have had rather bad reputation that was in part understandable but in part based on claims that simply make no sense upon closer examination. A deep dive into this very popular and widespread NE2000 adapter.
FreeBSD will promote arm64 to a Tier 1 architecture in FreeBSD 13. This means we will provide release images, binary packages, and security and errata updates. While we anticipate there will be minor issues with this first release, we believe the port is mature enough that they can be resolved during the life of FreeBSD 13. Maybe not massively relevant right now, but with Arm making its way into both servers and desktops, this is some good future-proofing for FreeBSD.
The NVIDIA-led work to allow XWayland OpenGL and Vulkan acceleration with their proprietary driver has just been merged into X.Org Server Git. The XWayland changes needed to allow the NVIDIA proprietary driver to work in an accelerated manner have landed in X.Org Server 1.21 Git. The main change is xwayland: implement pixmap_from_buffers for the eglstream backend that was merged just a few minutes ago. NVIDIA is a big blocker for Wayland, so any steps forward are good steps – even if it takes a while before this code ends up on our desktops.
COBOL for Linux on x86 1.1 is the latest addition to the IBM COBOL compiler family, which includes Enterprise COBOL for z/OS and COBOL for AIX. COBOL for Linux on x86 is a productive and powerful development environment for building and modernizing COBOL applications. It includes an optimizing COBOL compiler and a COBOL runtime library. COBOL for Linux on x86 is based on the same advanced optimization technology as Enterprise COBOL for z/OS. It offers both performance and programming capabilities for developing business critical COBOL applications for Linux on x86 systems. COBOL for Linux on x86 is designed to support clients on their journey to the cloud. It enables clients to strategically deploy business-critical applications written in COBOL to a hybrid cloud environment or best-fit platforms, which includes IBM Z (z/OS), IBM Power Systems (AIX), and x86 (Linux) platforms. As I understand it, there’s still a lot of COBOL code all over the industry, so it makes sense for IBM to make its COBOL technologies available to more people.
An old post from 2014. From 1986 to 1989, I worked in the Xenix group at Microsoft. It was my first job out of school, and I was the most junior person on the team. I was hopelessly naive, inexperienced, generally clueless, and borderline incompetent, but my coworkers were kind, supportive and enormously forgiving – just a lovely bunch of folks. Microsoft decided to exit the Xenix business in 1989, but before the group was dispersed to the winds, we held a wake. Many of the old hands at MS had worked on Xenix at some point, so the party was filled with much of the senior development staff from across the company. There was cake, beer, and nostalgia; stories were told, most of which I can’t repeat. Some of the longer-serving folks dug through their files to find particularly amusing Xenix-related documents, and they were copied and distributed to the attendees. These are kinds of stories that need to be written down for posterity, of we risk losing a lot of valuable information and backstories to some of the less successful technology products of our time.
Correctness of code in the Android platform is a top priority for the security, stability, and quality of each Android release. Memory safety bugs in C and C++ continue to be the most-difficult-to-address source of incorrectness. We invest a great deal of effort and resources into detecting, fixing, and mitigating this class of bugs, and these efforts are effective in preventing a large number of bugs from making it into Android releases. Yet in spite of these efforts, memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities. In addition to ongoing and upcoming efforts to improve detection of memory bugs, we are ramping up efforts to prevent them in the first place. Memory-safe languages are the most cost-effective means for preventing memory bugs. In addition to memory-safe languages like Kotlin and Java, we’re excited to announce that the Android Open Source Project (AOSP) now supports the Rust programming language for developing the OS itself. Rust is popping up everywhere.
Many technologists viscerally felt yesterday’s announcement as a punch to the gut when we heard that the Signal messaging app was bundling an embedded cryptocurrency. This news really cut to heart of what many technologists have felt before when we as loyal users have been exploited and betrayed by corporations, but this time it felt much deeper because it introduced a conflict of interest from our fellow technologists that we truly believed were advancing a cause many of us also believed in. So many of us have spent significant time and social capital moving our friends and family away from the exploitative data siphon platforms that Facebook et al offer, and on to Signal in the hopes of breaking the cycle of commercial exploitation of our online relationships. And some of us feel used. Signal users are overwhelmingly tech savvy consumers and we’re not idiots. Do they think we don’t see through the thinly veiled pump and dump scheme that’s proposed? It’s an old scam with a new face. Allegedly the controlling entity prints 250 million units of some artificially scarce trashcoin called MOB (coincidence?) of which the issuing organization controls 85% of the supply. This token then floats on a shady offshore cryptocurrency exchange hiding in the Cayman Islands or the Bahamas, where users can buy and exchange the token. The token is wash traded back and forth by insiders and the exchange itself to artificially pump up the price before it’s dumped on users in the UK to buy to allegedly use as “payments”. All of this while insiders are free to silently use information asymmetry to cash out on the influx of pumped hype-driven buys before the token crashes in value. Did I mention that the exchange that floats the token is the primary investor in the company itself, does anyone else see a major conflict of interest here? And there goes Signal, down the drain, throwing away all the goodwill it has managed to build up. Apparently, the donations they received from users weren’t enough, and it has to resort to shady schemes like these to keep the service running. I wasn’t using Signal to begin with, but this ensures I’m not touch it with a ten foot pole. As for cryptocurrency, a topic we effectively do not cover on OSNews – I’m not saying cryptocurrency is by definition shady, but let’s just say I don’t read many stories about cryptocurrency that instill me with any confidence in its trustworthiness and stability in any way, shape, or form. The technology in and of itself is cool, but what people are doing with it is, well, not.
Steam is a gaming platform that sells and manages games on Windows and Linux. Since FreeBSD has some pretty good Linux emulation, it is possible – with some footnotes – to run Linux Steam Games on FreeBSD. This was already possible in 2016 but the tooling keeps being updated, so let’s take a look at how things work. This is really interesting. Wine’s and Valve’s efforts are paying off in so many unforeseen ways.
Great news from the Supreme Court of the United States. In a ruling on Monday, the Supreme Court found that Google could legally use elements of Oracle’s Java application programming interface (API) code when building Android. “Google’s copying of the API to reimplement a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, constituted a fair use of that material,” the Supreme Court ruled in a 6-2 opinion, with one justice (Amy Coney Barrett) not taking part in the ruling. It overturned an earlier federal decision, which found that Google’s use of the API had constituted infringement. Not only is Google’s specific use case declared fair use, but any and all similar cases are fair use as well, as a matter of law, the Supreme Court ruled. We reach the conclusion that in this case, where Google reimplemented a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, Google’s copying of the Sun Java API was a fair use of that material as a matter of law. Not only is this the only possible correct and proper ruling, it also means Oracle and Larry Ellison fall flat on their face which is always a joyous occasion as far as I’m concerned. And so ends the saga that, according to my pet conspiracy theory, was set up as one-two punch between Steve Jobs and Larry Ellison, who were incredibly close friends. Apple’s patent assault on Android vendors and Oracle’s attack on Google’s Android API usage happened at the same time, right after Jobs proclaimed he would go “thermonuclear war” on Android. Now, you can argue that these two simultaneous assaults were entirely coincidental, and that these two close friends did not coordinate their attacks in any way. I, on the other hand, remain convinced this was a premeditated, coordinated assault on Android – entirely befitting the two, by all accounts, unpleasant people Jobs and Ellison are.
We’re pleased to announce the release of webOS Open Source Edition (OSE) 2.10.0. There’s a new storage access framework, cookie encryption of Blink has been enabled, a peripheral manager service has been added, and there are ACG enhancements.
Rust developers have repeatedly raised concerned about an unaddressed privacy issue over the last few years. Rust has rapidly gained momentum among developers, for its focus on performance, safety, safe concurrency, and for having a similar syntax to C++. StackOverflow’s 2020 developer survey ranked Rust first among the “most loved programming languages.” However, for the longest time developers have been bothered by their production builds leaking potentially sensitive debug information. I’ll leave this one for you folks to figure out, but from a layman’s perspective, it looks like a really dumb thing to keep paths from the developer’s machine like this in compiled binaries? At least after countless years, the Rust developers seem committed to fixing it, finally.
This is version 4.9 of the open-source based AmiSSL library for Amiga based operating systems. Version 4.x is a new major release which comes with full compatibility to the OpenSSL 1.1.x line which includes important security related fixes, TLSv1.3 and comes with new encryption ciphers which are required nowadays to connect to modern SSL-based services (e.g. HTTPS). This may seem like a small update to an insignificant package, but it’s hugely important for smaller operating systems like Amiga OS to remain usable in this day and age.
Google is making some new changes to the Developer Program Policy that will make it harder for apps to see what other apps are installed on your Android device. Google says it regards the full list of installed apps on a user’s device to be personal and sensitive information, and as such, will limit which apps can access this information. Specifically, Google will be restricting which apps can request the QUERY_ALL_PACKAGES permission which is currently required for apps targeting API level 30 (Android 11) and above that want to query the list of installed apps on a user’s device that runs Android 11 or later. These moves by Google to make Android’s permission system less permissive is a welcome one. These changes don’t really restrict users in what kinds of access and permissions they can give applications if they choose to do so, but the default access levels applications get are getting more restrictive, which I think is a good thing. As long as we can keep making different choices and grant the access we choose, all is well.
Windows 95 was the “next-generation” OS from Microsoft: redesigned UI, long file names support, 32-bit apps and many other changes. Some of Windows 95 components are still in use today. How does it look? Let’s test it and figure it out. It’s always fun to dive back into old operating systems we used to use every day. Windows 95 is such a monumental release, and one that changed the face of computing overnight. It turned an already massive computer company into one of the largest, most powerful companies in the world, and its influence on how desktop and laptop user interfaces work today can be seen everywhere. Windows 95 also happens to be delightfully pleasant to look at, especially taking into account the jumbled, chaotic mess of a user interface Windows has become today.
9to5Google can report today that Google’s upcoming phones for this fall, including the presumed Pixel 6, will be among the first devices to run on the “GS101” Whitechapel chip. First rumored in early 2020, Whitechapel is an effort on Google’s part to create their own systems on a chip (SoCs) to be used in Pixel phones and Chromebooks alike, similar in to how Apple uses their own chips in the iPhone and Mac. Google was said to be co-developing Whitechapel with Samsung, whose Exynos chips rival Snapdragon processors in the Android space. Per that report, Google would be ready to launch devices with Whitechapel chips as soon as 2021. According to documentation viewed by 9to5Google, this fall’s Pixel phones will indeed be powered by Google’s Whitechapel platform. Google’s been hinting at this for a few years now. I’m curious to see how these will stack up against Apple’s and Qualcomm’s chips, because unlike what some people seem to think, Google has a lot of experience designing and building chips – just not for consumer devices.
