Yes, I know so much of Alpine's lightweightness comes from not using glibc.

But still, the other options I see are far from being slimmed down. Debian, Ubuntu server, CentOS... They all could use some cuts.

What's the most slimmed down non-desktop distro that still has a glibc base? I honestly don't care if it has its own package manager (build tool handles this for me). Just wanna use it in containers for running server apps.

Yes, I know so much of Alpine's lightweightness comes from not using glibc.

But still, the other options I see are far from being slimmed down. Debian, Ubuntu server, CentOS... They all could use some cuts.

What's the most slimmed down non-desktop distro that still has a glibc base? I honestly don't care if it has its own package manager (build tool handles this for me). Just wanna use it in containers for running server apps.

Some backend libraries let you write SQL queries as they are and deliver them to the database. They still handle making the connection, pooling, etc.

ORMs introduce a different API for making SQL queries, with the aim to make it easier. But I find them always subpar to SQL, and often times they miss advanced features (and sometimes not even those advanced).

It also means every time I use a ORM, I have to learn this ORM's API.

SQL is already a high level language abstracting inner workings of the database. So I find the promise of ease of use not to beat SQL. And I don't like abstracting an already high level abstraction.

Alright, I admit, there are a few advantages:

• if I don't know SQL and don't plan on learning it, it is easier to learn a ORM
• if I want better out of the box syntax highlighting (as SQL queries may be interpreted as pure strings)
• if I want to use structures similar to my programming language (classes, functions, etc).

But ultimately I find these benefits far outweighed by the benefits of pure sql.

Podman is a lot like Docker: a tool for running OCI containers. While it maintains backwards compatibility with Dockerfile and docker-compose syntax, it offers a lot of other benefits:

• daemonless: it can run containers without a daemon process running in the background.
• Rootless: can run containers without root privileges
• pods: can group containers into secluded pods, which share resources and network namespace

Podman has other features I haven't explored yet, like compatibility with Kubernetes yaml file, and being able to run containers as systemd units.

Have you used podman before? What are your thoughts on it?

There was a time where this debate was bigger. It seems the world has shifted towards architectures and tooling that does not allow dynamic linking or makes it harder. This compromise makes it easier for the maintainers of the tools / languages, but does take away choice from the user / developer. But maybe that's not important? What are your thoughts?

In a lot of projects, this is usually done via README. It tells you what running dependencies to install and how to run certain commands.

This can get harder to maintain as things change, the project grows, and complexity increases.

I see two parts to automate here: actually setting up the environment, and running the application or orchestrating multiple apps.

How do you address this?

why?

Because bash feels clunky to write and work with for anything non-trivial, especially compared to other scripting languages.

Why not another scripting language (no compile necessary)?

Because bash and sh are installed nearly everywhere. Any other scripting language means the user is required to have that installed, and that is far less likely to be the case.

If I could write my scripts in a nice syntax, but be sure my users will be able to use it effortlessly by distributing to them compiled versions, then that would make both of our lives easier!

Thoughts? Are there any languges that do this?

Hello all,

I am looking for suggestions for libraries to use on my project. It is a personal project, so I'm happy to experiment with lesser known or new libraries.

The application will be a mix of content-focus and client side interactivity (think to-do list with server side persistence).

My current approach is as follows:

• Server side rendering on NodeJS with a template engine, complemented with client side scripting for interactivity (mostly vanilla JS)
• Use liquidJS as template engine (any alternatives?)
• Use fastify as the HTTP / Backend server with @fastify/view plugin for serving liquidJS (and other template engines)
• use vanilla JS scripts for interactivity and DOM manipulation
• use vanilla-SWR for data fetching, mutation and persistence on server side. Link: droyson/vanilla-swr

Any other suggestions?

React (and Vue, et al) was built with client side rendering in mind. It just does not seem to fit the server side rendering pattern.

What are the use cases? From my perspective, if your app is a rich web app with a lot of interactivity, you probably want CSR and don't benefit much from SSR.

If you have a content-centric site, or a site with some interactivity but not much, you want a static site generator, or SSR. But in that case, a template engine with some smaller client side libraries (jQuery or AlpineJS or idk what all is out there).

Using React SSR for all of these seems like the wrong tool. What am I missing?

suppose I enable CONFIG_CMDLINE_BOOL=y and CONFIG_CMDLINE="...", but I also add a cmdline using efibootmgr via -u option, which one takes precedence and gets executed?

Does an initramfs make this more complicated? does it also have its own cmdline?

The majority of Linux distributions out there seem to be over-engineering their method of distribution. They are not giving us a new distribution of Linux. They are giving us an existing distribution of Linux, but with a different distribution of non-system software (like a different desktop environment or configuration of it)

In many cases, turning an installation of the base distribution used to the one they're shipping is a matter of installing certain packages and setting some configurations. Why should the user be required to reinstall their whole OS for this?

It would be way more practical if those distributions are available as packages, preferably managed by the package manager itself. This is much easier for both the user and the developer.

Some developers may find it less satisfying to do this, and I don't mean to force my opinion on anyone, but only suggesting that there's an easier way to do this. Distributions should be changing things that aren't easily doable without a system reinstall.

hello friends,

I am looking for a way to do what I described in the title. When running command command, I dont want to have to type SOME_ENV_VAR=value command every time, especially if there are multiple.

I am sure youre immediately thinking aliases. My issue with aliases is that if I do this for several programs, my .bashrc will get large and messy quickly. I would prefer a way to separate those by program or application, rather than put them all in one file.

Is there a clean way to do this?