3np

Quadlets aren't what I'd personally use for local dev. They are good for running a local headless persistent service. So I wouldn't use it for your service-under-test but they can be a good fit for supporting dev tools like a local package registry, proxy or VPN gateway.

The docs you need for quadlets are basically here: https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

The one gotcha I can think of not mentioned there is that if you run it as a non-root user and want it to run without logging in as that user, you need to: `sudo loginctl enable-linger $USER`.

If you don't vibe with quadlets, it's equally fine to do a normal systemd .service file with `ExecStart=podman run ...`, which quadlets are just convenience sugar for. I'd start there and then return to quadlets if/when you find that becomes too messy. Don't add new abstraction layers just because you can if they don't help.

If you have a more complex service consisting of multiple containers you want to schedule as a single unit, it's also totally fine to combine systemd and compose by having `ExecStart=podman compose up ...`.

Do you want it to run silently in the background with control over autorestarts and log to system journal? Quadlets/systemd.

Do you want to have multiple containers scheduled together (or just prefer it)? Compose.

Do you want to manually invoke it and have the output in a terminal by default? CLI run or compose.

"Write your own Dockerfiles" is not useful security advice.

I actually think it is. It makes you more intimate with the application and how it runs, and can mitigate one particular supply-chain security vector.

Agreeing that the reasoning is confused but that particular advice is still good I think.

Two paths:

- Configuration management (ansible, salt, chef, puppet)

- Preconfigured images (NixOS, packer, Guix, atomic stuffs)

For a one-off: pssh

Not if you run it in rootless mode.

Same as for docker, yes?

https://docs.docker.com/engine/security/rootless/

Hey, thanks for taking the time to share your learnings and engage. I'm sure there are HN readers out there who will be better off for it alongside you!

(And good to hear you're leaving the LLMs out of the writing next time <3)

Thanks! Would be cool to have it packaged for alpine since firewalld requires D-Bus. There is awall but that's still on iptables and IMO at bit clunky to set up.

This affects podman too.

It still says:

IT NEVER ESCAPED.

You haven't confirmed this (at least from the contents of the article). You did some reasonable spot checks and confirmed/corrected your understanding of the setup. I'd agree that it looks likely that it did not escape or gain persistence on your host but in no way have you actually verified this. If it were me I'd still wipe the host and set up everything from scratch again[0].

Also your part about the container user not being root is still misinformed and/or misleading. The user inside the container, the container runtime user, and whether container is privileged are three different things that are being talked about as one.

Also, see my comment on firewall: https://news.ycombinator.com/item?id=46306974

[0]: Not necessarily drop-everything-you-do urgently but next time you get some downtime to do it calmly. Recovering like this is a good excercise anyway to make sure you can if you get a more critical situation in the future where you really need to. It will also be less time and work vs actually confirming that the host is uncontaminated.

I also enabled UFW (which I should have done ages ago)

I disrecommend UFW.

firewalld is a much better pick in current year and will not grow unmaintainable the way UFW rules can.

    firewall-cmd --persistent --set-default-zone=block
    firewall-cmd --persistent --zone=block --add-service=ssh
    firewall-cmd --persistent --zone=block --add-service=https
    firewall-cmd --persistent --zone=block --add-port=80/tcp
    firewall-cmd --reload

Specifically for docker it is a very common gotcha that the container runtime can and will bypass firewall rules and open ports anyway. Depending on your configuration, those firewall rules in OP may not actually do anything to prevent docker from opening incoming ports.

Newer versions of firewalld gives an easy way to configure this via StrictForwardPorts=yes in /etc/firewalld/firewalld.conf.

As sibling mentioned, unless you or the runtime explicitly mount the docker socket, this particular scenario shouldn't affect you.

You might still want to tighten things up. Just adding on the "rootless" part - running the container runtime as an unprivileged user on the host instead of root - you also want to run npm/node as unprivileged user inside the container. I still see many defaulting to running as root inside the container since that's the default of most images. OP touches on this.

For rootless podman, this will run as a user with your current uid and map ownership of mounts/volumes:

    podman run -u$(id -u) --userns=keep-id

> Onboarding is bad

Sorry, but you have to run an auth server (matrix-authentication-service) if you want Element X to work.

This is a bit outrageous IMO. Actually breaking and deprecating the classic auth and requiring a new server component to keep the only actively supported client (which still can't properly manage keys or sessions on its own, like classic Element can, even as non-verified sessions are being disabled) is a bit rich.

The answer seems obvious but one that won't be spelled out in SCMP.

Great you found something that works for you and that you managed to dodge the parts of the community that somehow managed to turn this into identity politics.

Still, the gaps are there and don't seem to be filled anytime soon, despite the progress you mention.

Cheers! 10% is nothing to scoff at!

...While I have your ear: IME ReThink DNS often runs into bootstrapping problems since 1) preconfigured DNS servers are referenced by hostname, not IP 2) I can't find a way to separately configure server address and TLS name (making it impossible to configure DoH/DoT servers via IP).

So users often run into "catch 22" where they need existing DNS to resolve their DNS server... When roaming it may work fine for a bit until the local cache drops it, and so on.

Allowing to separately configure TLS hostname for TLS-enabled protocols, and having a preseeded list of IPs for bundled provider endpoints, would mean ReThink DNS could work reliably even in absense of existing DNS.

cf tls_auth_name for stubby. https://dnsprivacy.org/dns_privacy_daemon_-_stubby/configuri...

The currently latest stable release of Debian (13.1) ships a broken version of systemd-networkd which may break networking completely for affected users. Maintainer response is less than encouraging: https://bugs.debian.org/1112535

There was absolutely no need to disturb RT and waste your time, as you have much more important things to take care of, as this is just a minor issue with a particular corner case of a custom config of an optional component. Anybody who is unable to deal with that should just stick to the default Debian components. The next stable update in ~2 months will contain a fix.

"minor issue with a particular corner case of an optional component" my ass.

---

If you are currently on Bookworm using systemd-networkd with VLANs and bridges, you may want to hold off on the Trixie upgrade until fixed systemd 257.9 is available.

Tried Brave?

Wayland is great and ready for (idk) 95% of users/use-cases.

There is a long tail of more-or-less critical stuff that depend on X11 and do not have working Wayland substitutes. While the tail has been shrinking for every year, it will be decades if ever until all can be realistically migrated. Consider the Lindy Effect and that some of these systems have been running for >10y already. Consider shared but secured environments at universities and research institutes. Consider obscure hardware incompatibilities and hardware-specifix performance issues which might never be fixed.

On the software side, acessibility aside, there are a lot of VNC and other remote-X setups out there with no viable replacement in sight (yet).

Alsa, pulseaudio, pipewire and jack can all coexist and so can display servers.

I understand GNOME and RedHat will do things their way. I understand distro and GUI framework maintainers wanting to reduce their load. I understand people who like Wayland, want it to succeed, and want to evangelize. I do not appreciate when it turns into tribalism, forcing of monoculture and insisting "X11 is deprecated".

---

OP is from 2023 but as they note in their update, the situation is fundamentally not that different 2y later. Are maintainers and decision-makers really sincerely imagining that a supposed deprecation and removal of X11 can be forced onto the wider community over a couple of years from now?

How is this spam not autoflagged by now?

https://news.ycombinator.com/from?site=reddit.com

The bullet engravings are well known

You can read anything you want into those if you want to. To me they reek weeb culture (as opposed to furry like everyone else jumps to - there are overlaps but they are distinct), 4chan trolling and lemmy more than anything. We can not know the intentions behind those engravings and they say nothing about which, if any, affiliation the shooter had. Could be a Luigi wannabe, could be a false flag to induce civil war.

"Unafilliated" seems like the most plausible assumption right now. Everyone pushing theories about shooter affiliation right now either has their own political agenda behind it and are doing so incincerly or are useful idiots serving the aforementioned.

I don't think you can get much further right than he was though.

Groypers.

Perhaps the people you see as cynical have more research and/or experience behind their views on OpenAI than you. Many of us have been more naive in the past, including specifically towards Altman, Microsoft, and OpenAI.

How recently was this experience?

TFA frames this all as recent and ongoing learnings and changes at F-Droid. Given the notability of your project (kudos and thanks), perhaps they'd appreciate your input.

Seems a bit vulnerable to subversion of the host (and/or its government) once they decide to pay attention (or even through negligence; imagine a minister being banned because of some ML false-positive).

If the format is to be sustainable, they will need to find or found a different platform.

My personal systemctl clunk pet-peeve is "get list of all currently (active/running) (units/services)". Something like a "systemctl ps".

Consider this a feature request, I guess :)

Considering how obviously in the wrong he is, it might not be too off calling that a win for him.

Very scant on details.

Who built it? Who operates it? Is it using existing proprietary LLM platform(s) or using their own tech?

I'm usually on the other side of these things but here I think most of the actual (some might be artificial...) outrage and concern come from a misunderstanding of the product and services Huntress are selling and how their EDR product is packaged and sold.

As presented I see no ethical concerns with the incident and their response. Someone hacks you and then installs your rootkit, I say you can leverage that to hack back and look all you want while it's running (as long as you can be confident it's really the attacker obv). I appreciate that Huntress shared their insights with the community and hope that they and others won't be discouraged from the unfortunate flaming.

Food for thought: Perhaps it wasnt't the money as much as Stripe itself being the barrier? Maybe you would have gotten better turnout with other payment options (especially for a platform like Trello, crypto like BTC/XMR might be more welcome than you'd expect).

My biggest lesson? Charge early.

Can't argue with that. And even if you go free early, advertise it as "free trial during our early days" or similar. If you already plan on charging in the future, get people used to the idea of having to pay for it from day one even if you give it away for some potentially extended time. Proper free-tiers with expectations and terms can come later down the line when the pricing strategy is clearer.

People emotionally respond very differently to their free trial expiring ("it was nice while it lasted") vs having their previously free service being replaced with a paid one ("f this enshittified rugpull"). The difference is proactive communication and setting of expectations.

As a technology, it is just database joins.

As a business, it is far more. Their FDEs are intrinsic to unlocking capabilities for customers.

Real title: "String Capitalism: Playing entrepreneur on Hard Mode"

The author name is in the domain name already; no need to editorialize the title to promote them further.