pbar

Unfortunately with SSH specifically, the dissectors aren't very mature - you only get valid parsing up to the KeX completion messages (NEWKEYS), and after that, even if the encryption is set to `none` via custom patches, the rest of the message flow is not parsed.

Seems because dumping the session keys is not at all a common thing. It's just a matter of effort though - if someone put in the time to improve the SSH story for dissectors, most of the groundwork is there.

Was it intentional to reply with another no true Scotsman in turn here?

Ah, quick and painless then

It’s all fun and games until your KDC goes down!

Interesting, what were some of those unique optimizations?

It’s a spreadsheet world and we’re just living in it ;)

To their point, S3 buckets must be uniquely named globally, across all of AWS

It’s always surprising to folks, but true, that Houston has a wealth of arts/culture/dining, and even a modicum of public transit (the metro rail, heh). Entertainment could be better, but the rest blow Austin out of the water!

Single responsibility - that same container is gonna get shipped to prod/etc. I would hope the database isn’t in the container there!

I get your point, and I disagree on opinion. I and many others have had success using containerized devenvs on projects both large and small, and have likewise felt some pain with respect to repeatability when not - especially with the Python stack. Containers are synonymous with repeatability. Your future self is just another collaborator, and they’ll appreciate it down the line when they’ve got a new laptop and new env, for example ;)

This kind of thinking is why engineering departments have tech debt.

Another counterpoint to readability: the benefit is diluted if the reader isn’t familiar with the dependencies. I know this goes both ways, though in some circles (say, devops) there’s more familiarity with Unix tools than Python. So the cognitive overhead of getting familiar with something you’re not IMO outweighs readability in either case.

In a similar vein, you also pretty well ;)

To each his own. There is an equally wide group of developers who choose Go for personal projects as it’s in line with their taste. The joy of programming is in the eye of the beholder.

The frustrating part is, I definitely faint due to blood being drawn for example, but something about the sight of the procedure makes it hard to look away

The reality is that containers via `runc` really _are_ just bundles of processes with some sugar to control Linux namespaces. Using another runtime (kata, etc) would get closer to the tighter abstraction you mention, but it would truly be a VM, just a small one.

That’s not edgy enough for HN ;)

And interrupt their mostly nontechnical employees’ productivity to learn a new OS, for a negligible cost savings? Good luck getting that past a board of directors.

We have to remember the Fermi Paradox is a Fermi estimation and only that

This is the same case regardless of being in a container or not, $app v0.1 and $app v0.2 will have different filters

From a developer point of view, one should not have a mental model in play for Kubernetes, the standard 12 factor pattern should be it. If not, the infrastructure and the app are strongly coupled

Make sure to take great care of the monorepo, and break it up _before_ it becomes impossible but necessary

Agree totally. One win Kubernetes provides my current team has been the fact that it is the interface on top of a cloud with agnostic primitives, allowing for multi cloud scaling. There are a lot of primitives, and a lot of things to monitor to ensure a running cluster, but the complexity of the system is IMO overblown in the popular mind. Isn't the core tenant of SRE to have the stability of the system automated?

A process making a system call to the kernel functions the same way regardless of whether it is in a container or not. How exactly does the security model differ at all?

You might find the Kubernetes offer interesting. Pod Security Policies[1] expose seccomp and selinux configuration in the form of annotations.

[1] https://kubernetes.io/docs/concepts/policy/pod-security-poli...

I wonder about similar future change in imagination. Almost certainly possible since there's precedent for it happening, but the hard part is imagining what sort of thought it would enable.