Pup Biru

viruses also don’t just “do” things, but here we are with COVID and bird flu

assuming you need to be fast that’s true, but if you don’t care how much time you take then you can spread the processing out… this is exactly how MoE models are much easier to run locally, but you could go much further

my CV has objectives, code skills, and infra skills right at the top: 1 para each

work experience also has some relatively plain english: achievements and responsibilities as bullet point sentences

all of these contain opinions somewhere… usually in the form of “i thought and pushed for this, worked great”

objectives is almost entirely opinion: the way i think about systems and what i want to achieve in a professional context

unlikely if you install from official repos, but it’s a more common occurrence installing random debs or curl totallylegit.ru | bash…. or… installing from rpms :p (which if something only ships via rpm is likely to be enterprise and targeting RHEL rather than fedora, so super old and a non-trivial chance of random patches to libraries)

the mechanical loom isn’t analogous to LLMs exactly, but the current generation of AI also includes things like self driving vehicles, which (whilst not ready) is, imo, set to make a huge portion of the logistics industry redundant in the next 20-30 years if not sooner, and the logistics industry is enormous

china having human rights abuses is not an argument against retraining people when technology starts to make jobs redundant

the luddites were taylors and the like fighting against being replaced by machines for various reasons, including child labour, low wages for machine operators, and low quality product

imo child labour laws are the way to solve the first problem: that’s, imo, unrelated to industrialisation/mechanisation

lower wages are a product of lowering the barrier to entry: when anyone can do the same job, that is not a bad thing… it’s sad that an industry of people are pushed out of their profession, but we’d never say the same of coal: coal miners should realise that their industry is not going to exist any more, and retrain,… i have empathy for them, which is why we need to provide social programs to cover industries that get made redundant for any reason, but that’s not a reason to deny the rest of humanity the plenty that inevitably comes from industrialisation

and low quality product is only really an issue at the very start of industrialisation… i guarantee these days we can make higher quality clothing in 100x the quantity than we can with artisans and hand stitching… machines always get better, but only if there’s effort put into using them

yeah… as i said, they had a point in the moment

in 2026 we have retraining programs and social security programs… these are the solutions to industrialisation; not ignorance… the longer you fight industrialisation the harder it hits because rather than happening gradually it happens all at once and society has a harder time absorbing it

the “article” that doesn’t mention luddites at all until a comment at the end that kinda agrees with what i’m saying or the wikipedia article that points out the luddites issues being about labour and generally being replaced by machines? i know very well the nuance of the luddite movement and their main good points, as i said, were about labour issues (mostly solved with labour laws on modern society) and the takeaway isn’t about technology but about how to deal with technology replacing people’s jobs

replacing artisans with machines that do a good enough or better job is a good thing, as painful as it is… it means more people get more of the thing… artisans instead of machines is a waste… humans are the most inefficient general machine we have… having a human make clothing is a cost on society

an LLM frequently writes shit tests… you’re just moving the architecture problem: either you properly understand and review the initial code, which means you catch not just binary “correct input/output” but also performance, layout, DRY, style, heaps of things

OR

you properly review the tests because “passing” doesn’t mean tested

i definitely agree, but plenty leading to waste doesn’t mean that plenty is a bad thing

having enough food to not worry about food waste is definitively a good problem to have. ideally we don’t have food waste because we don’t have enough food for everyone, but just because plenty leads to waste at least initially isn’t an argument against plenty

i’d say it’s not quite like a compiler because you still need to know what the code does… a compiler you largely don’t care, and it’s deterministic… an LLM hallucinates, so you can’t just trust it, which means you have to be able to assess when it’s doing the wrong thing

i agree that setting an agent going helping you learn a codebase is reasonable, largely because it can quickly point out connections in the code quicker than you can understand the architecture, and its guesses are usually just as good as your guesses until you get knowledgeable with the codebase

however, and that’s a very load-bearing however, i don’t think you should just jump into a codebase and just go ahead and tell the LLM to write new code without understanding what it’s done… the understanding is exactly what this graph is trying to show: actually learning is critical, so your review of the code becomes doubly important: you’re gaining institutional knowledge, and you’re making sure the output isn’t slop

they were absolutely not right… the modern world of plentiful clothing simply wouldn’t be possible without industrial clothing machinery (and i’m not talking about fast fashion and waste - though industrial clothing also makes those things possible, i think that’s an outcome of the plenty rather than an inevitable outcome of industrialised clothing)

artisans don’t magically make better clothing… in fact, modern machinery can and does produce much higher quality, complex clothing than a human alone would, and in much higher volumes

they had a moment when they had a point, when the machinery just wasn’t very good (and of course the child labour concerns)

clothing quality on the modern era comes down to choices far far more than the skill of the person making the clothing… artisans are still able to make cost cutting decisions

the point we should take away from the luddites is more about retraining than about their core point… this applies to coal miners and the green transition, and will at some point in the future apply to the logistics industry when driverless trucks become reliable: we can’t just toss an entire industry out of work and expect them to be okay with it (or for that matter expect the economy to absorb them)… but it’s a much better world when fewer people are required to achieve the same output

the luddites had a point… in the moment… kinda… but i think have largely been pretty conclusively proven wrong… clothing is now plentiful, and i doubt anyone would want to go back to paying taylors to make all their clothes for 10x more, even if the clothing would be much higher quality, which i even doubt: clothing quality doesn’t come down to artisan skill any more, it comes down to choices you make, and an artisan can still make cost cutting decisions on fabric, construction, etc

ko-fly preferable to ko-squito… they’re both pests but those fees really sting

rent? it’s keeping your house pest free… you owe it money

(also obligatory that’s not a spider THIS is a spider from australia)

i’d say it’s a balance… you’re totally right that individual requests for review should be relatively small (mostly so that they can all fit in your head at once), but imo equally valid is that everything in main should be a complete feature/fix: if you were to be gone immediately after merging, would someone need to continue or revert the change? would there be unused code laying around?

this is where merge trains and a decent UI around them comes in handy: your main work is on a branch many small PRs each reviewed individually merge into that branch, and then when you’re done pretty much just automated integration tests, lint, and you’re good to merge the whole

but equally some people prefer to solve this with things like gitflow, or just not at all and accept that main is always in flux

refactor to support a new feature is also tricky: does it belong with the feature because it’s unnecessary abstraction without it? or is it its own PR because it stands in its own? and if it’s its own PR then how do you base your own feature branch on it before someone reviews and merges? how do you know you’re done without finishing? what if your assumptions are wrong and you need to try something new - just a lot of unnecessary churn and review?

dev is messy and as always LOC is a pretty useless metric… keeping things understandable is key, and somethings a 17k line PR is the cleanest way to proceed

vivaldi recently disabled uBO and said it’d soon be unsupported. you can re-enable for now

the fact that nothing happened doesn’t mean it was overblown. the fact that nothing happened means all the engineering effort and sleepless nights that went into the problem were well-spent

prevention that succeeds so completely to prevent a disaster that you don’t even notice is just a job very well done: not evidence that the disaster wasn’t real or very dangerous

stringify is used to serialize an object good enough in the large majority of cases because we have far more poorly implemented hacks to work around