zamalek

Platform support for AI has as much place in a browser as it does in Notepad. This isn't about being open-minded at all. I have written multiple MCPs, I use it daily, I am not in the crowd who "don't have an open mind." This outright non-feature is a significant source of issues, least of which is fingerprinting.

Make an AI browser extension. Done.

Shoving AI into anything where it can go is not having an open mind about things, it's nothing more shoving AI into anything where it can go.

On the inverse, can you provide a single reason why this API should exist which is isn't something that obviously erupted from an LLM? Again:

> Browsers and operating systems are increasingly expected to gain access to language models.

God help people if they have to copy their prompt from ChatGPT to Claude.

AI massively empowers people who are incapable of anything except bikeshedding. It itself is very likely to be a bikeshed (but there are legitimate uses), and it also gives them to power to drone on until they overpower any opposition to their useless ideas.

Everything is increasingly expected to gain bikesheds.

Can't wait for the CVEs.

Only the weights and the RNG used to select tokens can answer that. You will understand much if you read up on the quality of code in the CC source leak, it's completely vibe coded and the printf fn is genuinely impossible for a human to comprehend.

I love it too, but instantly knew it would be polarizing the first time I used it :)

Ligatures are a renderer issue, so using alacritty as a lib wouldn't have this issue (it does demonstrate their hardline stance). Another example that would translate is how long it took them to support disambiguation of key combinations: https://github.com/alacritty/alacritty/issues/6378 (2019-2023). Of course, the maintainers are free to do whatever they want with the project - but such things do make alacritty-as-a-lib an exceptionally bad choice for situations where you want things to just work.

Exactly, only humans should have at least one chance to grow and improve. Orgs are heartless legal entities that deserve no loyalty whatsoever, they are all one acquisition away from turning on you (as a customer or an employee).

Large orgs aim to produce some type of output. Their entire existence stems from a "perverse incentive."[1] Governments produce bills and laws, corps produce short-term profits, etc. I am pretty sure that preventing this type of waste consumes significantly more energy than creating the waste - e.g. the agile manifesto, the rework book.

Jobs was probably a good example of this. In my opinion, his image of an innovator is vastly exaggerated. What he did do well was to not invent things. E.G. liquid glass would have never seen the light of day under him: he was adept at saying "no" and preventing waste - Apple is now at the whims of anyone with the next stupid idea, the ideal example of wasteful behavior.

[1]: https://en.wikipedia.org/wiki/Perverse_incentive

That's the one!

There was somewhat recently a post here about how priorities, pressure, and management subverted Dave Cutler's vision for Azure (which was to have near zero human involvement) - my Google fu isn't strong enough to find it. Supposedly, someone running over or opening a serial to a rack/VM is now typical operational procedure.

> Our priorities are clear: availability first, then capacity, then new features.

No mention of Copilot/slopiffication. Probably an intentional omission as Microsoft only has one true priority across all of its products.

The FX-888D is known to have a significant time delay between tip temperature and reported temperature, which is a newbie landmine.

https://www.reddit.com/r/soldering/comments/1le2y4l/comment/...

https://www.eevblog.com/forum/beginners/is-the-hakko-fx-888d... (#7)

https://www.reddit.com/r/AskElectronics/comments/qcofiq/comm...

https://www.reddit.com/r/soldering/comments/1282gci/comment/...

It was maybe the best at the price tier 10 years ago, but smart tips make things much more predictable. The FX-888D is dated and suggesting it is bad advice; you overcame its shortcomings while learning and years later are left with "the good parts." Try do something with it when it reports that it's at temperature, bonus points for changing the calibration by mistake or straight into a large copper pour. Smart tips have a much more forgiving learning curve, and then the user might subsequently have more success with something like the FX-888D.

I personally ran into this when starting out, not knowing what I was doing wrong for literal months - until I got the Pinecil, which was night and day.

I just don't know why anyone would suggest something that's "good enough" over something that's genuinely good.

Breadboards[1] with breakout boards[2] (the Pi Pico in particular is incredible, having an unusually detailed and correct datasheet). MicroPython is probably a great way for gets to get started on the compute side of things. Once you have something working on a breadboard then you can "graduate" to PCB design (and there's nothing wrong with designing the PCB to take a breakout daughterboard) - possibly perfboard as an intermediate step. Use KiCAD - it's Blender-tier open source software. A high quality breadboard and wires are very important - I guess diagnosing a loose connection is a learning experience, but it would be an overall hindrance to learning if encountered frequently.

Have many spares of all components (including breakout boards) handy - they will probably summon the magic smoke a few times.

They will likely quickly need to learn how to read data sheets. You can often get away with copying the "typical application" and avoiding the real technical stuff.

Friendly reminder: those brains are still developing. Adequate exhaust is extremely important (even if you are using solder-free, flux fumes are varying levels of toxic). You want those fumes going out of the window, not via a filter into the same room. Any complaints about headaches are serious: you aren't extracting the fumes correctly. There are a few important things to know about soldering: "there is no such thing as too much flux," "solder likes to flow towards heat," and "heat the thing and apply the solder to the thing (not to the iron)" (to keep the technique at its most basic).

The often recommended Hakko FX-888D is just plain awful. The Pinecil is way better (yes, even though its a fraction of the price) or the TS100/TS101.

[1]: https://en.wikipedia.org/wiki/Breadboard [2]: https://www.raspberrypi.com/products/raspberry-pi-pico/

Awesome! It's been a while, but my next level of learning was designing PCBs without breakout boards (and I had several failed revisions). This will be great to learn from.

Put infra deletion locks on your prod DBs right now, irrespective of whether you use agents. This was a well established practice before agents because humans can also make mistakes (but obviously not as frequently as we're seeing with agents).

If you do use agents then you should be able to ban related CLI commands in your repo. I upsert locks in CI after TF apply, meaning unlocks only survive a single deployment and there's no forgetting to reapply them.

Only when required, though. It's a conflict resource (which tends to make it more expensive).

Same would apply here, but the paper talks about moving molecules around so maybe quantity would eliminate the issue.

> It lazily hand-waves issues away in order to avoid reading my actual code and doing real reasoning work on it.

It decided to leave the write endpoints added to an authentication service completely unauthenticated. The effort to do the contrary was about 6 characters, and in the claude.md. It tried to implement PKCE by embedding _everything_ in the state.

This thing is beyond untrustworthy.

The fact that they are using Claude to build Claude (not just Claude Code) probably explains a lot.

Anything where there's _at worst_ solder and traces between the compute and the memory. That's why you see it on GPUs (and Apple hardware). DRAMs advantage is modularity.

At least as I understand it.

Not a rec, but just my source: Atrioc (streamer, YouTuber) is good at gathering all the facts for the rest of us. There's many other things in play, like the Strait of Hormuz (helium, bromine). Ultimately it works out that the shortage, and shortage profits, will continue; the chip makers are probably going to continue to see record profits (as Samsung has).

The specific mix of factors could change at any time, but the supply chain is relatively inelastic, it will take some time to show up on price labels.

That flashbang happens during the initial latency (DNS, RTT, any server slowness).

I love the idea of ending it for myself, but my users are still screwed?

Is there still no way to prevent the flash bang while waiting for initial content from the server?

> It seems like 90% of Claude's recent problems are strictly lack of compute related.

Downtime is annoying, but the problem is that over the past 2-3 weeks Claude has been outrageously stupid when it does work. I have always been skeptical of everything produced - but now I have no faith whatsoever in anything that it produces. I'm not even sure if I will experiment with 4.7, unless there are glowing reviews.

Codex has had none of these problems. I still don't trust anything it produces, but it's not like everything it produces is completely and utterly useless.

Claude to plan, codex to implement. Claude's giant context is great for reading large amounts of code but it is currently incapable of following instructions/guidelines.

The IPO theater is in full swing.

I am also on Codex while Claude seems to be blatantly ignoring instructions (as recently as Thursday: when I made the switch). The huge Claude context helps with planning, so that's all it does now.

Codex consumes way fewer resources and is much snappier.

The last two weeks with Claude has been a nightmare with code quality, it outright ignores standards (in CLAUDE.md). Just yesterday I was reviewed a PR from a coworker where it undid some compliant code, and then proceeded to struggle with exactly what the standards were designed to address.

I threw in the towel last night and switched to codex, which has actually been following instructions.

> Ignores instructions

> Claims "simplest fixes" that are incorrect

> Does the opposite of requested activities

> Claims completion against instructions

I thought it was just me. I'm continuously interrupting it with "no, that's not what I said" - being ignored sometimes 3 times; is Claude at the intellectual level of a teenager now?

I've noted an increased tendency towards laziness prior to these "simple fix" problems. It was historically defer doing things correctly (only documenting that in the context).

It was later reproduced on the same machine without huge pages enabled. PICNIC?

Absolutely. That's typically a good problem to have :). Hopefully you would had gradual enough growth to implement elastic scaling before this is an issue, but you're definitely eventually screwed and have to outright copy what the likes of FAANG do - your startup is a unicorn at that point, so you'd probably already have the talent hired.

> Here’s an exchange I had on twitter a few months ago:

The purple account is just plain wrong. Classically, the full architecture is this (keeping in mind that all rules are sometimes broken):

* CQRS is the linchpin.

* You generally only queue commands (writes). A few hundreds of ms of latency on those typically won't be noticed by users.

* Reads happen from either a read replica or cache.

The problem the author faces are caused by cherry-picking bits of the full picture.

A queue is a load smoothing operator. Things are going to go bad one way or another if you exceed capacity, a queue at least guarantees progress (up to a point). It's also a great metric to use to scale your worker count.

> What will you do when your queue is full

If your queue fills up you need to start rejecting requests. If you have a public facing API there's a good chance that there will be badly behaved clients that don't back off correctly - so you'll need a way to IP ban them until things calm down. AWS has API Gateway and Azure APIM that can help with this.

If you're separating commands and queries you should _typically_ see more headroom.