maybe you can skip C and just use assembly
Or fab your own chip.
Readit Newsguhcampos commented on Performance hacks for faster Python code blog.jetbrains.com/pychar... · Posted by u/ashvardanian
guhcampos commented on Asus Announces October Availability of ProArt Display 8K PA32KCX press.asus.com/news/press... · Posted by u/Roachma
The problem with using this kind of monitor for any work that others will view on their own monitors is that your perception of what looks good will be way off. For example, it's clear that a lot of the Rust UI framework developers have been working on Macs for the last few years. The font rendering on many of those look bad once you plug them into a more normal DPI monitor. If they hadn't been using Macs with Retina displays they would have noticed.
This is more widespread than we like to admit.
Developers writing software on 64GB M4 Macs often don't realize the performance bottlenecks of the software they write.
Developers working over 1gbps Internet connections often don't realize the data gluttony of the software they write.
Developers writing services over unlimited cloud budgets often don't realize the resource wastes into which their software incurrs.
And to extend this to society in general.
Rich people with nice things often alienate themselves from the reality of the majority of people in the World.
guhcampos commented on Kafka is Fast – I'll use Postgres topicpartition.io/blog/po... · Posted by u/enether
Why can't you? In my experience, scaling Kafka was far easier than scaling our RabbitMQ cluster. We started running into issues when our RabbitMQ cluster hit 25k TPS, our Kafka cluster of equivalent resources didn't break a sweat at 500k TPS.
How did you handle re-partitioning and rebalancing every time you scaled your cluster in or out?
guhcampos commented on Kafka is Fast – I'll use Postgres topicpartition.io/blog/po... · Posted by u/enether
Yes but the practical reality of it is it can be used exactly the same way as you would do a queue and you can make it work just as well as any MQ based system. I know this as I moved from a RabbitMQ system to Kafka for additionally scalability requirements and it worked perfectly.
So sure "technically" it's not a queue, but in reality its used as a queue for 1000s of companies around the world for huge production workloads which no MQ system can support.
It is a *very bad* replacement for an MQ system, for the simple reason you can't quickly and effortlessly scale int/out consumers.
guhcampos commented on Designing software for things that rot drobinin.com/posts/design... · Posted by u/valzevul
Here's me hoping this was something for Factorio: Space Age...
Hahaha my exact thought.
guhcampos commented on Designing software for things that rot drobinin.com/posts/design... · Posted by u/valzevul
Yes. I thought of Gleba too.
guhcampos commented on Bots are getting good at mimicking engagement joindatacops.com/resource... · Posted by u/simul007
This possibly counts for some of it, where you are just the collateral damage of somebody trying to disguise their bot as a real user. It feels unlikely to be the majority of bots though, but I could be wrong.
I'm not sure how many of these there are, but they're very significant.
These are bot networks run by big firms just building reputation overtime, to be switched on during some huge - usually political - campaign.
Suddenly, in some point in the future, all these "legitimate" looking "people" start inflating discourse against some political figure in some country and completely flip the democratic game.
It happened way too many times in the past decade.
yeah claude is really eager to apply stuff directly to the cluster to the wrong context even with constant reminding that it rolls out through gitops. I think there's a way to restrict more than "kubectl" so you can allow get/describe but not apply.
Exactly. I'll need to dig deeper into its allowlist and try a few things.
Problem is: I also force it to run `kubectl --context somecontext`, as to avoid it using `kubectl config use-context` and pull a hug on me (if it switches the context and I miss it, I might then run commands against the wrong cluster by mistake). I have 60+ clusters so that's a major problem.
Then I'd need a way to allowlist `kubectl get --context`, `kubectl logs --context` and so on. A bit more painful, but hopefully a lot safer.
May I gently suggest isolating production write credentials from the development environment?
I was diagnosing an issue in production. The idea was to have the LLM would need to collect the logs of a bunch of pods, compare the YAML code in the cluster with the templates we were feeding ArgoCD, then check why the original YAML we were feeding the cluster wasn't giving the results we expected (after several layers of templating between ArgoCD Appsets, ArgoCD Applications, Helm Charts and Prometheus Operator).
I have a cursor rule stating it should never make changes to clusters, and I have explicitly told it not to do anything behind my back.
I don't know what happened in the meantime, maybe it blew up its own context and "forgot" the basic rules, but when I got back it was running `kubectl patch` to try some changes and see if it works. Basically what a human - with the proper knowledge - would do.
Thing is: it worked. The MF found the templating issue that was breaking my Alertmanager by patching and comparing the logs. All by itself, however by going over an explicit rule I had given it a couple times.
So to summarize: it's useful as hell, but it's also dangerous as hell.
I think it also is important to remember the purpose of specific numbers. For instance I would argue a PN without the birthday would be strictly worse. With the current system (I only know the Swedish one, but assume it's the same) I only have to remember a 4 digit (because the number is bdate + unique 4 digits). If we would instead use completely random numbers I would have to remember at least an 8 digit number (and likely to be future proof you'd want at least 9 digits). Sure that's fine for myself (although I suspect some people already struggle with it), but then I also have to remember the numbers for my 2 kids and my partner and things become quickly annoying. Especially, because one doesn't use the numbers often enough that it becomes easy, but still often enough that it becomes annoying to look up, especially when one doesn't always cary their phone with them.