I'm writing this on my new desktop computer.

It's a Linux system I chose after deciding to migrate from ChromeOS back to Linux: a System76 Merkaat short case mini PC with a 5 GHz 13th gen Intel Core i7 processor, Intel Iris Xe graphics, 32 GB RAM, 500 GB SSD, 2.5 G Ethernet, and Wi-Fi 6. It replaces an ASUS Chromebox 3 I used since 2018.

I installed Linux Mint 21.3 Cinnamon Edition, configured the operating system, and downloaded the main programs I need. This is my experience after a week of usage.

In short, I absolutely love the Markaat and Mint which both exceed my expectations.

Hardware

The Merkaat case has a similar footprint and convenient port locations as the Chromebox but is noticeably smaller. This is the Merkaat connected via USB-C to a VOTNUT USB speaker.

A 23” HP Pavillon 23cw LCD screen, a wireless TedGen keyboard, a wireless Logitech M220 mouse, and a Logitech c920 webcam round up the hardware setup on a desk next to the bookcase where the Merkaat is. A Brother HL-L2340DW wireless laser printer sits nearby.

At the highest spin rate the Merkaat fan is quieter than the Chromebox one at the lowest. Speaking of cooling, the case doesn't go much past slightly warm.

Software

In the first week with Mint I discovered many little Linux features and customization options I didn't know I wanted until I escaped the confines of ChromeOS. They make a difference in everyday work and reduce friction.

I use Cinnamon, the flagship desktop environment of Mint. I had no prior exposure to it but I like its pleasant design, features, and coherence. The environment strikes a good balance between ease of use and customizability. But aside from adding a few program icons to the panel as in the screenshot, so far I haven't customized Cinnamon much.

It's still early to comment on the stability of Linux, especially with system updates and upgrades to major versions of the distro, and it's something I'll monitor. But Mint has been working smoothly over the first week.

Usage

The new system is fading into the background.

In everyday use it's getting easier to focus on the task at hand without thinking much to how to accomplish it on Linux. This is all I can ask of a system: supporting my work and getting out of the way.

I'm also unlearning almost a decade of ChromeOS muscle memory and workflows, and relearning the Linux way.

Setup and configuration

Installing Mint was uneventful, mostly.

I flashed the Mint USB boot stick on the Chromebox using the ChromeOS Recovery Utility. But when I booted the stick the Merkaat displayed a long series of scary looking errors, as the ISO was somehow corrupted or incorrectly encoded.

I had to start Pop!_OS preinstalled on the Merkaat and flash the stick again. Booting Mint from the reflashed stick finally led me through the few simple steps of the installation flow.

The installer allowed me to set different languages for the Linux user interface and locale. I want the Italian locale, as I live in Italy, but the English user interface, which comes more natural for tech stuff. Nice, I don't remember it being so easy when I last installed Linux a dozen years ago.

Configuring the system also involved installing the System76 Driver required for sound and other hardware support.

I worried Linux wouldn't fully detect my hardware or not work well with it. But you know who malfunctioned? Yours truly.

At first I didn't realize the pairing of my Mixcoder E9 Bluetooth headphones completed successfully and thought something was off. Also, no sound coming from the USB speaker had me puzzled until I figured the volume was turned all the way down. Doh.

Mint actually detects and fully supports all the hardware of the Merkaat and the connected peripherals including audio, Bluetooth, Wi-Fi, and the printer.

I turned on the printer and, while figuring how to run the Mint print manager, a notification informed the unit was added. This is pure magic.

Performance

The 13th gen Intel Core i7 processor of the Merkaat is five generations newer than the 8th gen of the Chromebox and, along with double the RAM, the upgrade can be felt. The machine is snappy and responsive. I no longer observe the subtle but perceivable lag associated with most actions on the Chromebox.

The system takes slightly longer to boot than the Chromebox but still under twenty seconds.

On average, with comparable workloads Linux consumes a few GB less RAM than ChromeOS. As I write this about 5 GB of RAM are in use and around 3 GB of cache, out of 32 GB.

Firefox is now my primary browser. For some tasks or actions Firefox seems slightly slower than than Chrome, but still perfectly useable and more than reactive.

Community

For researching, setting up, and configuring the new system I relied on three main sources of information and support: the Linux Mint Forums, Mastodon, and System76. From all the sources I received prompt, informative, and helpful answers to my questions and requests for assistance.

The community is a valuable feature of Mint and Linux and I hope to give back in some way.

Conclusion

Using the Merkaat for a week drove home how much I missed out over the past decade.

I'm really happy I finally found the motivation and momentum to leave ChromeOS for Linux. The Merkaat and Linux rewarded my decision with smooth sailing.

It feels good to be back home.

#Linux #ChromeOS

Discuss... Email | Reply @amoroso@fosstodon.org

I'm going back to Linux after nine years of ChromeOS.

In 2015 I had been using Linux for a couple of decades. Exasperated by the frequent maintenance issues, that year I migrated to ChromeOS. I was living in the browser anyway and ChromeOS seemed like a stable alternative, so I switched. Linux system updates often broke the Nvidia drivers or X11 and dumped me to the text console with no clue what to do. At some point I even stopped performing updates.

Almost a decade later, something changed and made me want to leave ChromeOS for Linux. This post records the motivations for the switch, lists my requirements, and describes the hardware and software setup I came up with for my new Linux system.

Motivation

ChromeOS served me well. It fulfilled my needs, nearly eliminated maintenance, and made upgrading to new devices as simple as signing into an account.

However, in all these years Linux has come a long way in features and usability. Getting a Raspberry Pi 400 gave me a glimpse at how much Linux improved.

These are not the only reasons for migrating though.

Google is considering for ChromeOS a feature similar to Windows Recall. Which is a deal breaker.

Although Google may implement the feature in a thoughtful way, it bothers me not just in itself but for the trend it hints at. I'm not interested in the wave of new AI features the market is pressuring tech companies to deliver.

Another motivation for moving to Linux is a consequence of how my use of ChromeOS changed.

Although I always relied on cloud applications, for the past few years I've been running more Linux programs under the Crostini Linux container of ChromeOS, such as emulators and specialized tools. And I've been increasingly bumping into subtle limitations of the Crostini environment like GUI rendering and keyboard issues, missing features, and minor incompatibilities here and there.

The solution is to move to a full, native Linux system.

The requirements

My experience with Chrome and Crostini on ChromeOS shaped the requirements for the new Linux system.

Hardware

My ChromeOS daily drivers have been Chromeboxes, the latest of which an ASUS Chromebox 3 since 2018. The device has an 8th gen Intel Core i7 processor, an Intel graphics chip, 16 GB RAM, 256 GB of storage, and 1 G Ethernet.

With their compact size and easy access to all ports at desk level, Chromeboxes made me fall in love with the mini PC form factor. The new machine must be a mini PC too.

The performance of the ASUS Chromebox 3 matches well my needs based on a mix of web apps and Linux software. The most graphically demanding programs I run are astronomy applications like Celestia and Stellarium or tools like basic video editors. The graphics chip of the ASUS Chromebox 3 makes them run well with no noticeable lag or stutter.

My typical workload consists of a dozen Chrome tabs plus one or two Linux programs. This computing mix usually fills half a dozen GB of RAM out of 16 GB. The local files take up about 160 GB of the available 256 GB storage.

I'm not a gamer and don't need a gaming rig. I don't plan to do machine learning either. However, I want extra room in the specs to accommodate some growth in my computing needs.

An updated Intel Core i7 processor and double the current RAM and storage seem adequate. The hardware should have good Linux compatibility, which doesn't mesh well with Nvidia chips. I don't need all that horsepower anyway as an Intel graphics chip is perfectly adequate.

Software

Again, my ChromeOS experience guided also my software requirements. I don't run servers and typically use web applications and Linux programs, so most Linux distros would do. However, I have a few extra requirements for a better setup and maintenance experience.

I want a desktop distro that's easy to install and maintain. It should be popular, actively maintained, and not controlled by a corporation.

On the technical side, my ideal distro should support a wide range of hardware and peripherals. Since most of the programs I need are available as .deb packages the distro must be based on or derived from Debian, default to APT, and not force alternate package managers like Snap. In addition, the distro should provide common software and support for installing multimedia codecs without jumping through hoops.

Although I'd appreciate a distro ready for Wayland, I actually have no immediate need for Wayland's features. I'd just like to put the transition from X11 behind me.

I never used Android apps much, which few developers bothered to adapt to ChromeOS anyway. I won't miss them on Linux.

The setup

Researching the right hardware and software combination was harder than anticipated because of two main reasons. First, I have been out of the Linux and PC loop for so long I'm not much familiar with the latest Linux features, desktop environments, and PC hardware.

Searching the web to make sense of the computer market and the huge selection of mini PCs was equally hard. Most keywords associated with the relevant queries are so high traffic the search result pages are filled with ads, SEO-optimized content, and noise.

I mostly skipped googling and went with asking around and browsing through the product listings of manufacturers I already know, who design for Linux, or are recommended by trusted sources.

A lot of reading and thinking later, I came up with a setup I'm pleased with.

Hardware

My new daily driver is a System76 Merkaat mini PC with a short case, a 13th gen 5 GHz Intel Core i7 processor, Intel Iris Xe graphics, 32 GB RAM, 500 GB SSD, 2.5 G Ethernet, and Wi-Fi 6.

The machine has two killer features. It's designed for Linux and should have little or no compatibility issues. Also, System76 let me configure the product with exactly the specs and features I wanted: processor, RAM size, storage size, and so on. The one size fits all models by other manufacturers typically miss one or more of the features I want.

I need no additional peripherals as I'll use those of the Chromebox: a 23” HP Pavillon 23cw monitor, a wireless TedGen keyboard, a wireless Logitech M220 mouse, a Logitech c920 webcam, a Blue Yeti microphone, and a Brother HL-L2340DW printer.

The only downside is System76 is an American company and I live in Italy, so dealing with import taxes and duties will be a bloodbath. But I hope the investment will pay off.

Software

Linux Mint is the distro that ticks all my boxes and I'll install on the System76 Merkaat.

It's popular, easy to use, low maintenance, and with no known incompatibilities with System76 devices. It comes with a lot of software out of the box, including multimedia codecs.

A non technical feature that impressed me is Mint is a community distro, which makes the interests of users align with those of developers. Making Snap optional drove this home.

Wayland is optional and experimental on Mint. Hopefully, when Wayland is ready, Mint will provide a smooth upgrade path.

What's next

I ordered the System76 Merkaat and the device is on its way to me. It should land here in a week or so. When I set up the system and play with it a bit, I'll share my impressions.

In the meantime, please excuse me while I refresh the tracking status of the shipment.

#Linux #ChromeOS

Discuss... Email | Reply @amoroso@fosstodon.org

ChromeOS Stable 121 rolled out to my ASUS Chromebox 3 and brought with it a one-click option to upgrade Crostini.

Crostini, the Debian based Linux container of chromeOS, was running Bullseye prior to that. ChromeOS 121 popped up a notification with a button offering to upgrade to Debian Bookworm 12.4. After backing up the container I clicked the button in the notification, skipped the backup option as I had already done it, and clicked another button to start the upgrade.

The process was uneventful. ChromeOS displayed a dialog with status messages informing on the progress, then a final message confirming the successful completion.

I checked out the main Linux programs I use and they all seem to be working fine on Bookworm, as well as everighing else. Some programs actually look better as they're built on GUI frameworks that come with an updated and refreshed design.

Upgrading Crostini from Buster to Bullseye a couple of yeas earlier was less smooth. Back then chromeOS didn't provide any user interface for activating the upgrade, so I had to manually run a script. Although the process completed with a few errors, Bullseye has always worked fine on Crostini since then.

#chromeOS #Linux

Discuss... Email | Reply @amoroso@fosstodon.org

I bought a lovely little computer, a Raspberry Pi 400, and two accessories, a 64 GB Samsung Pro Endurance microSD card to hold the file system and a very cheap Full HD webcam for video calls.

I always wanted a Raspberry computer but assumed the components and cables would take up too much space at my work station.

Recently though I carefully inspected the layout of my desk, the HDMI ports of my HP Pavillon 23cw monitor, and the nearby electrical sockets. Researching the Raspberry Pi 400 convinced me I could set the device on the desk with minimal inconvenience and little space.

This is not a full review but a collection of early impressions and usage notes after working with the device for a week.

Motivations

Although I have possible uses for the Pi 400, one of the reasons why I got it is not technical: the computer has a delightful form factor.

My daily driver, an ASUS Chromebox 3, is a high end desktop system. But the opportunity of using a different device with a nice form factor is a welcome and refreshing context switch that helps productivity and makes things fun. It's like writers spending time at Starbucks to get some work done instead of sitting and typing at their desk at home.

Another reason for getting the Pi 400 is I always loved Linux. Since switching to chromeOS in 2015 I've been thinking of how to set up a Linux box as a secondary computer within the constraints of my work station. The Pi 400 finally enabled this possibility.

Another major consideration that drew me to the Pi 400 is it's a full, native Linux system specifically designed as a combination of hardware and software to run Linux. Raspberry Pi OS is tightly integrated with the hardware and well supported, which will hopefully spare me the nightmares of Linux updates frequently breaking X-Windows back in the day.

Finally, I wanted a computer for experimenting with various computing technologies, such as ARM on the desktop. And, of course, I wanted an extra computer to play with Medley and other Lisp systems.

The Pi 400 is a member of the Raspberry family at the heart of countless electronics and IoT projects. But, since I'm not a hardware guy, I'll use it mostly as a desktop productivity and software development environment.

Reviews

I extensively researched the Pi 400 and a key theme of what I learned is performance.

The reviews describe and evaluate performance through a wide range of experiences that doesn't make it easy to figure what to expect. Perhaps because the specs place the device at a spot of the performance spectrum along the transition between realizing responsiveness is suboptimal, and not noticing anything unusual about the way the system reacts.

Therefore, given the affordable price, I accepted the small risk of disappointment and went with the Pi 400.

What I think the reviews don't highlight enough is that, even at the lower end of the performance spectrum, Raspberry absolutely nailed the combination of form factor and price of the Pi 400. It sits at a local maximum in the product space that delivers tremendous value for the money.

Hardware

The Italian keyboard of my Pi 400, which makes up the entire device, has nearly the same size as the TedGen keyboard of my Chromebox. The keys of the Pi 400 are actually slightly larger than those of the TedGen and support well my typing speed, which is not much.

I feel at ease with the Pi 400 keyboard because I prefer short-travel chicklet units. The plastic feel and feedback aren't an issue for me as, again, the mechanics and build don't interfere with my relatively slow typing.

Although not as smooth and precise as the Logitech mouse of my Chromebox, the Pi 400 one is acceptable despite the occasional lower than average responsiveness.

The Pi 400 instantly recognized the new Full HD webcam as well as my Mixcoder E9 Bluetooth headphones and Brother HL-L2340DW wireless printer. The webcam delivers a smooth feed with Google Meet and good image quality for the price.

Software

I've been using Unix since the early 1990s and Linux since the mid 1990s, so the Raspberry Pi OS desktop and system look mostly familiar.

I personalized the desktop environment to make it look similar to my Chromebox. I set a similar background color, moved the taskbar to the botton like the chromeOS shelf, and set Chromium as the default browser with a matching tab layout.

This is what my Raspberry Pi OS desktop looks like:

Since my daily driver on the desktop is a Chromebox I mostly live in the browser, with a number of tabs often open on Google products. On the Pi 400 Chromium works well enough with Google web apps. But I can't synchronize my extensions and settings with chromeOS as Google removed the functionality from Chromium.

Although most of the programs I need are available, I haven't found an easy to install screencasting tool with Wayland support.

Usage

I don't leave the Pi 400 permanently on the desk but set it up on demand.

Whenever I need the device I bring it out, set it on the desk, and connect the cables. One of the cables goes into the HP monitor which the Pi 400 shares with the Chromebox. I can use either computer by switching the monitor input signal with a button.

The only Ethernet wall socket close to the desk is permanently hooked to the Chromebox. The Pi 400 accesses the network over Wi-Fi at up to 70-80 Mbps.

Setup and configuration

To initially set up the Pi 400 I connected it to the Ethernet socket so the required large file downloads and system updates could go faster.

For installing the operating system on the microSD card I originally planned to run the Raspberry Pi Imager tool on my Chromebox under the Debian based Crostini Linux. But, although Raspberry Pi OS is derived from Debian, the only binaries of such an essential tool are available only for Ubuntu. Raspberry does provide instructions for building a package for Debian but network installation on the Pi 400 seemed simpler.

I selected the 64-bit version of Raspberry Pi OS Bookworm desktop and recommended software.

Despite the simplicity of the process, which can complete in less than a quarter of an hour, it took me three reinstallations and a couple of hours because of a subtle Raspberry Pi Imager bug.

I also configured SSH and headless access to the Pi 400 from my Chromebox with the recommended VNC client TigerVNC, the only one that supports Wayland on Raspberry Pi OS Bookworm. But the Pi 400 is just too slow and laggy over VNC with my setup, which makes it viable in a pinch.

Performance

The Pi 400 is no gaming rig but delivers enough performance for most ordinary tasks without the feel of constant wait and lag.

This supports well the kinds of tasks I ordinarily carry out such as running a browser with half a dozen tabs, a terminal, and another program or two. I don't consume much media.

The most noticeable manifestation of performance limitations is that programs don't start up instantaneously. For example, Chromium comes up in about 4 seconds. But once programs start, they run with mostly instantaneous responsiveness for common tasks.

YouTube streams consistently smoothly over Wi-Fi at 1080p and full screen, but entering or leaving full screen mode freezes the browser for a few seconds.

I don't mind the overall experience as I'm used to systems with similar architecture like cheap Android tablets and Chromebooks. The Pi 400 actually feels snappier than my Lenovo Yoga N26 Chromebook.

Although not architecturally similar to the Pi 400, the 8-bit single board computers I use for my retrocomputing projects, such as the Z80-MBC2, deliver a comparable feel that's part of the expected experience.

Speaking of retrocomputing, one the reason I got the Pi 400 is to run Medley, other historical Lisp systems, and emulated classic computers at a level of performance closer to the originals. Running Medley on powerful desktop systems or in the cloud is much faster, thus limiting the appreciation of certain design decisions, features, or workflows the systems imposed back in the day.

The more I use the Pi 400, the more the perception of not operating a powerful computer is fading away as I focus on the tasks I use it for.

An example can express and synthesize this perception. As I said earlier, I configured the desktop environment of the Pi 400 to look similar to that of my Chromebox. The Pi 400 often feels so smooth I forget I'm not on the Chromebox.

Conclusions

it's been a week since I unboxed the Pi 400 and I love it.

The product has the perfect combination of features, form factor, and price for my needs. This surprisingly capable little computer is one of the rare lovely products that encourage to use it, be productive, and have fun.

#pi400 #linux

Discuss... Email | Reply @amoroso@fosstodon.org

To code on the Z80-MBC2 and V20-MBC homebrew computers I often transfer text files to and from their CP/M environments.

In one direction I send files from Crostini Linux by dumping them to CP/M, where PIP saves the text to CP/M files. In the opposite direction I run PIP on CP/M to print the files to the screen, where Minicom captures the text and saves it to files on Crostini.

CP/M and Unix have different line break and end of file encodings. In addition, the transfer process may introduce unwanted text. That's why the text files exchanged between the systems need some conversion, to automate which I wrote two short Bash scripts.

The first script, unix2cpm, converts line breaks and the end of file marker in the input to the CP/M encoding and prints the result to stdout. If the optional file name argument isn't supplied the script reads from stdin with a technique I researched. This is the script:

#!/usr/bin/env bash

# Convert line breaks and end of file from Unix to CP/M.
#
# Usage:
#
#   unix2cpm [filename]
#
# Reads from stdin if the optional argument is missing.

input_file="${1:-/dev/stdin}"

cat "$input_file" | unix2dos
echo -e -n '\x1a'

The script calls unix2dos distributed with the dos2unix / unix2dos tools. unix2dos converts line breaks from Unix to MS-DOS, which borrows the encoding from CP/M. unix2cpm needs only to append with echo the ^Z end of file control character.

Once converted, the file is ready to be dumped from Linux to CP/M.

I initiate file transfers in the oppostite direction by executing the Minicom command to capture the terminal output to a file, Ctrl-A L (Capture on/off). Then, at the CP/M prompt, I execute a command like this to print a file to the console:

A>a:pip con:=filename.txt

When printing ends and the A> prompt reappears, I turn off output capture in Minicom to close the capture file. The captured output contains the PIP command in the first line, then the text of the file, and finally the A> prompt in the last line.

To remove the unwanted first and last line I wrote the second script, skipfl (skip first and last). Again, the script reads from stdin if the optional file name isn't supplied and writes to stdout. The code is:

#!/usr/bin/env bash

# Skip the first and last file of the argument file
#
# Usage:
#
#   skipfl [filename]
#
# Reads from stdin if the optional argument is missing.

input_file="${1:-/dev/stdin}"

cat "$input_file" | sed '1d' | sed '$d'

The script calls sed to delete the first and last line with the d command.

No further processing of the captured CP/M output file is necessary as Minicom takes care of inserting the proper line break and end of file encodings.

#z80mbc2 #v20mbc #linux #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

I needed to write some Bash scripts on Linux that read the input from stdin or a file passed as an optional argument, but couldn't figure how.

Googling turned up several designs and examples, such as on StackOverflow, where the script directly processes the input. But I actually wanted the script to assemble a pipeline, feed the input into the beginning, and delegate the processing to the programs and filters in the pipeline.

More googling turned up exactly what I wanted, a reply by the user Daniel buried in a long StackExchange thread.

The trick is to assign to a variable the input stream and feed it into the first program of the pipeline. To demonstrate the technique, the script unlc (unique line count) prints the number of unique lines in the input:

#!/usr/bin/env bash

# unlc - print number of unique lines in the optional input file or stdin
#
# Usage:
#
#   unlc [input-file]

input_file="${1:-/dev/stdin}"

cat "$input_file" | sort | uniq | wc -l

The code assigns to input_file the first argument $1 passed to the script, if supplied, or the standard input. Then cat feeds the content of input_file to the rest of the pipeline. The script is invoked by passing a file as an argument or feeding the data into the script's standard input:

$ cat input-file.txt 
1
2
2
3
4
4
4
4
$ unlc input-file.txt 
4
$ cat input-file.txt | unlc
4

Simple and brilliant.

#Linux

Discuss... Email | Reply @amoroso@fosstodon.org

My post on why I use a Chromebox was shared on Hacker News and got enough upvotes to receive more than 4,000 views over a day. The feedback in the comments made me realize I didn't explain why I use chromeOS instead of Linux, so here goes.

I did use various Linux distros from the mid 1990s until switching to chromeOS, but I got exasperated with maintenance.

Device driver support was suboptimal. System updates would often break something and throw me to the console, forcing to waste days to troubleshoot and fix whatever broke and restore X. These issues were so frequent I ended up deferring to apply system updates, trading features and fixes for stability.

I had enough with Linux maintenance, realized I was living in Chrome anyway, didn't mind Google, and gave chromeOS a try. Seven years and four chromeOS devices later, I never had a single system update issue. And maintenance simply disappeared.

For years I used also Windows and Mac OS X but I liked Linux — and later chromeOS — much more.

#chromeOS #Linux

Discuss... Email | Reply @amoroso@fosstodon.org

Chrome OS 101 was supposed to prompt to upgrade Crostini, its Linux container subsystem, from Debian Buster to Bullseye. A 9to5Google article on Chrome OS 101 noted:

Linux on Chrome OS now uses Debian 11 (Bullseye) with upgrade prompts available in the Settings app for those on Debian 10 (Buster). You also now get an upgrade log that’s saved in the Downloads folder.

However, when Chrome OS Stable 101.0.4951.59 landed on my ASUS Chromebox 3 with Crostini running Buster, I got no such prompt. A comment by the user Mr. Smith on an About Chromebooks post about upgrading to Bullseye clarified the prompt is hidden behind a flag.

I went through the upgrade process Mr. Smith outlined and it worked, sort of. Here are the steps I took:

1. enable the flag chrome://flags#crostini-bullseye-upgrade
2. reboot Chrome OS
3. accept the prompt to upgrade to Bullseye
4. open the Terminal app

5. run the following shell commands:

   $ sudo apt update
   $ sudo apt full-upgrade -y
   $ sudo apt -y autoremove
   

Sure enough, after rebooting the system I got the upgrade prompt, accepted it, and watched a dialog reporting on the upgrade progress. A dozen minutes later the process ended with the following errors:

Failed to connect to bus: No data available
Failed to connect to bus: No data available
invoke-rc.d: initscript sudo, action "restart" failed.
Failed to connect to bus: No data available
dpkg: error processing package sudo (--configure):
 installed sudo package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 sudo
E: Sub-process /usr/bin/dpkg returned an error code (1)

I'm not sure what triggered the errors. But a few quick checks of Crostini suggested the installed apps work and nothing major seems broken. Therefore, I'm leaving the container upgraded to Bullseye 11.3 as is and monitor it.

#chromeOS #Linux

Discuss... Email | Reply @amoroso@fosstodon.org

Although Linux had been my daily driver for almost two decades, when I switched to Chrome OS I regarded the Crostini Chrome OS Linux container mostly as a curiosity.

Sure, I was eager to have some fun with Linux on my Chromebox. But I already lived fully in the cloud and web apps met all my computing needs. I assumed the main use cases for Crostini were advanced development or DevOps.

To check out Crostini, I installed some astronomical image visualization and processing software for Linux. Next, I used Python preinstalled on Crostini to test the code I was writing with Repl.it and make sure it ran on a different system.

When I began working on Suite8080, a suite of Intel 8080 Assembly cross-development tools in Python, I needed some CP/M emulators and 8080 tools to test the Python programs I was developing, as well as my Assembly code. Again, installing and running such Linux software on Crostini worked well.

I came to love Crostini, now a key component of my Chrome OS toolset. It lets me run all sorts of niche applications and specialized software for my hobby projects and geeky interests.

#chromeOS #Linux

Discuss... Email | Reply @amoroso@fosstodon.org

My work on Suite8080 is making me rediscover the Unix M4 macro processing language.

Suite8080, a suite of Intel 8080 Assembly cross-development tools I'm writing in Python, includes also an assembler. I designed the latter to optionally read from the standard input, a feature that gives for free macro processing via a separate tool like m4. I can feed macro Assembly source to m4 and pipe the expanded output into the assembler.

The M4 language is a good choice thanks to its power and ubiquity on POSIX systems.

However, m4 is an obscure tool with a learning curve made steep by the unintuitive quoting and expansion rules. There are few resources and no books or tutorials. The very few code samples are abstract, short, and formatted with little or no whitespace and indentation, which doesn't help readability.

After extensive online research, I put together a list of the best learning and reference resources:

• GNU M4 manual: the complete reference
• Notes on the M4 Macro Language: an overview with a practical focus
• M4 Playground: a collection of research papers and commented examples
• Stack Overflow questions tagged m4: practical applications and issues
• Working with the M4 Macro Language: a list of resources by James Howard
• M4 tutorial of the COHERENT Unix clone
• m4 support in Opbasm: the macro package of the Opbasm assembler for PicoBlaze microcontrollers (m4 source)

#Linux #development

Discuss... Email | Reply @amoroso@fosstodon.org