tetha

If the addressed person does not comply, you can also add "or else" in a threatening tone.

Such a funny movie.

And even with a mutual agreement - default LLM output tends to be very hard and inefficient to read. We've spent quite a bit of time at work to setup a few writing skills for Claude.

For example, mine is a technical writing skill based on the old book "The Art of Scientific Writing": Front load information as much as possible - the first paragraph of a document should be a summary, the first sentence of a paragraph should summarize. Short sentences building on each other. Always show evidence.

Someone else spent quite a while optimizing a standardized PR description template, with a section for intent, expected changes, risk, rollout coordination and such.

That made the slop a lot more tolerable.

Oh nice. Then I have to thank you for a possible non-horrible upgrade path. If you were close by, I'd invite you for some icecream or a round of pool :)

Good to know. Does the first invocation recompute and check the hash of the wheel locally afterwards to ensure integrity?

Rebind the keys for player one.

That being said, the one player campaign seems way faster and higher damage than I remember. But heck I love this blast from the past.

And strictly speaking you cannot trust the pip upgrade of pip with the vulnerable cert in the trust store due to certifi, which you also cannot upgrade safely with pip for the same reason. All of these are at one out of two compromises from being MITM'd during the upgrade.

So strictly we have to burn everything python to the ground and reinstall entirely.

They are also incentivized to find high severity vulnerabilities - and/or to announce found vulnerabilities as high severity.

After all, what would all that hardware and research be worth it, if it didn't find the most critical vulnerabilities around?

Well at least we know about it while or before the giant patch effort for everything else goes on. Just put it onto the pile.

Who turned on hard mode this week?

It's the attitude that riles me.

This demonstrates how hard we are messed up in a CA revocation. But no need to rub it in like that, is there?

> He added that global SSL/TLS is a small part of eMudhra’s business contributing to about 1% of the global revenue

Good that we are now investing thousands of engineering hours globally to fix this.

Several tech stacks require upgrades of their runtime, python is an ungodly mess with certifi, but yes. It's just 1% of your revenue.

Sorry, it's been a long week.

I think I'm too old for this industry

I want to go back to talks by bored defcon guys or gals calmly stating how they obtained private keys of a globally trusted CA with just a bit of math. Which, mind you, ate the other part of the teams time.

Now I know how much I hustled today likely due to that atrocity of a video. I think I will take a vacation day and sit in a forest near a river on friday.

Quite the strange communication. It was posted on the forum in May, and may have landed in developer notes afterwards, but the general mail to users went out less than 1 month before deadline. And now quite a few customers are mad.

It's also not the best business case. We've been tolerating infra-code in Bitbucket, because it would be a pain to migrate.

Now someone snidely remarked: Once we have done this migration in a hurry, don't we know all the places we have to touch to move out of Bitbucket - in order to avoid such short-term activity? It's difficult to answer no to that.

Curiously, that makes integration a trapdoor function and a possible cryptographic primitive. Not a very practical one, but...

I'm on the fence there.

To pace something is a fairly regular formulation in racing, running, cycling, most sports. You can "pace yourself to reach the festival by bike in about three hours to not gas out". This means to control your speed and time investment intentionally so you don't run out of energy or steam and run into leg cramps before your goal. We can "pace a rollout slowly to burn out risks", or "increase the pace of a rollout due to adverse factors".

But I have noted a point to simplify my vocabulary at work to optimize the audience capable of understanding. So I rather defer the delving into deep dark corners of the dictionary derived from devouring literature to a simple intro or outro, and people find it funny, especially if the rest is easy to read. Claude on the other hand does not do that.

I would rather say the argument is simplified, but on a decent track. Because there are two angles to it.

I've been wondering what sectors I wouldn't maintain and develop infrastructure for, because I consider it a strength of mine that I don't entirely care about that. I'm not excited about your product, for good or bad.

Defense for example is on an edge there. Supporting the creation of death and suffering in other humans does not sit right with me. Being defenseless doesn't sit right either, as it can create suffering and death for people I know as well.

Online gambling is more on the nope side. Maybe with a decent regulated german company, but if you start working with some eastern-europan online video gambling sites with pretty girls as dealers, you are suddenly very close to human trafficking and many more things connected to it.

So I guess directly causing human suffering and pain is a boundary for me. And yes, if you push that argument to an extreme, if you search long enough, you realize that pure existence causes suffering to other people, animals and the planet and must be ceased.

But then there is that other side - in the current system (and arguably many before) you have to do a job to get money to live, and a lot of people like the person making cars have no choice about that. I guess we are contributing to that suffering as well by existing.

So, minimizing the direct suffering and pain I cause seems to be a sensible directive.

It's funny. My experience of running Win95-Era Games, especially more wonky one like Cavelands on Linux with Wine is far better than on Windows. And DosBox is a given. So e.g. both Civ 2 and Civ 1 are just standard launchers on my Linux box.

And with something like Lutris, it's not a lot of tinkering. "Install game from setup.exe". Done in a lot of cases, needs a few winetricks or dll overrides in some cases for the wonky ones.

It's going to be interesting, because liability cases tend to revolve around the involved people, the duty they had in a situation, and if they fulfilled that duty (or were prevented in some way by someone else not fulfilling their duty).

For example, for a runaway car (example from a sibling comment), the driver could be liable because they forgot the parking brake. The driver could be liable for a lack of maintenance and inspection. A mechanic could be liable for not reinstalling brake pads correctly. Or the manufacturer of the car or the brake pads could be liable because of a systemic defect.

Or it could grow even more complex, maybe the brakes are designed that they have to be maintained in a very specific way, and the mechanic did a reasonable maintenance and inspection but it failed later due to this maintenance. That could split liability between the manufacturer and the mechanic.

As an example, with other software, you as a developer or operator of a software have a duty to ensure it does not access computer systems you do not own in unintended ways. And this could go beyond liability into criminal territory.

It'll be interesting what OpenAI gets slapped with there.

> It is precisely about showing that you can still propagate backdoored code if the compromised binary in your seed is NOT the compiler.

But that seems like quibbling about semantics. Thompson says that if a compromised binary generates a binary, you cannot trust the generated binary.

This does not even have to be gcc, it could be vim. Or strip. Or cat. Or dd.

Or an iop to write data to persistent storage if the firmware of your SSD is compromised.

> Skills have some instructions but are primarily informed repo specific instructions and keep their context away from the rest of the repo to keep things sanitised for me.

Skills and agents in the Claude world can also be extended and evolved over time, as they are committed "code".

For example, we have an agent which can take a statement or a support ticket and identifies the services, tenants and infrastructure components likely meant in the ticket or request. Similar to a skill, Claude can invoke this on demand in a conversation.

This started very simple, but various people spent time tuning it over the last 4-6 months. They have "taught" it to pick up on jargon from different departments, writing style of different departments, how they think about their systems.

With all of that tuning over time it has become quite "clever" in identifying the mentioned systems and - if requested - the train of thought leading to this conclusion.

Similar things are happening with skills for various task, be it Ansible integration tests, upgrade chores and so on. The first version can be fairly underwhelming, but continuously improving it after each usage can make them very powerful.

This becomes fun if you start to prioritize security work on CVEs rated higher, not affecting you, over security work on CVEs rated lower and affecting you.

Or prioritizing chasing CVEs currently not affecting you over architectural work improving security.

The CVE should be fixed, I fully agree, but where does it land as a priority? Less competent security teams push /all/ CVEs as Sev0 over /all/ other topics.

I agree this is a scope or focus thing. Different tools for different things.

If you are already maintaining a tool chain, a supply chain and skills in an SPA framework for multiple customer-facing, client-driven projects, I don't think you have much of a use for HTMX. Hence why at work, we have our full-time frontend engineers doing this, because it gives you the most flashy quality.

I am an infrastructure engineer. I have privately tried out a couple of SPA frameworks, The complexity to set this up for the first time is immense. And if you have rarely touched projects, the churn of the tooling and dependency ecosystem is taking up a significant amount of time for something that may be nice to have at work, or a pet project at home.

It's not cool if you have half a day to touch an old project and everything has rotted away around it so nothing interesting gets done. Something like Pydantic, Flask or Django + Jinja generally doesn't do that. And HTMX can make it nicer fairly cheaply.

I'm right with you. My dad was a farmer and taught me: First deal with the irregular, annoying parts on the outside. Create rectangles with a long side and turning space on each shorter side. Then deal with each rectangle by going back and forth along the long edge. The turnarounds are also a great place for some wheelbarrows to collect the clippings closest to the Komposthaufen.

Hence why I went for the irregular strange part on the lower left first, and then the more regular part on the right. That's the weird rain collection, herb garden, thing we have at the back.

> People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done. Any senior engineer knows this all too well

I've been pushing against this "maximum LLM driven speed" in our infrastructure as well and been working on a middle ground:

We can generate a change to Ansible or terraform code in half or a third of the time, sure. But we don't use this to make three times the changes in the same time frame. We rather use the freed up time to discuss the change, the context and the affected systems with 2-3 engineers maintaining them. And yes, at times this means us three are sitting around half a day discussing and drawing diagrams about our systems.

I'm just happy to work in a company understanding the value of speeding up less than we could in the feature direction, but investing this time in the direction of control and understanding of the infrastructure.

In our case, "testing" as an environment has the goal to be a fully integrated setup of the entire service landscape. Each team is responsible for the uptime of their service, just like in production.

The teams are running automated end-to-end tests against this environment. On top, pre-sales uses it to build demo and sample environments, sales shows demos on it, solution engineers use it to test/try out the important parts of projects.

That generates a good production-like experience for the team: You have customers using the system, and possibly screaming if you break it. And it has been pretty successful at catching problems missed or integration failures.

This is one of the unintuitive parts when you get into operations: If you go to lower layers in the stack, production expands towards dev:

To the product developers and operators, customer-facing systems are production.

To us in infra-operations, dev and testing are actually production as well. Maybe with a lower SLA and easier maintenance scheduling, but if we fry dev or testing, a hundred developers can't work and start screaming.

Within the infra-ops team, our config management tests and the deployment pipelines are production. If those don't work, infra operators cannot test or roll out changes to the infrastructure.

This was recently discovered by a dev team providing a cross-cutting service: Their testing environment can halt work for a lot of other teams, so they have to be really careful with their testing environment.

In my experience, business software has narrow and predictable use cases. Note taking: You need to add, delete and update notes and the real meat of the product is usually in the note organization. Even SAP has use cases simple in nature: Account for milk cartons sold. The use cases just grow complex once you work in 30 countries or more. "Pay the right taxes on milk cartons sold" becomes tricky.

However, this is parallelizable: You can work on all 30 countries at once and ship when ready. You can work on taking and organizing notes in parallel. You can work on scaling in parallel. You can streamline UX in parallel while introducing tagging, or trees, or groups, or anything.

A game, and especially a narrative game, has an intrinsic linear component, the plot. You can work on a certain amount in parallel, sure: Once the rough shape of the plot is laid out, you can start working on assets, necessary engine features, sounds, dialog in parallel.

But you still have a strong need that a player or play tester has a good progression from act one to act two to act three, and a good progression from puzzle one to puzzle two to puzzle three. This takes a lot of very slow iteration.

This involves human testing by nature. You get a playtest every few months, if you have the money. You can easily throw more CI hardware to run your integration tests more often for more countries. Playtesters, especially those who don't know the game, are very, very limited.

Then you also want characters and settings to be consistent across the plot. If done well, this takes a lot of adjustments and refinement both back and forth. Sometimes the setting of Act three requires a character to have a certain trait, and that trait should be developed, so you now go back to Acts one and two to see if you can build up the character -- without knocking down the entire house of cards already in place.

And once you get to polish and atmosphere, it becomes even harder and more time consuming, because then you need new playtesters even more.

From a past job and working on some features, I spent a day or two presenting like 6-8 different options, and then spent half a day in different testing groups to figure out which procedural generation option "feels the best" for what the game designer wants. With a better spec, that could've been an hour. This made players more excited. Probably.

Back when we were working in the office, this was honestly a preferred pair programming setup for us. Two people, and each just had their keyboard and mouse.

Interestingly enough, it seemed that the inputs from multiple mice onto the same cursor is summed up by default. So you could fight cursor movement you disagreed with by moving the mouse in the other direction.

Very silly, but quite funny.

Yeah I wanted to see if they special cased Wacken. One campground later, 85% done.

You jest, but companies have sent people home fully paid, because power or internet were down and would be down for an extended period of time. Technically a small number could have kept working on white-boarding design topics, but without access to documentation, existing tickets, it would have been minimally effective.

It's not clear if or when these tools become as essential as power or internet to a developers or admins work, but if they do? Giving everyone a quarter day off at least generates some good-will, unlike forcing them to sit around unproductively because of working hours.

Some of my deepest architectural work honestly happened... in a hammock on the balcony, while alternating between staring at a cloud, the sun, and two magpies building a nest in the birch tree while yelling at me occasionally.

Then I came back to my desk, saw that I had missed a call or two from my boss and he had a concerned message of where I was. I ignored that and sent him an architecture document an hour later. After years, it is still the backbone of our hosting infrastructure and will go into certification audits later this year.