tetha

If a driver does get involved in a crash after a single mile, it's very likely that they are not safer than the average driver. It could of course be extraordinarily bad luck, but that's unlikely.

This is not that simple. Emergency service vehicles are at a very high risk of collision when they pull out of the station and crossings close to the station, or when leaving a situation under time pressure. Busses are at an increased risk of collision when pulling away from a bus stop. Construction vehicles are at a high risk of collision when they pull away from a construction site at a busy road.

Hence why you need more data, after which average accidents per mile are a much stronger indicator.

I think the "But this is not intelligence because it is known math" is not a correct argument. It is unknown how the overall higher intelligence of humans works.

What I do notice however is that LLMs are becoming capable of doing an increasing part of the intellectual work I can do, and usually a lot faster.

Just today I presented an agent framework that can take an informal incident statement and propose infrastructure changes to fix it, all evidence backed. This did nothing I could not to, but it did all 5 test cases in 6 - 12 minutes each. I would have found all of the monitoring indications it did, but it would have taken me a day per test case. The LLM also included sass to silly tickets. ("This is not even worth spending monitoring resources on. It's obviously a configuration problem.")

That's how this is reading to me as well. It's just fast at slogging through a certain level of "simple" transformations.

But how do you conclude then that they are less safe? They are neither proven to be more, less, or equally safe. So any statement of "more injuries" is as unfounded as "less injuries" or "just as many injuries".

That seems like the same statement, unless we apply stochastic class level subtlety.

This is why the idea of being "Vogelfrei" or "lawless" was honestly a terrifying concept in the middle ages. They are neither bound by law, nor protected by law.

A lawless man can be struck down with force without persecution by law, because they are lawless.

Agreed. The much better question is: Are we locking ourselves out of a feature, or do we just leave a gap for a rare case?

At work we agreed that some use cases are very niche. These have guards in place to log an alerted-upon marker + return HTTP/500. They have not tripped for years by customers. So, it's fine to not support some rare cases and to deliberately leave known gaps in some contexts. As long as you don't close these paths forward if you need them.

On the other hand, we have contexts like our PostgreSQL instances. Those have a very well defined scope and rooting out all known problems has been the right choice. Most issues we have ignored in that scope have bitten us in the butt sooner rather than later. Very hard in some cases, I may add.

Realizing this about a domain is very important.

It reminded me of an old meme. Please don't follow the following instructions and stop reading if you cannot.

It was just a popup: "Hello. This is virus from Albania. Due to poor technology in country, I cannot harm your computer directly. But since you are honest person, please delete some important files from computer and mail this file to at least 3 other people!"

Claude.md is an equally effective defensive tool.

But sorry if you lost some files from reading that.

They thought climate change was the next war-level crisis, and worked towards that.

Did we though? At least in Germany a bunch of anti-climate-change projects and changes have been and are being canceled and we're going back to coal and diesel. It seems we're optimizing to have no results and negative progress at the moment.

And interestingly, a few good people at work are learning faster with the LLMs at hand.

To a degree, it looks like LLMs help them overcome the blank page anxiety and help them with the grunt work of, well, actually writing code, which actually contains a lot of technical nuances to keep track of. But once that's down, I'm having very good discussions with them on what makes good, maintainable and sustainable code bases.

It's almost like the old writing advice my Mark Twain: “Writing is easy. All you have to do is cross out the wrong words.” It's easier to dislike a part of something existing and fix that, than trying to create the perfect thing at once.

Own hardware has a weird scaling curve.

It does not make sense for a lot of time and scaling. You need 3+ people maintaining it, you have upfront costs in the hundreds of thousands of euros on the very lower end. If you don't utilize that money spent, sucks to be you. You have planning times in the area of months, not hours, unless you keep capacity you don't use around (rackspace, cabling, power/cooling capacity).

On the other hand, if you have that hardware management running, it's very amazing. Before the AI nuke, We were looking at moving various systems fully bare metal, because it would simplify management on both sides a lot, and a common statement I heard is "We don't deal with systems that small. If we do bare metal container hosting, we don't measure in dozens of gigabytes of memory. Your business case validates that investment. Here is btw three test systems about double your requirement, just old".

Before the AI nonsense (HBM Memory Demand -> RAM & SSD prices), this would result in very competitive hosting costs after some scale, when amortized across 5 years and then tossed into the testing environment until it stops functioning. And these testing environments allow for a lot of experimentation and failover testing.

Though now it's all very different and not clear.

That didn't prevent Anna Rudolf being accused that she hid a supercomputer in her lip balm box made of tin sheet metal in 2007 and cheated with it in the bathroom.

Some parts of the chess community are very ridiculous.

You are correct, there is no strong indication of active suicide.

However, it certainly put him into a state of mind of neglect, not caring anymore and not taking care of himself and most importantly, no way out. The words "I cannot play chess anymore without doubt of being accused of cheating, no matter what I do" are haunting to me. At that point he had multiple cameras targeting all screens he had and everything he could see, and it wasn't enough to Kramnik.

At such a point, it feels like arguing semantics.

But it did not take 2 threads within the same application to interact in a bad way on data the system controlled to cause this problem.

This reads more like an overly broad transition in a deterministic state machine. The fix was to split up a bad transition to shutdown.

Both certainly do. My own hypothesis on why this isn't a more widespread problem is the speed, or lack thereof, of these ecosystems. By the time a package hits debian stable, it's usually been under scrutiny for a year or more.

The terms I've learned to use is rather: Happiness, and Stressors.

If you need your car to earn money, and you don't have the money or other resources to repair it if it breaks - that's a huge uncertainty and a huge source of stress and worry. Liquid funds can remove that source of stress. More drastic examples would include rent or food.

That's why liquid funds can remove impediments and distractions from your life, but once all of those are gone, then what?

I watched a talk by her about this, and this post is missing half of the equation, which is really important:

Having a wrong abstraction means you end up with a class/function/module with a huge amount of configurations through boolean/enum parameters. It's not even clear that all combinations of configurations is even valid. This situation may be simplified by duplicating, and then eliminating code, thus creating more streamlined code for each use case. This may require fixing similar or cross-cutting bugs in multiple places (eg: JSON serialization is stupid, need to hack a workaround), but keeps the business logic changes simple. Maybe a bit more numerous, but the code is able to raise all the scenarios to consider.

Having no abstraction means you may have to change business logic consistently in multiple places, or you have to fix exactly the same misconception (aka a bug) in multiple cases. e.g. tax rate management in a multi-national context. This is also terrible, because you may fix an important problem in one place and forget other places with the same issue. Now you missed 12 potential bugs by fixing one. This can however allow you to discover a true abstraction. Maybe these 12 places should call just one place?

But for code evolving across a team understanding this tension, a bit of duplication while waiting for confirmation that these pieces of code break together and change together is better than just shoving the same 3 if-statements into a function to avoid "line duplication". Concept duplication is more important.

The world needs more confusing positivity.

"You are beautiful and wonderful - keep going! (unlike this systems security)"

I've started something similar in my life. Chris Boltendhal (Founder of Grave Digger) has been criticizing how streaming services had turned music into a wallpaper, and others have too. Something that's just there in the background, but not fully appreciated.

So now I've been making room in my week for new albums of bands I enjoy and listen to. Just an hour or two of nothing, but listening to this album, while sitting in a hammock or somewhere else entirely relaxed.

I can only recommend this. For example, Heilung(1) or Wardruna(2) are already great on theri own, but one of their new songs, but I was listening to one of their songs in a park over here, sitting at a tree and suddenly a little noise was nearby. Turns out, there was a squirrel looking at me and then scampering by. Later on a little bird also was exasperated I looked at him as he chased a bug. Very fitting to these bands.

Sometimes balancing the speed of our lives indeed seems like a very good idea.

1: https://www.youtube.com/watch?v=64CACoHNBEI

2: https://www.youtube.com/watch?v=VEizKmZlUAw

As the old joke went, the easiest way to not have detected covid cases in the country is to stop testing. Very simple, very effective.

Starcraft is too tame. You need to use Dwarf Fortress there and we need to make those strategy guides worded more realistic. Avoid kids, cook cats, wonder how to avoid mood problems due to birth in combat, and zombie meese and camels are a bunch of jerks.

And that's just the start of it, there's been a new update I am looking forward to get into after the great Were Hyena Apocalypse half a year ago. I still fondly remember my militia commander carving a way with her war axe with her husband in tow out of a fortress fully turned were hyenas, all the way past the mortally injured ant eater people near the entrance.

They made it. An entirely epic tale.

Regarding 1 and 2, my pity is mild if this requirement forced companies to follow principles of secure software development, configuration and deployment. Injecting stuff from deployment config is not hard.

3 is valid and can be tricky, as it would depend on when in the software lifecycle the release would be mandatory. If it's in a wind-down or bankruptcy situation, it would be tricky. Though that discussion is similar to the responsible disclosure discussion, isn't it? Exploiters usually already know them.

So release the server code as OSS, data necessary to function & support community servers. Even in a crappy hard-to-support way, the community will usually figure out a way.

IMO, the move from community servers over to matchmaking & vendor only servers being the only viable option was a huge disservice to the long-levity of games. If I find the code around here, I could still get a Tremulous server running today for a few bucks, even if I haven't played that game for 20+ years.

Also the APT and RPM world lets packages sit for a long time - those are called "testing" and "unstable" in the Debian world. It's slow, but it seems hard to move intentional exploits with short-term payoffs through as far as we can see.

That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.

Also, from the customer side, people ask at the higher end, don't they? Beyond a certain level, it's more of a search and a quest than just browsing. So you mainly have to show that you have connections for certain things. Why does this sound like drugs now?

I know this from a few friends who are deep into tabletop and boardgames, and they would regularly work with the one or two small stores around to get some special, expensive item (to help keep the shop afloat).

Women in a committed relationship can enter a medical situation that renders then unable to work for 6-9 months, + 2 - 3 years of leave afterwards. Men don't, that's just a month or two twice.

It is illegal, and in my book also immoral to deny such a candidate, but the other side of the coin is there.

A friend of mine had an interesting point there. It was more on a personal note that either of us had a hard time spending money on nice things for ourselves. Like, do you need better headphones, do you need this, do you really need that? Better not buy anything nice or fun.

A fairly unintuitive resolution to this is to setup a "fun and nonsense" budget and force yourself to spend it every half year, or to make a conscious plan on how to spend it over the year. If you plan the budget right, it won't hurt you, but it will force you to make your life better.

Maintenance, especially of owned property, seems similar to me. You should be saving up for the real "oh shit" situations, and you should accumulate a budget to just do things continuously. 6 months of routine maintenance budget saved up, what do we spend it on actively, before it becomes a mess?

ETHOS is generally reserved for a certain type of error involving slab memory and complex logic though.

Let's hope that reference is not too obscure...

Three deterministic Linux LPEs in a week, an LPE in BSD in execve (of all things...), nginx vulnerabilities, one or two new gnarly supply chain attacks. Linus noting that the linux-security mailing list is getting flooded with duplicated, AI-driven reports of varying quality. There are pretty crazy keycloak vulnerabilities getting discovered.

We're most likely entering a year or two or rapid vulnerability discovery, patching, as well as reducing and minimalizing system footprints just to survive the onslaught of strange vulnerabilities from e.g. ancient and widely unused kernel modules.

"Molten" to me implies it is still liquid. Molten salt reactors, molten magma from a volcano, molten sand, molten steel, dipping something into molten cheese. All fluid.

If I was to nitpick, "melted" is kind of inaccurate and not entirely natural in this context. Technically, molten sand is also melted sand, because that's how you get it to that state? Usually, you'd hear about solidified magma, crystalized sand, cast iron, air-cast steel, unevenly settled corium... to make a better point on how it turned back into a solid and what to expect from it - something like "The molten sand crystalized into an unusual structure" would be clearer.

I'd usually rather hear "melted" if it is important to note that this had a phase change and back. Plastic on an electrical device may look melted, indicating heat. A hardened steel part may look melted, which may damage the hardening. Rubber on a hydraulic line may look melted, also indicating heat. A plastic container looking melted in the context of chemicals may indicate some compromise.

Now the words sound weird in my head. Thank you.

But in a perfect world, the question would be: Is it reasonable to expect an outage by sending a few single TCP packet to a system? Or, were you flooding the system unreasonably?

It is a huge security risk to treat systems as ancient eggshells you must not touch ever. A certain amount of touching has to be reasonable, because that is what foreign actors will do if they need to cause trouble. Apparently you could cause this company major operational harm with a pi zero. Why is that protected by professional ruin and jail time?

Yeah.

And I do think that security research should have some regulation about it, but it should be more about responsible handling of the privileged access you gained, or a responsibility to disclose found vulnerabilities in private and/or to a government entity. You know, "If you have gained access to a system, and you saw a button <Turn off cooling pump 2> and you pressed it, you are on the hook for the damages". That is common practice with paid pentesters already.

But we're at a point where a court had do decide if discovering an endpoint on an API without authorization is a "circumvention of a security boundary" or not. Luckily, we now have a ruling that accessing API endpoints without authorization logic is no circumvention of a security boundary, due to a lack of a security boundary like authorization.

That's the level we are at. I don't want to know what happens if foreign nation state actors start acting on this seriously.