A few weeks ago I posted about the trouble I had with 100% whole wheat pizza crust. I've been tweaking the recipe since then, so I think it's time for an update. The summary is that the most recent recipe works pretty well.. as long as I don't let the dough get over-proofed. Decent structure, crumb, and taste. The big innovation isn't too surprising: Adding vital wheat gluten to strengthen the dough.

The recipe for two NY-style pizzas: 562 grams home-milled white whole wheat flour, 370+ grams water, 120 grams ripe sourdough starter, 28 grams vital wheat gluten, 19 grams olive oil, 11 grams salt, and 6 grams sugar. Optional: Half a teaspoon each of onion and garlic powder. Knead, divide, 72 hour proof in the fridge, bring to room temp, shape, top, and bake (preheated to 550°F then switched to broil, baked 5 minutes on steel).

Pictured here: Kale, potato, red onion, and fennel seed.

The recent post about what people are using for webmail got me thinking about a perhaps irrational policy I have with my own self-hosted software: I don't install anything written in PHP, because I have this vague notion that PHP software is often insecure. I think I probably got this idea because years ago I saw all the vulnerabilities in PHP webmail clients and PHP software like Wordpress and decided that it was the language's fault—or at least a contributing factor.

Maybe this isn't fair. Maybe PHP is just more accessible to new devs and so they're more likely to gravitate to it and make security mistakes. Maybe my perception isn't even accurate, and webmail / blog software written in other languages is just as bad—but PHP gets all the the negative attention because it's so prevalent for web apps. Maybe my policy was a good idea, years ago, but now it's just out of date.

To be clear, I'm not trying to stoke the flames of a language holy war here or anything. I'm honestly asking: Is it maybe time to revisit my anti-PHP policy? I'm looking longingly at some federated software like Pixelfed and wondering if maybe I'm just being a little too close-minded.

So I'm interested in your own experiences and polices here. Where do you draw the security line for what you will or won't host, and what made you make that choice?

Anyone have a good approach/recipe for 100% whole wheat pizza? I'm pretty experienced making pizza at home, but my usual pie is only 40% white whole wheat and 60% white bread flour. Now I'm trying to go to 100% whole wheat for health reasons, which I realize is a tall order for pizza.

The last time I tried this, I did a short knead and then a bunch of stretch and folds over a couple hours to develop more structure. Then I refrigerated for my usual 72 hours (because sourdough). But I think due to all the time at room temp with the stretches and folds, the dough got too active and was overproofed by the time I got to shaping the pie. And then it tore and was a big mess.

So any tips? Anyone else brave enough to try this? I'm not above adding gluten. Should I just lose the stretch and fold and knead longer so as not to get the starter too active? Alternatively, if this is just plain dumb, what's the highest percentage you can go with whole wheat on pizza before things get silly?

Current recipe for two pies:

• 562 grams white whole wheat flour
• 370 grams water
• 120 grams ripe sourdough starter
• 19 grams olive oil
• 11 grams fine salt
• 6 grams sugar

(It's vaguely NY style, in case that matters.)

EDIT: I posted an update on this.

So Podman is an open source container engine like Docker—with "full"^1^ Docker compatibility. IMO Podman's main benefit over Docker is security. But how is it more secure? Keep reading...

Docker traditionally runs a daemon as the root user, and you need to mount that daemon's socket into various containers for them to work as intended (See: Traefik, Portainer, etc.) But if someone compromises such a container and therefore gains access to the Docker socket, it's game over for your host. That Docker socket is the keys to the root kingdom, so to speak.

Podman doesn't have a daemon by default, although you can run a very minimal one for Docker compatibility. And perhaps more importantly, Podman can run entirely as a non-root user.^2^ Non-root means if someone compromises a container and somehow manages to break out of it, they don't get the keys to the kingdom. They only get access to your non-privileged Unix user. So like the keys to a little room that only contains the thing they already compromised.^2.5^ Pretty neat.

Okay, now for the annoying parts of Podman. In order to achieve this rootless, daemonless nirvana, you have to give up the convenience of Unix users in your containers being the same as the users on the host. (Or at least the same UIDs.) That's because Podman typically^3^ runs as a non-root user, and most containers expect to either run as root or some other specific user.

The "solution"^4^ is user re-mapping. Meaning that you can configure your non-root user that Podman is running as to map into the container as the root user! Or as UID 1234. Or really any mapping you can imagine. If that makes your head spin, wait until you actually try to configure it. It's actually not so bad on containers that expect to run as root. You just map your non-root user to the container UID 0 (root)... and Bob's your uncle. But it can get more complicated and annoying when you have to do more involved UID and GID mappings—and then play the resultant permissions whack-a-mole on the host because your volumes are no longer accessed from a container running as host-root....

Still, it's a pretty cool feeling the first time you run a "root" container in your completely unprivileged Unix user and everything just works. (After spending hours of swearing and Duck-Ducking to get it to that point.) At least, it was pretty cool for me. If it's not when you do it, then Podman may not be for you.

The other big annoying thing about Podman is that because there's no Big Bad Daemon managing everything, there are certain things you give up. Like containers actually starting on boot. You'd think that'd be a fundamental feature of a container engine in 2023, but you'd be wrong. Podman doesn't do that. Podman adheres to the "Unix philosophy." Meaning, briefly, if Podman doesn't feel like doing something, then it doesn't. And therefore expects you to use systemd for starting your containers on boot. Which is all good and well in theory, until you realize that means Podman wants you to manage your containers entirely with systemd. So... running each container with a systemd service, using those services to stop/start/manage your containers, etc.

Which, if you ask me, is totally bananasland. I don't know about you, but I don't want to individually manage my containers with systemd. I want to use my good old trusty Docker Compose. The good news is you can use good old trusty Docker Compose with Podman! Just run a compatibility daemon (tiny and minimal and rootless… don't you worry) to present a Docker-like socket to Compose and boom everything works. Except your containers still don't actually start on boot. You still need systemd for that. But if you make systemd run Docker Compose, problem solved!

This isn't the "Podman Way" though, and any real Podman user will be happy to tell you that. The Podman Way is either the aforementioned systemd-running-the-show approach or something called Quadlet or even a Kubernetes compatibility feature. Briefly, about those: Quadlet is "just" a tighter integration between systemd and Podman so that you can declaratively define Podman containers and volumes directly in a sort of systemd service file. (Well, multiple.) It's like Podman and Docker Compose and systemd and Windows 3.1 INI files all had a bastard love child—and it's about as pretty as it sounds. IMO, you'd do well to stick with Docker Compose.

The Kubernetes compatibility feature lets you write Kubernetes-style configuration files and run them with Podman to start/manage your containers. It doesn't actually use a Kubernetes cluster; it lets you pretend you're running a big boy cluster because your command has the word "kube" in it, but in actuality you're just running your lowly Podman containers instead. It also has the feel of being a dev toy intended for local development rather than actual production use.^5^ For instance, there's no way to apply a change in-place without totally stopping and starting a container with two separate commands. What is this, 2003?

Lastly, there's Podman Compose. It's a third-party project (not produced by the Podman devs) that's intended to support Docker Compose configuration files while working more "natively" with Podman. My brief experience using it (with all due respect to the devs) is that it's total amateur hour and/or just not ready for prime time. Again, stick with Docker Compose, which works great with Podman.

Anyway, that's all I've got! Use Podman if you want. Don't use it if you don't want. I'm not the boss of you. But you said you wanted content on Lemmy, and now you've got content on Lemmy. This is all your fault!

^1^ Where "full" is defined as: Not actually full.

^2^ Newer versions of Docker also have some rootless capabilities. But they've still got that stinky ol' daemon.

^2.5^ It's maybe not quite this simple in practice, because you'll probably want to run multiple containers under the same Unix account unless you're really OCD about security and/or have a hatred of the convenience of container networking.

^3^ You can run Podman as root and have many of the same properties as root Docker, but then what's the point? One less daemon, I guess?

^4^ Where "solution" is defined as: Something that solves the problem while creating five new ones.

^5^ Spoiler: Red Hat's whole positioning with Podman is like they see it is as a way for buttoned-up corporate devs to run containers locally for development while their "production" is running K8s or whatever. Personally, I don't care how they position it as long as Podman works well to run my self-hosting shit....

For context, I'm talking about texturing smaller drywall repairs like, say, a patched 3-inch hole (don't get me started on railings not installed to code...) or even nail pop repairs as per the other recent post. Assume I've mudded and sanded and it's nice and smooth and now I want it.. less smooth. To match, say, an orange peel texture.

I fully realize that no repair texturing will 100% match an existing texture, but I'm not going for a 100% match. Hell, I'd settle for 50%. To date, my efforts have involved a paint roller with 1/2 inch nap (something like this one) and slightly dilluted joint compound. The results have been ... less than stellar. Just a bunch of random wrinkly ridges on the wall rather than orange-peely bumps. From thirty feet, you probably wouldn't see it. Unfortunately it's in a hallway that's less than thirty feet wide...

Also, I'd love to believe that spraying texture isn't necessary for a repair this small. I have tried the spray cans in the past (so, not a real sprayer like the pros use). Not only were the results less than less than stellar, it was a huge mess.

So, what the heck do homeowners do for this sort of thing? Just take off their glasses when they walk by?

Hey all! I'm looking for a mythical local-only (Wifi, Z-Wave, or Zigbee) smart light switch that has a good feel and user experience when manually switching on/off. What I mean by that: I think my ideal UX is some sort of hard rocker switch like the very much not smart Leviton Decora switches. You hit the top of the rocker for on or hit the bottom of it for off, and it has a good, solid feel with each state change.

The problem comes when making one of these switches "smart," e.g. stuffing a Shelly or something behind it. The up/down directions won't correspond to on/off anymore, because the smart switch can turn the light on/off without affecting the rocker direction. Maybe this is okay and I just need to deal with it? Does anyone with a similar setup find this annoying? I guess it's no different than a traditional three-way switch.

Another option is to take out the dumb switches and replaces them entirely with smart ones. Almost all smart switches are single on/off toggle buttons (some have two buttons), sidestepping the up/down state problem described above. But I'm not sure I'd like the feel of a squishing a button into the wall instead of a tilting a rocker. I do have a few of an older model of this Eva Logik switch, which has two buttons and kinda sorta mimics the look of the Decoras—but it doesn't actually rock like traditional switches. The up/down buttons are more like clicky mouse buttons, and not the best tactile experience IMO. Plus, newer models apparently are no longer Tuya-convertible to Tasmota...

So am I just being too picky here? Does anyone else experience similar issues?

EDIT: Here's a TL;DR of the suggestions below, for anyone also looking to solve a similar probem:

• Use a Jasco/GE Enbrighten series smart switch (Z-Wave, Zigbee, or Wifi)
• Use a TPLink Kasa switch (Wifi via HA tplink integration)
• Try an Innovelli Blue switch (Zigbee; there's also a Z-Wave variant)
• Open your wallet for a Lutron Caséta Diva/Claro (proprietary, but local only)
• Use a SONOFF SwitchMan M5 smart switch (Wifi?)
• Just deal with your OCD and put a Shelly behind a dumb switch