Dirk

Update: Based on the discussion here and in other places I added the following (well, technically I did something different in my colorscheme, but in the end it translates to that)

vim.api.nvim_set_hl(0, 'Normal', {})

This reverts the weird text and background colors to the previous behavior of ... not setting them.

With update 0.10 Neovim behavior changed regarding text color and background color.

I use a color theme that does not set those and previously this worked perfectly fine. Neovim simply used the font color defined in the terminal and had a transparent background.

Now the background is #14161b and the font color is #e0e2ea. Neither of the colors is configured ANYWHERE in my whole setup. Neither in the colorscheme, nor in my terminal configuration, nor in my Neovim configuration.

Is there a sane way to revert this to the old behavior? (i.e. use the font color configured in the terminal’s configuration and use transparent background.)

I'm currently researching the best method for running a static website from Docker.

The site consists of one single HTML file, a bunch of CSS files, and a few JS files. On server-side nothing needs to be preprocessed. The website uses JS to request some JSON files, though. Handling of the files is doing via client-side JS, the server only need to - serve the files.

The website is intended to be used as selfhosted web application and is quite niche so there won't be much load and not many concurrent users.

I boiled it down to the following options:

1. BusyBox in a selfmade Docker container, manually running httpd or The smallest Docker image ...
2. php:latest (ignoring the fact, that the built-in webserver is meant for development and not for production)
3. Nginx serving the files (but this)

For all of the variants I found information online. From the options I found I actually prefer the BusyBox route because it seems the cleanest with the least amount of overhead (I just need to serve the files, the rest is done on the client).

Do you have any other ideas? How do you host static content?

Currently I’m planning to dockerize some web applications but I didn’t find a reasonably easy way do create the images to be hosted in my repository so I can pull them on my server.

What I currently have is:

1. A local computer with a directory where the application that I want to dockerize is located
2. A “docker server” running Portainer without shell/ssh access
3. A place where I can upload/host the Docker images and where I can pull the images from on the “Docker server”
4. Basic knowledge on how to write the needed Dockerfile

What I now need is a sane way to build the images WITHOUT setting up a fully featured Docker environment on the local computer.

Ideally something where I can build the images and upload them but without that something “littering Docker-related files all over my system”.

Something like a VM that resets on every start maybe? So … build the image, upload to repository, close the terminal window, and forget that anything ever happened.

What is YOUR solution to create and upload Docker images in a clean and sane way?

Since some time now the Steam Flatpak cannot start up and I have no idea why this happens.

Web research leads to basically nothing that is related to what I experience so I assume it has something to do with my system. Other Flatpaks start up normally and I can use them.

When resetting everything related to the Steam Flatpak and reinstalling it from Flathub it loads and installs the Flatpak and then installs all necessary stuff

[various update-related stuff]
setup.sh[4598]: Forced use of runtime version for 32-bit libcurl.so.4
setup.sh[4598]: Found newer runtime version for 32-bit libSDL2-2.0.so.0. Host: 0.2400.0 Runtime: 0.2600.5
setup.sh[4598]: Forced use of runtime version for 32-bit libgtk-x11-2.0.so.0
setup.sh[4598]: Found newer runtime version for 32-bit libvulkan.so.1. Host: 1.3.224 Runtime: 1.3.239
setup.sh[4598]: Forced use of runtime version for 32-bit libdbusmenu-glib.so.4
setup.sh[4598]: Forced use of runtime version for 32-bit libcurl-gnutls.so.4
setup.sh[4598]: Forced use of runtime version for 32-bit libdbusmenu-gtk.so.4
setup.sh[4598]: Forced use of runtime version for 64-bit libcurl.so.4
setup.sh[4598]: Found newer runtime version for 64-bit libSDL2-2.0.so.0. Host: 0.2400.0 Runtime: 0.2600.5
setup.sh[4598]: Found newer runtime version for 64-bit libvulkan.so.1. Host: 1.3.224 Runtime: 1.3.239
setup.sh[4598]: Forced use of runtime version for 64-bit libcurl-gnutls.so.4
steam.sh[2]: Steam client's requirements are satisfied

So everything looks good up to this point. The small Steam update windows poppend up several times indicating the running installation/update. The output then continues:

[2023-08-17 22:47:50] Startup - updater built Jul 28 2023 18:44:09
[2023-08-17 22:47:50] Startup - Steam Client launched with: '/home/dirk/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_32/steam' '-no-cef-sandbox'
08/17 22:47:50 Init: Installing breakpad exception handler for appid(steam)/version(1690583737)/tid(5467)
[2023-08-17 22:47:50] Loading cached metrics from disk (/home/dirk/.var/app/com.valvesoftware.Steam/.local/share/Steam/package/steam_client_metrics.bin)
[2023-08-17 22:47:50] Failed to load cached hosts file (File 'update_hosts_cached.vdf' not found), using defaults
[2023-08-17 22:47:50] Using the following download hosts for Public, Realm steamglobal
[2023-08-17 22:47:50] 1. https://cdn.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in'
[2023-08-17 22:47:50] Verifying installation...
[2023-08-17 22:47:50] Verification complete
XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xf0d328f0
XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xf0d311c0
GetWin32Stats: display was not open yet, good
GetWin32Stats: display was not open yet, good

(The last line gets printed twice, yes.)

The first startup process then hangs there for a few seconds and continues with this.

steamwebhelper.sh[5473]: Running under Flatpak, disabling sandbox
steamwebhelper.sh[5473]: CEF sandbox already disabled
CAppInfoCacheReadFromDiskThread took 0 milliseconds to initialize
src/steamUI/steamuisharedjscontroller.cpp (540) : Failed creating offscreen shared JS context
src/steamUI/steamuisharedjscontroller.cpp (540) : Fatal assert; application exiting
08/17 22:48:39 Init: Installing breakpad exception handler for appid(steam)/version(1690583737)/tid(5467)
assert_20230817224839_27.dmp[5771]: Uploading dump (out-of-process)
/tmp/dumps/assert_20230817224839_27.dmp
dirk ~ $ 

After the command prompt is shown agein, this gets printed:

assert_20230817224839_27.dmp[5771]: Finished uploading minidump (out-of-process): success = yes
assert_20230817224839_27.dmp[5771]: response: CrashID=bp-f62fb7e8-d024-452e-a937-9c6672230817
assert_20230817224839_27.dmp[5771]: file ''/tmp/dumps/assert_20230817224839_27.dmp'', upload yes: ''CrashID=bp-f62fb7e8-d024-452e-a937-9c6672230817''

At the given location there is no dump file.

Do you guys have any Idea why this happens and how I can fix it?

Involved software:

$ flatpak --version
Flatpak 1.15.4

$ flatpak remotes
Name    Optionen
flathub system

$ flatpak info com.valvesoftware.Steam | grep Version | awk '{print $2}'
1.0.0.78

$ uname -rms
Linux 6.4.10-arch1-1 x86_64

$ openbox --version | head -n1
Openbox 3.6.1

$ pacman -Qi xorg-server | grep Version | awk '{print $3}'
21.1.8-2

I can't help but feel overwhelmed by the sheer complexity of self-hosting modern web applications (if you look under the surface!)

Most modern web applications are designed to basically run standalone on a server. Integration into an existing environment a real challenge if not impossible. They often come with their own set of requirements and dependencies that don't easily align with an established infrastructure.

“So you have an already running and fully configured web server? Too bad for you, bind me to port 443 or GTFO. Reverse-proxying by subdomain? Never heard of that. I won’t work. Deal with it. Oh, and your TLS certificates? Screw them, I ship my own!”

Attempting to merge everything together requires meticulous planning, extensive configuration, and often annoying development work and finding workarounds.

Modern web applications, with their elusive promises of flexibility and power, have instead become a source of maddening frustration when not being the only application that is served.

My frustration about this is real. Self-hosting modern web applications is an uphill battle, not only in terms of technology but also when it comes to setting up the hosting environment.

I just want to drop some PHP files into a directory and call it a day. A PHP interpreter and a simple HTTP server – that’s all I want to need for hosting my applications.