Hacker Newsnew | past | comments | ask | show | jobs | submit | evertheylen's commentslogin

This is actually how GTFS (a standard format for public transit data) works: https://gtfs.org/documentation/schedule/reference/#stop_time... . Especially sleeper trains can get weird with 30+ hours. But I don't think it's wise to show that to the user


And it is the right thing to do as otherwise the question to which day a train belongs will be confusing. Just take it %24hours before intersecting trains.

It is also how I personally record time spans. It makes it much easier as you do not need to deal with the case where the start is larger than the end time and you can only have a single date field.


If you're on Linux, I've tried to build an easy yet secure way to isolate your system from your coding projects with containers. See https://github.com/evertheylen/probox


Interesting to see Marko and Solid topping the performance metrics. Ryan Carniato* was a core team member of Marko and started Solid. I wouldn't be surprised if SolidStart can eventually lower its bundle size further.

*) https://github.com/ryansolid


The article is a bit disappointing in that it focuses too much on bundle size. Bundle size is important for sure, especially in rural areas with poor mobile signal, but time-to-interactive is imho more important, and that's where resumable frameworks like qwik and marko6 shine

Solid is great for raw rendering speed, but it hydrates just like react (unless you use an islands framework on top like astro which has its own limitations), while qwik and marko are resumable out of the box


I wish he would have combined Astro with solid instead of HTMX for a more direct comparison


Great piece of software. For me its killer feature is automatically passing through exposed ports in a container, so you don't have to recreate the container with different -p options. (See https://evertheylen.eu/p/probox-intro/#network)


I always like to see new projects using containers. Two questions:

- how is your devbox.json file different from a Dockerfile/Containerfile?

- does your project attempt to provide any isolation security-wise?


> does your project attempt to provide any isolation security-wise?

Considering that they provide Docker-in-Docker by default, this would have to be a "no" right now. Having the ability to launch Docker containers is equivalent to having root access on the Docker host by default.


To add to the article: systemd integration works in the other way too! Running systemd in a Docker container is a pain. It's much easier in Podman: https://developers.redhat.com/blog/2019/04/24/how-to-run-sys...

(Most people use containers in a limited way, where they should do just one thing and shouldn't require systemd. OTOH I run them as isolated developer containers, and it's just so much easier to run systemd in the container as the OS expects.)


I actually run code-server (derivative of VSCode) inside the container! But I agree that there can be many gotchas, which is why I try to collect as much feedback as possible.


If you are on Linux, I'm writing a little tool to securely isolate projects from eachother with podman: https://github.com/evertheylen/probox. The UX is an important aspect which I've spent quite some time on.

I use it all the time, but I'm still looking for people to review its security.


Containers should not be used as a security mechanism.


I agree with you that VMs would provide better isolation. But I do think containers (or other kernel techniques like SELinux) can still provide quite decent isolation with a very limited performance/ease-of-use cost. Much better than nothing I'd say?


I would kinda disagree with this. The whole 'better than nothing' is what gave a huge chunk of people a false sense of security wrt containers to begin with. The reality is that there is no singular create_container(2). Much of the 'security' is left up to the runtime of choice and the various flags they choose or don't choose to enable. Others in this thread have already mentioned both bubblewrap and podman. The fact that the underlying functionality is exposed very differently through different 'runtimes' with numerous optional flags and such is what leads to all sorts of issues because there simply was no thought to designing these things with security in mind. (We just saw CVE-2025-9074 last week). This is very different than something like the v8 sandbox or gvisor which was designed with certain properties.


It’s a gradient. An airgapped physical device is better than a VM. A VM is better than podman. Podman is better than nothing.

A locked door is better than an unlocked one, even if it gives its owner a false sense of security. There is still non-zero utility there.


This is also my impression. Containers aren't full-proof. There are ways to escape from them I guess? But surely it's more secure practically than not using them? Your project looks interesting I will take a look.


I do too, but I found it non-trivial to actually secure the podman container. I described my approach here [1]. I'm very interested to hear your approach. Any specific podman flags or do you use another tool like toolbx/distrobox?

[1]: https://evertheylen.eu/p/probox-intro/


Very interesting. I learned some new things. I didn't know about `--userns` or the flexible "bind everything" network approach!

Here's my script:

https://codeberg.org/chrisdavies/dotfiles/src/branch/main/sr...

What I do is look for a `.podman` folder, and if it exists, I use the `env` file there to explicitly bind certain ports. That does mean I have to rebuild the container if I need to add a port, so I usually bind 2 ports, and that's generally good enough for my needs.

I don't do any ssh in the container at all. I do that from the host.

The nice thing about the `.podman` folder thing is that I can be anywhere in a subfolder, type `gg pod`, and it drops me into my container (at whatever path I last accessed within the container).

No idea how secure my setup is, but I figure it's probably better than just running things unfettered on my dev box.


Yeah props to the `pasta` tool, it solves a specific problem really well.

Nice script! I considered a similar approach that's based on "magic" files in the filesystem before, but it was difficult to get the security right. In your case I believe a malicious script can just overwrite .podman/env and it will be sourced by the host the next time you start the container.

I'm happy to discuss this more, feel free to reach out at evertheylen@gmail.com. I'm particularly interested in trying automated ways to try to break out of a container (like https://github.com/brompwnie/botb), this would benefit any containerization project.


Another approach I wrote to protect your system from untrusted dependencies (for Linux devs): https://evertheylen.eu/p/probox-intro/

Happy to hear other people's thoughts!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: