Month: March 2023

It seems like every 7-8 years I’m switching operating systems. In 2006 I first
started using Apple, because it was just so damn cool to have a well working
Unix-like system. (I’ll never forget you Snow Leopard).

In 2015 I switched to Ubuntu. Apple’s Software seemed to hit rock bottom at
this point from a quality perspective, and hardware seemed to go obsolete at
a rate I hadn’t seen before. Fed up paying a premium price for a sub-par
product, it was time for a change.

Ubuntu’s fall

Ubuntu was the obvious choice. I want something that just works, and Dell’s
XPS 13 Developer Edition ships with Ubuntu which means hardware support
from Dell itself. Breath of fresh air and fast as hell. The experience was
similar to what people have been saying about the new M1 chips.
But it’s fast because of software, not hardware.

But something changed with Ubuntu in recent years. I think linux users have
a thicker than usual skin when it comes to software issues and are willing
to look past more things. But Ubuntu’s quality has been consistently falling.
I was being worn down, and it seems to be a common sentiment in my bubble.

The best example is Ubuntu’s package manager Snap. A pretty good idea, I like
the branding too but the execution hasn’t been there. Ubuntu users have been
effectively beta-testing this for years. Just to give you an idea I made a
giant list of bugs that I ran into when Ubuntu switched Firefox from apt
to Snap.

To be honest I feel a bit bad ragging on Ubuntu, because without knowing
anything about how the project and Canonical is run, my intuition is
that the steam is just kind of running out for them. Ubuntu feels ‘depressed’,
but maybe it’s all in my head.

Installation

Installation was super smooth. I always forget to make a separate /home
mount, so it took a while to move everything to an external disk and back.

The one thing I always forget to move is my MySQL databases, and today
was no exception.

Non-free stuff

Fedora does not ship with things that aren’t open source. Nothing against that
philosophy (awesome in fact), but personally I don’t mind adding some binaries
for a better experience.

I miss Ubuntu’s Additional Drivers tool, because it told me what to
install. I’m sure the drivers I need are available for Fedora, but I don’t
know what to look for which makes me slightly worried my computer is not
running optimally. Battery feels worse but that could also be my imagination.

Video in Firefox didn’t work at all in stock Fedora. I had to install
ffmpeg to get it to barely function, but then I discovered RPM Fusion, where
I got an even better ffmpeg, plus gstreamer and Intel drivers and I can now watch
beautiful smooth 4K video, and confirmed with intel_gpu_top that I’m using
hardware acceleration.

Gnome

Ubuntu used to have their own desktop environment called Unity. In
2018 they switched to Gnome, but they modified Gnome to keep their
Unity look.

This felt like a good move, because it let them kept their look while
taking advantage of all the Gnome plumbing.

One drawback is that Ubuntu was usually a bit behind with Gnome
features.

Fedora uses stock Gnome. As a result

Truncated by Planet PHP, read more at the original (another 2756 bytes)

In this blog, our expert discusses the new Puppet PHP modules created by Zend, with details on how they work, and how to deploy them to your benefit.

In this blog, our expert discusses how containers can be used to improve PHP application security — including details on container security best practices.

I maintain a few dozen Javascript libraries, and recently updated many of them
to support CommonJS and Ecmascript modules at the same time.

The first half of this article describes why and how I did it, and then all the
hoops I had to jump through to make things work.

Hopefully it’s a helpful document for the next challenger.

A quick refresher, CommonJS code typically looks like this:

const MyApp = require('./my-app');
module.exports = {foo: 5};

And ESM like this:

import MyApp from './my-app.js';
export default {foo: 5};

Except if you use Typescript! Most Typescript uses ESM syntax, but actually
builds to CommonJS. So if your Typescript code looks like the second and
think ‘I’m good’, make sure you also take a look at the built Javascript
code to see what you actually use.

Why support ESM

The general vibe is that ESM is going to be the future of Javascript code.
Even though I don’t think the developer experience is quite there yet, but
more people will start trying ESM.

If you decided to plunge in with ESM, I want my libraries to feel first-class.

For example, I’d want you to be able to default-import:

import Controller from '@curveball/controller';

At the same time most people are still on CommonJS, and I want to continue
to support this without breaking backwards compatibility for the forseeable
future.

The general approach

My goal is for my packages to ‘default’ to ESM. From the perspective of a
library maintainer you will be dealing with ESM.

During the build phase steps are being made to generate a secondary CommonJS
build. As a maintainer you might run into CommonJS-specific issues, but
I suspect people will only see those if the CI system reports an issue.

Our published NPM packages will have a directory structure roughly like this:

- package.json
- tsconfig.json - src/ # Typescript source
- cjs/ # CommonJS
- esm/ # ESM
- test/

We include the original typescript sources to make step-through debugging work
well, and have a seperate directory for the ESM and CommonJS builds.

If you just want to skip to the end and see an example of a package that has
all this work done, check out my @curveball/core package:

• Github source: https://github.com/curveball/core
• Published NPM package contents: https://www.npmjs.com/package/@curveball/core?activeTab=code

Typescript features we don’t use

esModuleInterop

We don’t use the esModuleInterop setting in tsconfig.json. This flag
lets you default-import non-ESM packages like this:

import path from 'node:path';

instead of the more awkward: