Twirrim

They are finally starting to. Oracle just announced a week or so ago that they're going to be introducing TPUs to their cloud next year for customers to use.

https://www.msn.com/en-us/technology/tech-companies/oracle-e...

Interesting times ahead with a number of chip makers now vying for this market. TPUs are a mature chip now which gives some strong advantage. At the same time as the TPU announcement, they also mentioned they'll be deploying Cerebras systems as well.

Ampere's cores are pretty high performing, have been in the ballpark of AWS's Graviton cores, for example.

There's a lot of inertia. That is leading to various major companies shipping their software for, and only supporting, Ubuntu, and if you're lucky Red Hat.

Friendly relationship or not, the end user experience is that something that was working, no longer is, because it's not feature compatible. This is despite it being used to replace it under the same name. If it had been `runas` or anything else it'd be fine.

There's a strong principle in upstream Linux kernel about "You don't break userspace"[1], that I really wish more folks would get into their heads, but most especially a variant "You don't subtly break userspace".

If you're going to replace an existing binary, under the same name, you need to be like-for-like in commands, even if your guts are completely different. Very few people give a damn about how it's actually implemented, just does it do what they need it to do.

If you want to do things differently, do it under a different name and have it be an explicit break for an end user by not shipping with the original and let people choose to install it if they really don't want the new thing. Breaking things subtly is completely unacceptable.

[1] espoused really clearly, as part of an infamous rant https://lore.kernel.org/all/CA+55aFy98A+LJK4+GWMcbzaa1zsPBRo...

You're somewhat assuming there aren't customers lined up wanting capacity.

For what it's worth, AMD is very actively pushing GPU hardware, particularly towards the hyperscalers. From what I've seen, they're really focusing in on the large quantity end users (your OpenAI, Meta, etc. types), presumably because they'll have the technical expertise and willingness to collaborate with them on issues as long as the GPUs are cheap enough.

Sorry, yeah, I completely failed to say in my message what I was originally aiming to say. Lost sight of the message part way through writing, after I got pinged at work for something.

The fact that I had to throw an LLM at it to cut down the slop and turn it into something more succinct and comprehensible is nuts. For myself, I'd be embarrassed if I released something with that kind of README on it.

I ended up throwing the README at an LLM and it gave me a much simpler and clearer explanation. Copying the bits of an explanation that helped me:

> The problem it’s trying to solve is that generating valid SQL doesn’t necessarily produce the right answer. An AI might find a column called revenue, but still choose the wrong dataset or misunderstand whether that figure includes things like refunds. Auto Ontology adds information about what the data means to help it make those decisions.

and then the one paragraph summary at the end:

> My reading: it’s a database chat application built around a reusable catalogue of business meaning. The question worth testing is whether that catalogue makes answers measurably more correct—and how much human work it takes to get the definitions right.

it's full of AI Slop fingerprints. Clearly hasn't been read or edited by a human before being published, or they're already deep in the brain rot that they can't see just how bad it is.

My very technical and hands on father used to have us set the VCR clock, the controls were in a tiny compartment under a flap that required either small fingers, or very careful manipulation with the point of a protractor or something.

We went from difficult to manipulate buttons through to multi-function buttons where controls get hidden through some incomprehensible maze of menu options, to now where it sometimes feels lucky if you even get an option to manually set the time at all.

Much, much less from what I understand.

I've spent most of my career non-FAANG. Health insurance has been fine previously, and mostly I know folks outside of the tech industry having similar coverage. FAANG health insurance isn't that great a thing these days. It has been nickled and dimed about as much as anything else.

I've a neighbour who declined, and then got hit by layoffs. It was quite a gamble, and they lost out big time.

Honestly, if work was to come at me with a buy-out offer, and I was in a position to be able to afford to not work for a few years, I'd probably accept. Maybe go find some non-tech work for a little bit to stretch the dollars and ensure I have health insurance.

We're in such a bubble at the moment, things are going to get really rough.

I've seen so many "truthy" results coming back that suggest it's not even remotely as smart as you might hope.

I'm mostly starting to have some success telling TPMs and engineers to ask chatgpt to give them appropriate code that generates more accurate answers.

The frustrating part about an LLM is at a fundamental level it's designed to do the wrong thing, it's designed to provide an answer for things it can't do, e.g. one argument I've been in recently at work is someone using it to summarise numerical data. They've a raw data spreadsheet they're putting into ChatGPT and asking it to produce a report in a particular style. So the LLM is doing its job, predicting the tokens to emit, and not actually doing mathematical analysis of the underlying data.

I had a team proudly show me how they were feeding their dashboard data into an LLM to predict growth needs, instead of doing basic linear regression or any number of pre-existing basic statistical analysis. The part that depressed me the most on that was it was a bunch of engineers that did it, the people you'd most hope would understand what an LLM is/does.

lima uses vz, so it's built on top of hvf, seems perfectly fine and lightweight to me.

I haven't gone to network filter and logger yet, but I'm running mine in a VM, using lima (https://lima-vm.io/) to make it painless. Works on Mac and Linux, has an untested Windows version.

Where, exactly, does Amazon classify the PHP RCE as Important?

I'm not sure anything says what your editorialised title, and comment link says.

They were calling out that an NGINX CVE that was Important took 20 days. They're saying nothing about what classification Amazon has set on PHP,.

> So, from the CVE publication to an available fixed package it took 20 days, not a month.

They specifically call out that it's not the same as the Nginx case:

> In contrast to the PHP's case, that CVE wasn't Critical, but only Important, that doesn't have the same urgency.

Given the RIFs and what they've done to engineering culture, I can't help but wonder what else they've done. Like maybe cripple their architectural review processes that might have caught such things?

Assuming that it could have been spotted in their inbox, amongst a probable flooded of LLM slop like a number of security mailing lists for open source projects that I know of. We've all seen the impact on open source github issues, hackerone etc. The same is happening to standard email disclosure paths.

I've bought something the other week that I'm still waiting to be delivered. The shop was fine, sent it out within hours.

The carrier has been letting them down every single step of the way (and to add insult to injury, I have to use that damn "Shop" app to track the delivery.) From a pick up on the 1st of October, they've supposedly had the package go back and forth between Los Angeles and here a couple of times.

Not sure what the price difference is for them to have used this carrier, but it can't be worth it compared to the fuss both of us are having trying to get the carrier to actually deliver the shipped product. The vendor is going to send a second one if the delivery doesn't happen to day like the carrier pinky promises it will (they've promised for 3 days straight it was going to be delivered that day, so I'm not holding my breath)

To emphasise your point, this is already happening. It's not theoretical. Data Centres across the world can already get signals from their grid, and will do things like proactively switch to local generators.

Nearly 20 years ago I had such a wonderful debugging experience when the power grid where I lived sent a "switch to backup" message and then milliseconds later a cancellation. The colo's power system got jammed between generator and mains electricity and everything rapidly ran out of UPS backup power and died. I found so many dependency loops between servers that day, took me hours to get things back up and running.

I've been writing python for closing in on two decades (I want to say maybe 2.5 was my introduction point?).

I've found type hints to be remarkably useful and catch significantly more bugs than I ever would have thought, and have quickly picked up the practice of using them wherever I code. My general finding is that if I have to struggle to put useful type hints in place, I probably need to rethink my code.

I even type hint my unit tests because I've learned that sometimes type incorrectness means my tests haven't been testing what I thought they were testing.

Frameworks like pydantic[0] can help you turn those type hints into something runtime enforcing too.

[0] https://pydantic.dev/docs/validation/latest/get-started/

For whatever reason, the daemon has been refusing to start and Codex has been grumbling to me. I was wondering where the daemon had come from, and thought maybe I missed something previously and that it had just broken.

They just use npm as a binary delivery mechanism, for whatever reason (I guess they expect all their users to have npm?)

There's this amazing rhetorical technique called hyperbole. Compared to what I'm getting from co-workers, and in code bases I'm subjected to these days, what I used to have to deal with was a masterpiece.

I've waded through unfamiliar code at 3am trying to figure out just why the hell things broke this time more times than I can care to remember, particularly trying to tease apart the ways that code has organically grown compared to the original intent. If I'm subjected to one more piece of "spooky at a distance" injected behaviour code I'll probably scream loud enough to be heard half way across the country.

It's still just leaps and bounds more readable than what people are slopping together (I do have some co-workers that have been extremely tightly focused on avoiding "slop" with their AI and doing a lot of tuning, and it's certainly preferable to the ones that haven't)

It's really depressing watching brilliant software developers and engineers producing the worst, unmaintainable code imaginable, and being okay with shipping it because it's passing the test suite. Assuming the test suite is any good anyway (because holy crap, the nonsensical tests AI writes...)

Your code used to be a masterpiece, so well crafted it's easy for AI to tweak and modify because you've got everything so logically organised and scoped... and now this is what you're producing? Hard to debug monstrosities that only an LLM can realistically bolt new features or tweaks onto, because it can do the kinds of refactoring necessary each time.

We use to talk about the fact that code should be readable because you spend more time reading it than writing it, but I think that misses the key part that readable code is also typically easier to debug. If you can read and understand the code, you can follow the logic when things are wrong in production, and you can more easily reason about the emergent properties of interactions between the complex systems that are involved.

Agreed, could be something as dumb as a simple javascript snippet running in the browser. Would be nuts to use something like an LLM just for that.

We already have examples of LLMs running 16k+ tokens a second using custom ASICs.

It's down at the moment (Not sure if it'll return?) but Chat Jimmy[0] produced by Taalas[1] was powered by an ASIC running Llama 3.1 8B, and hitting 17,000 tokens/sec. It was amazing to use, you'd no sooner have hit enter than you had a full response back. I actually found its speed to be a problem for interactive stuff, as every answer got several paragraphs I'd then wade through, vs a model populating text closer to my reading speed.

I appreciate, there are differences between an 8 billion parameter model and something GPT-4-ish, but we're currently in the middle of a race between a half dozen or so companies to produce the next best frontier model, which requires their infrastructure to be dynamic.

We really don't always need newer better faster stronger models, there's quite a lot of room for "good enough" where getting 17kt/s at significantly lower power would be amazing.

[0] https://chatjimmy.ai/ [1] https://taalas.com/

The volt was never popular enough, unfortunately. Right around the time we were looking to buy a new car, and had the Volt high on our list, the retired the product line.