is-number is a project by John Schlinkert. John has a background in sales and marketing before he became an open source programmer and started creating these types of single function packages. So far he has about 1400 projects. Not all of them are this small, though many are.

He builds a lot of very basic functionality packages. Get the first n values from an array. Sort an array. Set a non-enumerable property on an object. Split a string. Get the length of the longest item in an array. Check if a path ends with some string. It goes on and on.

If you browse through it’s not uncommon to find packages that do nothing but call another package of his. For example, is-valid-path provides a function to check if a windows path contains any invalid characters. The only thing it does is import and call another package, is-invalid-path, and inverses its output.

He has a package called alphabet that only exports an array with all the letters of the alphabet. There’s a package that provides a list of phrases that could mean “yes.” He has a package (ansi-wrap) to wrap text in ANSI color escape codes, then he has separate packages to wrap text in every color name (ansi-red, ansi-cyan, etc).

To me, 1400 projects is just an insane number, and it’s only possible because they are all so trivial. To me, it very much looks like the work of someone who cares a lot about pumping up his numbers and looking impressive. However the JavaScript world also extolled the virtues of these types of micro packages at some point so what do I know.

I don’t really care about the declarative/imperative thing, to me how many commands you “really need” is beside the point. This is essentially the same argument as the people who say “git is not complex because you only really need checkout/commit/push, just ignore all the other commands.” This doesn’t matter when the official documentation and web resources keep talking about the other billion commands. Even home-manager has this warning at the very top of the page that basically tells you “you need to understand all the other commands first before you use this,” and “if your directory gets messed up you have to fix it yourself.”

These are exactly the same kinds of problems people have with git.

The confusion arises because there are 5 different ways to do the same thing, the non-experimental methods shouldn’t be used even though they’re recommended in the official docs

I appreciate what you’re trying to say, but you’re kind of illustrating exactly the point I was making about conceptual simplicity and atrocious UX.

Nix has the same mix of conceptual simplicity and atrocious user interface as git, but somehow magnified three times over. I’ve tried it multiple times, but could never get over the unintuitive gaggle of commands.

Micro services always require more maintenance, devops, tooling, artifact registries, version syncing, etc.

The initial transition is so huge too. Like, going from 20 to 21 services is no big deal, but going from 1 service to 2 is a big jump in the complexity of your operations.

Yeah, Nvidia really sucks on Linux unfortunately and they simply do not care very much.

Seems like there’s a bunch of solutions out there:

As of 2020, there are several projects that use these methods to provide GUI access to remote computers. The compositor Weston provides an RDP backend. GNOME has a remote desktop server that supports VNC. WayVNC is a VNC server that works with compositors, like Sway, based on the wlroots library. Waypipe works with all Wayland compositors and offers almost-transparent application forwarding, like ssh -X.

Do these not work for your use case?

Lots of tools ignore xdg, and issues asking to add support get bogged down in backwards compatibility problems. The best they achieve is to introduce yet another env variable to control where the config goes. It’s really annoying.

I have a bunch of TOOLX_CONFIG="$XDG_CONFIG_HOME/toolx" stuff in my bashrc.