beardedwizard

I do not assume anyone is obviously wrong and prefer to ask questions. Most bugs exist in classes, and variants are something you typically consider when a bug results in a production incident.

I'm not sure I read anything that makes me confident this class of bugs could never recur. I could be reasonably confident this _exact_ bug in this _exact_ scenario may not happen again, but that only makes me more concerned about variants that may have equal or more serious implications.

So I'm wondering which claim did it for you? I only really saw pen test as a concrete action.

Based on which claim? That 12 months from now they might accidentally discover a new bug just as serious?

Annual pen tests are great, but what are you doing to actually improve the engineering design process that failed to identify this gap? How can you possibly claim to be confident this won't happen again unless you myopically focus on this single bug, which itself is a symptom of a larger design problem.

These kinds of "never happen again" statements never age well, and make no sense to even put forward.

A more pragmatic response might look like: something similar can and probably will happen again, just like any other bugs. Here are the engineering standards we use ..., here is how they compare to our peers our size ..., here are our goals with it ..., here is how we know when to improve it...

Is this really upper management though? I see a lot of what I assume to be engineers here taking the same approach, and many projects in open source.

I agree there are a bunch of small inflections that make me confident such a solution is possible today, but llms just aren't one of them. Enterprise software is a prisoner of its own old mindset and low resource allocation.

Why do so many see LLM as the inflection that makes this all possible? So much of the proposed automation can be built in totally deterministic ways for cheaper. Not everything benefits from being forced to look like a non deterministic language problem.

You might argue the biggest barrier to enterprise software innovation is the enterprise mindset vs a more engineering first mindset.

Rippling comes to mind as an example of bringing engineering to enterprise.

I'm struggling to understand why I wouldn't just use wireshark and specify the interface as well. Reading docs shows you need to invoke your container with this as a wrapper which to me is quite a bit scarier than attaching to an interface.

What seems a bit silly is writing all this in response to the clickbait title, but clearly not reading the article. The title is intentionally misleading, the article argues the exact opposite, albeit as a marketing ploy for a newsletter on privacy.

Have you seen what animals do to each other on a daily basis?

I agree but how rich is too rich?

One is not like the others - firejail is aimed at more of desktop type applications you interact with, where the others can do so but are more suited for arbitrary workloads.

A parent comment mentions ebpf syscall interception, many end up combining gvisor and nsjail and seccomp.

I would argue this extends to all systems and behaviors that aren't formally verified. Bugs notwithstanding, breaking current encryption is a mathematically backed concept. The issue is broken implementations.

Next they will try to force us to use our tax dollars to fund their legal fights.

What about Linux namespaces makes you think it's not running on bare metal? Maybe you are thinking of versions of docker that introduce a Linux hyper visor like macos?

Whoever it is you think is out there doing it and promoting it. That's why we have phrases like "a culture of harassment", "a culture if lies", etc.

The point is things that appear as universal absolutes are not the same for everyone.

I won't argue that, but there are cultures out there that disagree - so how can it be universal?

Very underrated comment. Right and wrong are largely a function of culture, not universal law.

The issue with SElinux is usability. A company called intrinsic tried a similar "allowlist" approach to javascript based on the assumption that you could never control this sprawl and had to assume every package was malicious. I never saw the technology take off because generating the allowlist was of course error prone.

im not sure what has to change in UX to make these approaches more palatable, but if you have to frequently allow 'good' behaviors, my experience is it never takes off.

The comments claiming no evidence are totally baffling, there are mountains of studies with data. This thread scares me with the amount of misinformation being aggressively pedaled.

Elitism is alive and well in this little nook. Equating platform engineering, SRE and sysadmin to the same thing.

Platforms are often large scale distributed systems, dealing with problems like ensuring 100000s of compute nodes are in a deployed and in consistent state. Millions of lines of code are written, peer reviewed and committed to solve this problem.

This mirrors an attitude I have frequently encountered from "traditional" or "mainstream" software engineers who devalue any work that isn't features, and don't want to have to work on problems like "make my feature appear on all deployments and work well" - it's just something sysadmins do amirite?

I think we have to be open to the possibility it's us not them, but I haven't been convinced yet

Calling it reflection is, for me, further anthropomorphizing. However I am in violent agreement that a common feature of llm debate is centered around anthropomorphism leading to claims of "thinking longer" or "reflecting" when none of those things are happening.

The state of the art seems very focused on promoting that language that might encode reason is as good as actual reason, rather than asking what a reasoning model might look like.

Why is this distinction lost in every thread on this topic, I don't get it.

I struggle with this idea of "run it long enough", or another description I have heard "give the model time to think" it's not a thing - it takes as long as it takes. What im taking away from this is two things:

1. the reason for generalizations like 'long enough' and 'think more' are apparently because the methods are somewhat obscure 2. those methods are being explored by hugging face to make them less obscure

am I getting that right? I have been struggling to see past the metaphors and understand exactly what additional computation is being done - and here I read its something like multiple guesses being fed back in and chosen among which means its just multiple inferences in series that are all related to solving 1 problem.

But the cannabis industry is mostly large companies capturing regulators and litigating genetics, so I'm not sure the distinction is accurate.

This is an intellectually dishonest statement.

Someone reading this might assume its zero sum to you - as if people on Ozempic have not already been exercising and monitoring caloric intake without the associated weight loss/health results they desire - and have only chosen it because they don't want to try something else.

I'm sure you aren't trying to come across as fat shaming, but the reality is of course not zero sum. Diet and exercise doesn't magically work for the entire population.

Diet and exercise definitely worked for me but im not willing to be a sample size of 1 in the face of so many others with legitimate stories.

What you are saying makes sense. Subjectively I feel like they could have done a better job at making this distinction clear given the explosive use for weight loss - but maybe it's just because my interest in this is outside of diabetes.

this part was both clear and unclear to me - does it exclude patients using it for weight loss or not?

I seriously regret not seeing my aunt when she was dying, though I went to the funeral.

A memory ill never forget though is the time I went to a funeral for a childhood friends sister - it was extremely sad as you would expect, but her brother (my childhood friend) saw a big group of us there and he said "I cant believe it, everyone came out" and I could see he was really happy.

When the article said "do it for the family" it really hit me, and in hindsight its obvious - we were there for them, not the deceased, and it meant A LOT to them to see us there.