if you’re apolitical, no you’re not
you can (probably) have my matrix if you dm me
i don’t disagree with you on the first half very broadly but that’s a pretty deeply reductionist and apathetic way to look at it.
we can both identify what is likely given current incentives and then work to avoid those outcomes if they aren’t desirable.
i don’t find the lack of people remembering phone numbers or keeping maps in their cars undesirable.
i do find a swerve into long term unmaintainability for many new (and some existing) foss projects undesirable.
nope. apologies but you have stepped on a pet peeve of mine.
the slippery slope fallacy is someone saying: don’t allow a1 because if we allow a1 then a2 will happen and we don’t want a2 so we must prohibit a1.
the slippery slope fallacy is not someone saying: a naturally trends towards a2 and a2 would be a problem so we should avoid passing a*2.
for example, the slippery slope fallacy was committed when people used to say that letting consenting adults legally marry each other would inevitably lead to people legally marrying animals. it is not committed when, for example, people say that americans should at some point put a limit on how big their trucks are getting since the short term incentives all push in that direction despite the fact that more and more people keep dying. do you understand?
saying that it is easy to slip further and further into leaning on llms in the way i described is both observably true and actively what the companies selling the product (with all of their vast resources) are aiming to achieve. that is the [if the short term incentives will foreseeable move us from a to a2] part of this. the other part of this is that i believe that a future where projects are truly vibe coded (no human reviewing the code) is not one where that software is maintained in the long term [a2 isn’t desirable] and it seems you agree on that part.
i am not saying that if people follow the short term incentives and move towards using llms more that next they will ‘get lazy’ (to use your word) with cooking too and start putting too much salt and oil in their food to try to quickly make it taste better. not a1 -> a2 but a -> a*2 -> a2. not only that but also i am not calling for banning generative ai at all. i am saying that because a2 is undesirable let’s stop at a*2 (“…/truly/ checking the output the same way [we] would scrutinize [code written by an intern we don’t trust].”) because that is the point that i believe delineates (broadly) positive vs negative outcomes in the long term.
all of that to say, even if you don’t agree with me on generative ai, i hope you now know how to correctly identify that fallacy in the future.
my concern isn’t “laziness” - it’s that i want software that is maintainable over something flashy that will be rotting in a year
someone who knows what they are doing using autocomplete is fine in my opinion if that is truly how it is being used. the problem is that once you accept an llm writing the rest of a line of boiler plate for you it is a short step into it writing a function body for you which i trust far less.
it is easy to just accept llm content as ‘good enough’ and become lulled into not thinking critically about the security and performance implications of the code it is popping out. /if/ humans who know what they are doing are /truly/ checking the output the same way they would scrutinize an intern they don’t trust’s code then… sure. we should be serious though about the fact that that is neither what the ai companies are incentivizing nor what they are advertising.
all of that aside, my most pragmatic concern is that projects slapped together with meaningful llm aid usually are not - in practice - maintained for long unless they were already a well maintained project pre-llm mass adoption. checking a repo for something shiny and new and finding that claude is a contributor is, in my experienced, /very/ tightly correlated with finding that /every single/ top level file/directory was last changed as part of the same commit n number of months ago (n > 2).
part of why i pick and use the tools i use is because i have /some/ confidence that i won’t have to drop them and deal with identifying (and then working through the hassle of sidegrading to) a new tool for that task every ~6 months. i would hate to see long maintained projects i use, or even cool new projects i follow, hamstring their maintainability in the medium and long term in exchange for a burst of speed in the short term.
for sure, but limiting it under 64 (the length of a sha256 hash) isn’t ideal at all
the vast majority of mine are +50 characters - you are just wrong. the services which strictly limit the length are rare and their security is suspect since they should be hashing your input anyway
sure, that’s true, but if we are being serious do you think software made nearly exclusively by a human (or humans) who care or software made mostly by a non-deterministic token generator working on behalf of a human who couldn’t bother to write the code themself is more likely to be maintained long enough to gain community trust
do you understand what an analogy is?
i don’t think llm content is cheating; i think it’s usually garbage and that slop projects are very rarely maintained for more than a few months
if people want to risk it they can risk it if they want i just want it labeled or in a separate category so i don’t have to waste my own time
i just find the argument that it is impossible to tell something 100% means you shouldn’t bother deeply suspect since we don’t apply that to other things we care about
that’s like saying that because we can’t all always 100% tell if someone is cheating at an online game we should forget about banning cheaters - you can prohibit a behavior you aren’t always able to sus out and use a combination of detection heuristics and making that behavior unwelcome (i will say i believe the correct policy is to label projects which discernibly use llms rather than banning them)
even the people over on hacker news concede that they are unusably buggy so… i think vibe coded slop is vibe coded slop - use gimp
i don’t disagree with /that/ but i think picking a sensible, truly non-corporate distro as your base is important: hence debian as a truly solid option (or arch if you want rolling release)
that’s terrible advice. distro != desktop environment
if you are from windows i would suggest using kde as your desktop environment, at least to start, regardless of which distro you pick
people like to joke about arch being hard but that’s mostly just a holdover from installing it being a chore that required a lot of careful manual reading - just use the built in archinstall and it’s straightforward while also being a breeze to customize how you want
once you run archinstall and have arch installed it isn’t any different than any other rolling release distro in difficulty - just use timeshift (or an equivalent, if you know enough already to pick one) in case you need to roll back an update in the future easily
the advantage is having easy access to the most recent versions of all your software all the time - just, if you use the aur for the additional community managed packages outside the official packages you admittedly need to learn to read the package files to make sure they aren’t doing anything funny but otherwise you can just get software you trust the way that the developers recommend
if that all sounds overwhelming instead of exciting, just use debian
start with debian if you want a stable release update style or arch if you want a rolling release update style
the vast majority of other distros are just nonsense stacked on top of one of those two
most of the big distros that isn’t true for are corporate (open suse, fedora, etc.) and should be avoided unless you have a pressing and specific reason
save yourself a headache and just start with debian or arch. what you learn with one of those two will be the most transferrable and they both have huge (comparatively) communities with well developed resources for learning and troubleshooting.
why assume the attacker is a guy?
i switched to ivpn, personally
i would highly recommend ivpn
(recommended by privacyguides.org)
human code of /course/ can have vulnerabilities; there is no need to be black and white about it, auli
if for some reason i had to trust my bank details with either a program written by a human who cared enough to write it or a fully vibe coded (human didn’t even /glance/ at the code) program i wouldn’t find the choice between those options difficult, would you?