Web sites do not; the static web technologies allow basically any styling, and browsing any content your browser can handle, and HTML forms work fine. In any case, many people who need to access the web site can't run modern JavaScript. So it should work without that.
There may be special dynamic enhancements that require JavaScript, but the site should so its core job flawlessly, without any JavaScript.
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.
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.)
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.
Most of the music I enjoy listening to, has good singing and/or lyrics that I want to hear. But this is exactly what I don't need while attempting to concentrate on another task!
When I need to focus on something, the music needs to be motivating, blocking out any ambient noise, but not distracting. I find trance and other techno to be best for this.
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.
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.
INTERCAL's main advantage over other programming languages is its strict simplicity. It has few capabilities, and thus there are few restrictions to be kept in mind. […]
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.
No. If an established dev leans on LLMs for coding and shovels it into the main branch, they have abdicated their responsibility and trashed their reputation. We get to point that out
Either we get him more resources or we STFU about the retired dev using AI. We can’t have it both ways.
Of course we can do both. I don't have those resources to grant
and I get to point out that Tridge, despite his well earned reputation from the huge contribution of creating rsync and bringing it to the point where it's effectively complete as an essential piece of internet infrastructure, was massively arrogant in abdicating his responsibility by shovelling LLM slop into that same piece of infrastructure.
Passkeys are a potentially good technology, that is frequently implemented in an insecure and user-hostile way.
Good: a standard way for authentication that can be implemented in common on client and server, such that the user doesn't need to know a secret.
Bad: Most OS and platform vendors breathlessly implemented this standard using their proprietary APIs and making it practically infeasible (read: impossible for typical end-users, therefore they won't, therefore insecure) to attempt syncing your passkeys outside their walled garden.
It is entirely feasible to implement passkeys in a way that users are in control and can freely move between devices and operating systems. But many implementations make that impossible, while still calling their implementation “passkey”.
So, we need to reject any implementation which puts any barrier to the user freely migrating and syncing all their devices regardless of platform.
Plenty of web clients allow the user to turn off JavaScript. Which is a good safety and security measure.
If a web site breaks without JavaScript, that's the fault of the web site designers and implementers.
I'd love to. Sadly, when I do leave JavaScript alone, too many web sites that should work fine just break.
Web applications need JavaScript.
Web sites do not; the static web technologies allow basically any styling, and browsing any content your browser can handle, and HTML forms work fine. In any case, many people who need to access the web site can't run modern JavaScript. So it should work without that.
There may be special dynamic enhancements that require JavaScript, but the site should so its core job flawlessly, without any JavaScript.
Would you improve the summary text, so that it says specifically what Ember is?
A good example is this post about FireDragon. The summary text says not only the news, but also what the heck FireDragon is, specifically.
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.
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.
Most of the music I enjoy listening to, has good singing and/or lyrics that I want to hear. But this is exactly what I don't need while attempting to concentrate on another task!
When I need to focus on something, the music needs to be motivating, blocking out any ambient noise, but not distracting. I find trance and other techno to be best for this.
I'm happy with Debian, yes.
You may be interested in the deliberations Debian has had earlier this year on exactly what should be permitted or banned with regard to contributions generated by bots.
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.
Answered in another reply.
Please put in the effort to write (in the post) a synposis of what you're linking to, and why you think it's worth visiting, before we go there.
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.
INTERCAL has entered the chat:
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.
No. If an established dev leans on LLMs for coding and shovels it into the main branch, they have abdicated their responsibility and trashed their reputation. We get to point that out
without any obligation to do their work for them.
Of course we can do both. I don't have those resources to grant
and I get to point out that Tridge, despite his well earned reputation from the huge contribution of creating rsync and bringing it to the point where it's effectively complete as an essential piece of internet infrastructure, was massively arrogant in abdicating his responsibility by shovelling LLM slop into that same piece of infrastructure.
—Groucho Marx
Passkeys are a potentially good technology, that is frequently implemented in an insecure and user-hostile way.
Good: a standard way for authentication that can be implemented in common on client and server, such that the user doesn't need to know a secret.
Bad: Most OS and platform vendors breathlessly implemented this standard using their proprietary APIs and making it practically infeasible (read: impossible for typical end-users, therefore they won't, therefore insecure) to attempt syncing your passkeys outside their walled garden.
It is entirely feasible to implement passkeys in a way that users are in control and can freely move between devices and operating systems. But many implementations make that impossible, while still calling their implementation “passkey”.
So, we need to reject any implementation which puts any barrier to the user freely migrating and syncing all their devices regardless of platform.
Of course, that works only when everyone's in the same room. I don't have a good replacement for teams that connect remotely.