Category Archives: linux

Amazon Linux 2023: designed to be disposable

Amazon Linux 2023 is the default for Linux VMs on AWS EC2 (Elastic Compute Cloud). Should you use it? It is a DevOps choice; the main reason why you might use it is that it feels like playing safe. AWS support will understand it, it should be performance-optimised for EC2; it should work smoothly with AWS services.

Amazon Linux 2 was released in June 2018 and was the latest production version until March 2023, by which time it was very out of date. Based on CentOS 7, it was pretty standard and you could easily use additional repositories such as EPEL (Extra Packages for Enterprise Linux). It is easy to keep up to date with sudo yum update. However there is no in-place upgrade.

Amazon Linux 2023 is different in character. It was released in March 2023 and the idea is to have a major release every 2 years, and to support each release for 5 years. It does not support EPEL or repositories other than Amazon’s own. The docs say:

At this time, there are no additional repositories that can be added to AL2023. This might change in the future.

The docs also document how to add an external repository so it is a bit confusing. You can also compile your own rpms and install that way; but if you do, keeping them up to date is down to you.

The key to why this is though is in a thing AWS calls deterministic upgrades. Each version, including minor versions, is locked to a specific repository. You can upgrade to a new release but it has to be specified. This is what I got today from my installation on Hyper-V:

Amazon Linux 2023 offering a new release

The command dnf check-release-update looks for a new release and tells you how to upgrade to it, but does not do so by default.

The reason, the docs explain, is that:

With AL2023, you can ensure consistency between package versions and updates across your environment. You can also ensure consistency for multiple instances of the same Amazon Machine Image (AMI). With the deterministic upgrades through versioned repositories feature, which is turned on by default, you can apply updates based on a schedule that meets your specific needs.

The idea is that if you have a fleet of Amazon Linux 2023 instances they all work the same. This is ideal for automation. The environment is predictable.

It is not ideal though if you have, say, one server, or a few servers doing different things, and you want to run them for a long time and keep them up to date. This will work, but the operating system is designed to be disposable. In fact, the docs say:

To apply both security and bug fixes to an AL2023 instance, update the DNF configuration. Alternatively, launch a newer AL2023 instance.

The bolding is mine; but if you have automation so that a new instance can be fired up configured as you want it, launching a new instance is just as logical as updating an existing one, and arguably safer.

.NET P/Invoke on Azure App Service for Linux

I have an online bridge game in development (yes, still!) and it is written in ASP.NET Core with C#. One of the things that interests bridge players is called double-dummy analysis; this is where you look at what would be the best play in a game if you knew where all the cards were, whereas when actually playing bridge you only see your own cards and, during play, another hand called Dummy, so half the cards are hidden.

Double-dummy analysis is a solved problem and bridge programmers benefit from an open source library called DDS (Double Dummy Solver) written primarily by Bo Hagland and Soren Hein. This is a C++ DLL that can also be compiled for Linux and MacOS.

I wanted to integrate DDS into the bridge game in order to give players information at the end of a game including whether they were in the optimum contract and whether they beat the optimum score. I started by doing a new C# wrapper for DDS though borrowing from the work here. My version is 64-bit and wraps a few more functions. I compiled the native DLL for Windows and Linux using OpenMP for concurrency, which considerably improves performance (Boost is another option but I did not find much difference).

Note: the usual caveats about P/Invoke apply here. During one of my tests I actually crashed the container running the app. The ASP.NET developers do a lot of work to make the platform reliable, and doing P/Invoke may introduce instability.

I added my wrapper into the ASP.NET application and it worked fine on my development machine. I deployed it to App Service and the P/Invoke calls did not work. Fixing this required a bit of a deep dive into Azure App Service for Linux.

I am deploying the native code .so library into the same directory as the compiled .NET code for the rest of the application. The error I got was:

Cannot open shared object file: No such file or directory

I raised the topic on Stack Overflow.

One of the things that puzzled me was that the unit tests, which include the P/Invoke code, ran OK in Azure Pipelines, which I use for deployment. But not when deployed.

The first point is that you get the “No such file” error not only when the file itself is not present (it was) but also when a dependency is missing. So step one is to SSH into the container running the ASP.NET app, which you can do with the Development Tools in the Azure portal. Note that with Azure App Service for Linux the app always runs in a container.

image

This gives you root permissions in the container though not to the host operating system. Navigate to the directory with the troublesome library and type:

ldd libdds.so

(or the name of your library). This will tell you if any dependencies are missing or other issues. I noticed two things. One is that it was missing the dependency libgomp.so.1 which is the OpenMP library. Second, ldd reported that my library required at least GLIBC 2.29 where the available version was 2.28.

How could I fix the GLIBC version? This is determined by the version of Linux and you can use

ldd – version

to check the version you have. In my case it said I had Debian with GLIBC 2.28:

image

I did some more research. If you really want to know about Azure App Service for Linux, there are a few key documents.

The basics here: Operating system functionality – Azure App Service | Microsoft Learn

The FAQ here: App Service on Linux FAQ | Microsoft Learn

Here you will learn details like why you cannot use a file-based database like SQLite in Azure App Service for Linux:

“The file system of your application is a mounted network share. This enables scale out scenarios where your code needs to be executed across multiple hosts. Unfortunately this blocks the use of file-based database providers like SQLite since it’s not possible to acquire exclusive locks on the database file.”

But I digress. To go deeper still, check this post by Jim Cheshire:

Things You Should Know: Web Apps and Linux – Microsoft Tech Community

which has lots of critical information, like why a custom container on App Service must respond to ping.

So after reading through all this and greatly improving my understanding of how App Service for Linux works, I got to the heart of my problem. When you deploy a .NET Core application to App Service for Linux, it will by default use a container from the Microsoft Artifact Registry that matches the version of .NET you are using. If you check this page you will see that the current version for ASP.NET Core 6.0 is tagged mcr.microsoft.com/dotnet/aspnet:6.0

image

If you examine this container you will find that it runs Debian Buster which uses GLIBC 2.28. It is a matter of slight concern since Debian Buster is shown on the Debian releases wiki as having an approximate end of life August 2022, though the LTS project extends that to June 2024.

Still, now I knew how to fix my problem. Either use a custom container image, or upgrade to .NET 7, or recompile libdds.so to run on Debian Buster.

I decided that the easiest short-term solution was to recompile. I downloaded Buster and recompiled the library.

What about libgomp.so.1? This was kind-of fixable by using SSH to run:

apt-get update

apt-get install libgomp1

This is not great though since Azure could replace the container at any time, and always if you do something like scale the plan up or down, to change the specification of the VM. I tried copying the buster version of libgomp.so.1 to the application directory. It works, but I also needed to add a linker option to enable DDS to use a library in the same directory:

 -Wl,-rpath='${ORIGIN}'

as explained here.

I think a better solution is to move to deploying a custom container to App Service, which is an option:

image

Care is needed though as there is a bit of special sauce in the official container images if you want features like SSH in the portal to work properly. It also means revisiting my deployment scripts, so the above hack was an easier and quicker workaround for me.

From Big Blue to Big Red? IBM to acquire Red Hat

image

IBM has agreed to acquire Red Hat:

IBM will acquire all of the issued and outstanding common shares of Red Hat for $190.00 per share in cash, representing a total enterprise value of approximately $34 billion.

IBM Is presenting this as a hybrid cloud play, with the claim that businesses are held back from cloud migration “by the proprietary nature of today’s cloud market.”

IBM and Red Hat will be strongly positioned to address this issue and accelerate hybrid multi-cloud adoption. Together, they will help clients create cloud-native business applications faster, drive greater portability and security of data and applications across multiple public and private clouds, all with consistent cloud management. In doing so, they will draw on their shared leadership in key technologies, such as Linux, containers, Kubernetes, multi-cloud management, and cloud management and automation.

Notably, the announcement specifically refers to multi-cloud adoption, and that the company intends to “build and enhance” partnerships with Amazon Web Services (AWS), Microsoft Azure, Google Cloud and Alibaba.

Red Hat will be a “distinct unit” within IBM, the intention being to preserve its open source culture and independence.

My own instinct is that we will see more IBM influence on Red Hat, than Microsoft influence on GitHub, to take another recent example of an established tech giant acquiring a company with an open source culture.

IBM is coming from behind in the cloud wars, but with Linux ascendant, and Red Hat the leader in enterprise Linux, the acquisition gives the company a stronger position in today’s technology landscape.

Windows on a Chromebook? How containers change everything

Apparently there are rumours concerning Windows on a Chromebook. I find this completely plausible, though unlike Barry Collins I would not recommend dual boot – always a horrible solution.

Rather, when I recently explored about Chromebooks and Chrome OS, it was like the proverbial lightbulb illuminating in my head. Containers (used to implement Linux and Android on Chrome OS) change everything. It makes total sense: a secure, locked-down base operating system, and arbitrary applications running in isolated containers on top.

Could Chrome OS run Windows in a container? Not directly, since containers are isolated from the host operating system but share its base files and resources. However you could run Windows in a VM on a Chromebook, and with a bit of integration work this could be relatively seamless for the user. Systems like Parallels do this trick on MacOS. Instead of the wretched inconvenience of dual boot, you could run a Linux app here, and a Windows app there, and everything integrates nicely together.

Microsoft could also re-engineer Windows along these lines. A lot of the work is already done. Windows supports containers and you can choose the level of isolation, with either lightweight containers or containers based on Hyper-V. It also supports Linux containers, via Hyper-V. Currently this is not designed for client applications, but for non-visual server applications, but his could change. It is also possible to run Linux containers on the Windows Subsystem for Linux, though not currently supported.

Windows RT failed for a few reasons: ARM-only, underpowered hardware, Windows 8 unpopularity, and most of all, inability to run arbitrary x86 Windows applications.

A container-based Windows could have the security and resilience of Windows RT, but without these limitations.

So I can imagine Google giving us the ability to run virtual Windows on Chrome OS. And I can imagine Microsoft building a future version of Windows in which you can run both Windows and Linux applications in isolated environments.

Linux Foundation Open Source Summit opens in Edinburgh: Microsoft praised for “facing reality”

The Linux Foundation Open Source Summit kicked off in Edinburgh today, with Executive Director Jim Zemlin declaring that the organization is now adding a new member daily. The Linux Foundation oversees over 150 open source projects, including Linux, Kubernetes, Let’s Encrypt, Cloud Foundry and Cloud Native Computing Foundation, and has over 1320 members.

image

Microsoft has been a member for several years, but has now also signed up to the Open Invention Network (OIN), promising patent non-aggression to other licensees. It is a significant move which has boosted both the OIN and the Linux Foundation.

image
Linux Foundation Executive Director Jim Zemlin

Keith Bergelt,, CEO of OIN, took the stage to congratulate Microsoft on “facing the reality of the world as it is.”

Another important recent event is the statement by Linus Torvalds, in which he apologises for brusque behaviour and says he is taking some time off Linux kernel development:

“I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely. I am going to take time off and get some assistance on how to understand people’s emotions and respond appropriately.”

What are the implications for Linux? Nobody known; though LWN’s Jonathan Corbet spoke at this morning’s keynote to assure us that a new code of conduct in which kernel developers promise to be nicer to each other will be a good thing.

I interviewed Zemlin today and will post more from the event soon.

Linux applications and .NET Core on a Chromebook makes this an increasingly interesting device

I have been writing about Google Chromebooks of late and as part of my research went out and bought one, an HP Chromebook 14 that cost me less than £200. It runs an Intel Celeron N3350 processor and has a generous (at this price) 32GB storage; many of the cheaper models have only 16GB.

This is a low-end notebook for sure, but still boots quickly and works fine for general web browsing and productivity applications. Chrome OS (the proprietary version of the open source Chromium OS) is no longer an OS that essentially just runs Google’s Chrome browser, though that is still the main intent. It has for some time been able to run Android applications; these run in a container which itself runs Android. Android apps run fairly well though I have experienced some anomalies.

Recently Google has added support for Linux applications, though this is still in beta. The main motivation for this seems to be to run Android Studio, so that Googlers and others with smart Pixelbooks (high-end Chromebooks that cost between £999 and £1,699) can do a bit more with their expensive hardware.

I had not realised that even a lowly HP Chromebook 14 is now supported by the beta, but when I saw the option in settings I jumped at it.

image

It took a little while to download but then I was able to open a Linux terminal. Like Android, Linux runs in a container. It is also worth noting that Chrome OS itself is based on Linux so in one sense Chromebooks have always run Linux; however they have been locked down so that you could not, until now, install applications other than web apps or Android.

Linux is therefore sandboxed. It is configured so that you do not have access to the general file system. However the Chromebook Files application has access to your user files in both Chrome OS and Linux.

image

I found little documentation for running Linux applications so here are a few notes on my initial stumblings.

First, note that the Chromebook trackpad has no right-click. To right-click you do Alt-Click. Useful, because this is how you paste from the clipboard into the Linux terminal.

Similarly, there is no Delete key. To Delete you do Alt-Backspace.

I attribute these annoyances to the fact that Chrome OS was mostly developed by Mac users.

Second, no Linux desktop is installed. I did in fact install the lightweight LXDE with partial success but it does not work properly.

The idea is that you install GUI applications which run in their own window. It is integrated so that once installed, Linux applications appear in the Chromebook application menu.

I installed Firefox ESR (Extended Support Release).  Then I installed an application which promises to be particularly useful for me, Visual Studio Code. Next I installed the .NET Core SDK, following the instructions for Debian.

image

Everything worked, and after installing the C# extension for VS Code I am able to debug and run .NET Core applications.

I understand that you will not be so lucky with VS Code if you have an ARM Chromebook. Intel x86 is the winner for compatibility.

What is significant to me is not only that you can now run desktop applications on a Chromebook, but also that you can work on a Chromebook without needing to be deeply hooked into the Google ecosystem. You still need a Google account of course, for log in and the Play Store.

You will also note from the screenshot above that Chrome OS is no longer just about a full-screen web browser. Multiple overlapping windows, just like Windows and Mac.

These changes might persuade me to spend a little more on a Chromebook next time around. Certainly the long battery life is attractive. Following a tip, I disabled Bluetooth, and my Chromebook battery app is reporting 48% remaining, 9 hrs 23 minutes. A little optimistic I suspect, but still fantastic.

Postscript: I was always a fan of the disliked Windows RT, which combined a locked-down operating system with the ability to run Windows applications. Maybe container technology is the answer to the conundrum of how to provide a fully capable operating system that is also protected from malware. Having said which, there is no doubt that these changes make Chromebooks more vulnerable to malware; even if it only runs in the Linux environment, it could be damaging and steal data. The OS itself though will be protected.

Ubuntu goes minimal (but still much bigger than Alpine Linux), cosies up to Google Cloud Platform

Ubuntu has announced “Minimal Ubuntu”, a cut-down server image designed for containerised deployments. The Docker image for Minimal Ubuntu 18.04 is 29MB:

Editors, documentation, locales and other user-oriented features of Ubuntu Server have been removed. What remains are only the vital components of the boot sequence.  Images still contain ssh, apt and snapd so you can connect and install any package you’re missing. The unminimize tool lets you ‘rehydrate’ your image into a familiar Ubuntu server package set, suitable for command line interaction.

says Canonical.

29MB is pretty small; but not as small as Alpine Linux images, commonly used by Docker, which are nearer 5MB. Of course these image sizes soon increase when you add the applications you need.

I pulled Ubuntu 18.04 from Docker Hub and the image size is 31.26MB so this hardly seems a breakthrough.

Canonical quotes Paul Nash, Group Product Manager for Google Cloud Platform, in its press release. The image is being made available initially for Amazon EC2, Google Compute Engine, LXD, and KVM/OpenStack. The kernel has been optimized for each deployment, so the downloadable image is optimized for KVM and slightly different than the AWS or GCP versions.

Case sensitive directories now possible in Windows Explorer as well as in the Windows Subsystem for Linux

Experienced Windows users will know that occasionally you hit a problem with case sensitivity in file names. The problem is that on Linux, you can have files whose name differs only in case, such as MyFile.txt and myfile.txt. Windows on the other hand will not normally let you do this and the second will overwrite the first.

The latest build of Windows 10 (1803, or the April 2018 Update) has a fix for this. You can now set directories to be case-sensitive using the fsutil command line utility:

fsutil.exe file setCaseSensitiveInfo <path> enable

You can then enjoy case sensitivity even in Windows Explorer:

image

This is not particularly useful in Windows. In fact, it is probably a bad idea since most Windows applications presume case-insensitivity. I found that using Notepad on my case-insensitive directory I soon hit bugs. I double-click a file, edit, save, and get this:

image

Press F5 and it sorts itself out.

Developers may have written applications where a file is specified with different case in different places. Everything is fine; it is the same file. Then you enable case-sensitivity and it breaks, possibly with unpredictable behaviour where the application does not actually crash, but gives wrong results (which is worse).

If you are using WSL though, you may well want case-sensitivity. There are even applications which will not compile without it, because there are different files in the source whose name differs only by case. Therefore, WSL has always supported case-sensitivity by default. However, Windows did not recognize this so you had to use this feature only from WSL.

In the new version this has changed and when you create a directory in WSL it will be case-sensitive in both WSL and Windows.

There is a snag. In the full explanation here there is an explanation of how to adjust this behaviour using /etc/wsl.conf and also the warning:

Any directories you created with WSL before build 17093 will not be treated as case sensitive anymore. To fix this, use fsutil.exe to mark your existing directories as case sensitive.

Hmm. If you are wondering why that application will not compile any more, this could be the reason. You can set it back to the old behaviour if you want.

Should Microsoft have made the file system case-sensitive? Possibly, though it is one of those things where it is very difficult to change the existing behaviour, for the reasons stated above. Note that Windows NT has always supported case-sensitive file names, but the feature is in effect disabled for compatibility reasons. It is poor for usability, having files whose names differ only in case which are therefore easily confused. So I am not sure. Being able to switch it on selectively is nice though.

Chromebooks get more useful as Linux comes to Chrome OS

At Google’s IO conference under way in San Francisco, the company has announced the ability for a Chromebook to run Linux applications.

image

“Support for Linux will enable you to create, test and run Android and web app for phones, tablets and laptops all on one Chromebook. Run popular editors, code in your favourite language and launch projects to Google Cloud with the command-line. Everything works directly on a Chromebook,” says product manager Ton Buckley. “Linux runs inside a virtual machine that was designed from scratch for Chromebooks. That means it starts in seconds and integrates completely with Chromebook features. Linux apps can start with a click of an icon, windows can be moved around, and files can be opened directly from apps.”

Squinting at the screen in Google’s photo, above, it looks like the Linux VM runs Debian.

Coupled with the existing ability to run Android apps, the announcement makes Chromebooks more attractive for users (and I am one of them) who would previously have found the operating system too restrictive.

Buckley presents the new feature as primarily one for developers. You will be able to build and test Android applications directly on the Chromebook. Given the operating system’s native support for Android, this should be an excellent machine for Android development.

One of the first things I would install would be Visual Studio Code, presuming it runs OK. Thanks to .NET Core, ASP.NET development should work. The LAMP stack running locally would be great for  PHP development.

Personally I would not only use it for coding though. The ability to run LibreOffice would be great, for example. There are also a ton of handy Linux utilities for admins.

Top feature: security

The key attractions of Chromebooks (aside from low prices from OEM vendors) is security. They are popular in education for this reason. They require less management than PCs because the operating system is locked down and self-patching. The new feature should not compromise security too much, because Linux runs in a VM and in the worst case resetting the VM should clear any malware – though access to user documents could make malware running in the VM quite disruptive.

Apple’s iPad Pro is another capable device with a locked down OS, but does not run Linux applications.

What about Windows? Microsoft has tried and so far failed to lock down Windows in a manner acceptable to its customers. Windows RT was the first attempt, but users found it too restrictive, partly because the Windows 8 app ecosystem was so weak. Windows S is another attempt; but progress is slow. Microsoft has also weakened the security of its modern app platform to make it more capable, even to the extent of allowing desktop applications into the Windows Store. The approach taken by Apple and Google, to design a new secure operating system and make it gradually more capable, is more viable than Microsoft’s work in the opposite direction.

Why Subsystem for Linux in Windows 10 and Windows Server? And what are the implications?

Microsoft is busy improving Windows Subsystem for Linux (WSL), the compatibility layer that lets you run Linux on Windows. WSL is not an emulator. It accesses the same file system and you can launch Windows applications from WSL, and vice versa. It also runs actual Linux binaries.

The latest announcements cover copy/paste between Linux and Windows, and a tabbed console. Both enhancements are in the skip-ahead insider version of Windows 10, which means they are unlikely to be in the one about to be released, currently known as Spring Creators Update (but rumoured to be getting a name change). In other words, you may have to wait around six months for this to be generally available.

image 

These are not huge changes, but overall WSL is a big deal. Why is Microsoft doing it? One Betanews commenter says:

I still can’t figure out who this whole "Linux-on-Windows" thing is meant for. Developers who work on both platforms maybe? I guess it would be handy for people who just want to try out Linux before migrating to it, but that’s the last thing Microsoft would want to promote.

Microsoft has in fact stated the primary purpose of WSL:

This is primarily a tool for developers — especially web developers and those who work on or with open source projects. This allows those who want/need to use Bash, common Linux tools (sed, awk, etc.) and many Linux-first tools (Ruby, Python, etc.) to use their toolchain on Windows.

There is a bit more to it. Developers are small in number relative to general users, but disproportionately influential, since they make the applications the rest of us run, and if the applications are not there or are inferior, the ecosystem starts to fail and the operating system declines.

I am not sure when it was that developers started to prefer Macs, but I noticed this trend many years ago, perhaps from the time that OS X moved to x86 (2006). This was not just about preferring the Mac user interface. In 2008 Apple opened up iOS, its mobile OS, to third-party applications, and a Mac was required for iOS development (this is still the case). It has long been relatively easy to run a Windows emulator on a Mac, but not vice versa, so for developers who want to support multiple target platforms from one computer, the Mac makes sense.

OS X / macOS is a Unix-like operating system, based on BSD (Berkeley Software Distribution). This means that moving between Linux and Mac is relatively smooth, from a developer perspective. The same tools are generally available. The internet runs mostly on Linux so the Mac has an advantage there as well.

In some cases this is more than just inconvenience. Windows has a long-standing issue with path lengths. MAX_PATH is defined as 260 characters. This limitation can be mostly removed if you have Windows 10 build 1607 or higher. Nevertheless, path issues have made Windows awkward for developing with Java, Node.js, and other languages or frameworks which typically use deeply nested directories. Open source developers perhaps did not care as much about these issues because they were mostly using Mac or Linux.

Microsoft has responded by improving Windows as a platform on which to develop applications. Visual Studio now targets Mac, iOS and Android as well as Windows. MAX_PATH has been alleviated as far as possible. WSL however goes much further. You can install and run Linux development tools and utilities such as gcc, perl, sed, awk, grep, wget, openssl, perl and more. There is no MAX_PATH issue. You can run the Linux build of Apache, PHP, MySQL and more. I used WSL to debug a PHP application and explained how here.

WSL is not perfect. Not everything is implemented. You can check the current issues here. Still, it is genuinely useful and mitigates the advantages of Mac or Linux for developers.

Microsoft has also added WSL to Windows Server. Why? The main focus here seems to be on administrators. There are times when it is handy to run a Linux command or script on Windows Server. It is not intended for production use as a server, though there is now support for background tasks; however it is still per-session so you would need to keep a user logged on in order to run, for example, a web server. More important, Microsoft has not designed WSL for production use as a server platform so it might not be as optimized or reliable as you require.

Implications of WSL

Where is this going? This is where it gets speculative. I will argue though that WSL is in part an admission of defeat. Windows remains an important development platform, but is now greatly outweighed by Unix-like platforms:

  • Web/Internet applications
  • iOS applications
  • Android applications

Where Windows support is needed, developers have many cross-platform options to choose from, a popular choice today being Electron, based on Chromium (the open source foundation of Google Chrome) and Node.js.

Today there seems little chance of Windows winning back market share as a mobile operating system, and the importance of desktop applications looks destined for long slow decline.

Windows Server remains a significant application platform, but Microsoft is focused more on driving developers to Azure cloud services than on Windows Server itself. SQL Server now runs on Linux, ASP.NET Core is cross-platform, and Azure has excellent support for Linux.

All of this leads me to think that WSL will continue to improve, perhaps to the point where production loads are supported on Windows Server, for example. Further, the ability to run Windows applications on Linux (which is more or less what happens in SQL Server for Linux) may become equally as important as the reverse.