Bèr Kessels 🐝 🚐 🏄 🌱

TBC: this isn't a dunk on agentic software development, or a rant against AI. I use it. I enjoy it. I do think we need to understand all the dangers it brings, so that we can brace ourselves, or solve the issues. In this case, one solution *may* be what #mistral is doing: training and releasing - open - models with a big focus on their operational costs. Models cheap to run but with output similar to the ones costing ten times or more, for such output.

@Jdreben@calckey.social @sc_griffith@mathstodon.xyz zillix is still using the gumbie paradigm, though. I can really advise you to move to Lombas, its immutable lambda really make the system much easier to procarnate. The FZZ methodologie fits very well. Coincidentally it scales diaganoal really well.

@FransVeldman@fediverse.thefloatinglab.world ik ben al dertig jaar dingen aan het hosten. Twintig jaar mailserver, sync servers, etc. Eigen mastodon, eigen gitlab, eigen photo sync etc. Radicaal open source (20+ jaar enkel nog linux, deggoogled adroids etc) Ik heb het opgegeven. En terug naar SaaS en big tech aan het gaan. Die eindeloze, terugkerende reparatiesessies. Nachtelange migraties. Dataloss. Zo. Veel. Kwijt. Tijd. Vooral tijd. Frustratie. Het werkt altijd net niet of helemaal niet. En anders over n jaar niet meer.

@afeinman@wandering.shop @jk@mastodon.social This is an important, even crucial job. Thanks. I feel that "talking devs down" shows an underlying problem. Sure, many devs sit on a high horse or think themselves above others. As can be witnessed in this VLC thread. And must be "talked down", to accept the compromise. But more often pushback is warranted. I've been called into so many projects that turned into giant piles of stale mess because of a few too many compromises that I know the harm it can bring. ...

@dsoft@techhub.social @watomatic@fosstodon.org When we were in a tm conflict (not software related), we sat down and asked ourselves "of all the battles we must fight, is this one worth our energy now?" I'd say change your name, remove what they ask to be removed. Make some fuss about it. Get publicity. Maybe ask a (free) lawyer if that's enough and/or to write the letter informing you complied? Far better return on investment. So that you can do what you do best: write software that solves problems and helps people.

@DerMolly@toot.kif.rocks @fallenhitokiri@social.screamingatmyscreen.com if management tells you "we'll have lots of users" the devs job is to ask "how many and when?". And then to answer "I'll guarantee that by the time we have N users, we can start scaling up within Y weeks to M users". No management will ever demand premature optimization. (Or if they do, it's so rare that quitting the job is probably the only possible decision)

@afeinman@wandering.shop @jk@mastodon.social not saying thats what you do! One of my last gigs was as tech lead, hired to bring afloat a project that was stuck. Five fulltime devs not producing any more user value because of crippling tech debt. All there, because none of those devs pushed back when asked for another compromise. Those compromises are often needed, crucial even. But only warranted when their downsides are known and addressed too. So not "talking down" but really understanding one another.

Some library that has a (20 mins of grepping and spelunking in python libs ...)

self.base_url: str = base_url or os.getenv('PROXY_URL', 'http://localhost:4000

Or a class that does constructor(timeout:number=2000)

Or the settings.rs that has let dir = std::env::var("DIR_VAR").unwrap_or_else(|_| "/etc/foo/".to_string());

I very much prefer expliciness.

@FransVeldman@fediverse.thefloatinglab.world mijn reden is dat die eindeloze frustratie en tijd veel effectiever ingezet kan worden om de wereld te veranderen. Een Instagram account bereikt veel meer demonstranten. Een whatsapp groep om gereedschap te delen, makkelijker om mensen aan boord te krijgen. Ik ben misschien wat negatief en cynisch. Maar dat krijg je van al dat gevecht met self hosted projecten, denk ik 😉

@FransVeldman@fediverse.thefloatinglab.world oh, hetzelfde hoor. Maar "gewoon €3/maand en een vinkje in Android" en al mn foto's, videos, netjes gesynchroniseerd, gebackupt, gecategoriseerd. Daar kan geen nextcloud tegenop.

@FransVeldman@fediverse.thefloatinglab.world sorry, nee, inderdaad. Mijn reactie was vooral bedoeld om je te voorzien van wat antimaterie. Het is mooi om zes enthousiaste vrijwilligers te vinden met verhalen over n plek, maar -IMO- mooier om één ex-vrijwilliger te spreken met gal over die plek. Geweldig dat je dit oppakt. Echt. Ik hoop dat jij t volhoudt en mij over zestien jaar spreekt om mn ongelijk er nog extra in te wrijven. Oprecht. 👍

@Xavier@infosec.exchange I know this. And I disagree about your TCO. I'm helping a friend with a $2500 computer, that uses approx $90 of electricity a month to run models which are inferior to those that I can rent off Mistral for about $40/month. And those are inferior - though not so much in practice - to frontier models like Opus which are impossible to host yourself, both technically and legally. When I runf Devstral2 on rented machines (hourly billed GPU VPSes) I can get comparable window sizes to that $40/month hosted version for about $800/month, provided I carefully engineer provisioning that bring the VPS down when unused. And I haven't then counted the hours tuning, deploying, monitoring etc that. Which could easily be another $1000/month. I then calculated the $/token or $/month for hosted models that in features/capabilities compare to the one in the $2500 computer at $90/month and it would've cost us under $5/month for the same usage. In other words: running models that are practically comparable to what's offered at $/token or $/month online currently costs way more than that. This obv. ignores all the other benefits of running yourself! I only look at the economics here, which, I know and admit, is too narrow.

@tomw@mastodon.social, have you considered software architectures that adress this problem? My domains too are messy, fluid, and ambiguous. Aren't all? So I use #ddd to model this domain. Then anti-corruption layers to put the most ugly parts, or uninteresting (and their libraries and frameworks) behind curtains, to keep all that abay. Hexagonal architecture to abstract these layers. And events to bind everything together. @silasmariner@hostux.social

@tomw@mastodon.social @silasmariner@hostux.social I guess I should have clarified "mess" better. If I make, say, an invoice parsing tool, as an HTTP service that stores events and sends emails, then "everything about invoicing and it's parsing", all its messy and real world constraints are put front and center. But HTTP, emailing, persistence? Way messier, but utterly uninteresting to the domain of invoices or the domain of parsing. Boring details. So those are put out of sight. Abstracted away.