[–] 1 point 3 months ago*

you’ll still have AI like you do today

A great many people today use only the proprietary, software-as-a-service providers for their LLMs, diffusion models, etc., and those services are indisputably costing far more to provide, than the revenue gained from users. They are funded to ridiculous levels by investment from funders who haven't yet figured out they will not be getting paid.

That kind of service will not survive the bursting of the current hyperscaler bubble. We will not have today's low-priced access to (and therefore we will not have shoved down our throat, in every application and device and online service, at low cost) the gargantuan resource-guzzling data centres, because the hyperscalers will not be keeping those operating when their investment funds dry up.

  • source
  • parent
  • context
  • [–] 2 points 3 months ago* (last edited 3 months ago) (1 child)

    Not just you. For more than a quarter century, we've known that if a paragraph's text lines sprawl across a wide screen, it's more difficult for most people to read. (And the same is true if the lines are too short. There's an optimal range.)

    https://jamesmattison.co.uk/method/why-line-length-matters-for-legibility/

    For this reason, it's good for a website's style rules to limit how wide (measured in characters) a column of text can get, regardless of how much screen there is to expand into.

  • source
  • parent
  • context
  • [–] 5 points 4 months ago* (last edited 4 months ago)

    Simply saying “No AI” would forbid a huge amount of code that was written with assistive technologies that long precede the latest crop of proprietary LLMs; I'd venture it would cover almost all software in distributions for the past several decades.

    “AI” is a marketing term, in continuous use from the mid-twentieth century to encompass a broad and ever-changing range of automation and other tools, that is deliberately vague. If we want to be clear what the ban does and does not cover, we need to avoid that term.

    And then of course we can deliberate on exactly what is permitted (code that was auto-corrected by a spell checker? code that had its boilerplate syntax automatically generated?) versus what is forbidden (code that was generated in some proprietary data centre? code that is an unattributable, non-consensual remix of existing code? code that was probabilistically extruded from an LLM?), because we'll avoid the useless term “AI” and instead speak of specific tools and technologies.

  • source
  • [–] 4 points 5 months ago

    The main argument, and it's a strong one, is: YAGNI (You Ain't Gonna Need It).

    Compared to defining a function as synchronous (the default), there is a significant cost to defining a function to be async: Its signature is different, therefore every caller to that interface must also be aware the function is async; test cases must handle not just a simple return value, but a Promise; etc. etc.

    So, don't impose that cost unless you already know it's needed, today. If you don't need it today, the most likely expectation is You Ain't Gonna Need It, at least not any time soon. So don't pay the cost now for something you likely won't get a benefit from.

  • source
  • [–] 19 points 5 months ago*

    I donate to a number of free-software projects via https://liberapay.com/ which lets me control the individual donation amounts and frequencies, and pay from a single account that I top up periodically.

    When approached about allowing me to donate to them via Liberapay, I've had several people respond positively and set up their end of the deal. It often just takes a friendly conversation.

  • source
  • view more: ‹ prev next ›