If a piece of art is “good” who cares where it came from? The “where it came from” is as integral to the “quality” of the art as the “art” itself.
This is a very “product” mindset, concerned with the end result and how it serves you. Myself, and many others, are not as concerned with that or they may be against AI for other ethical or environmental reasons.
The take you’re giving presupposes that the utility of the end result is the only axis upon which to judge something.
In the universe where the “where it came from” can’t affect the end quality, the question itself indeed becomes irrelevant. And in case of the Linux kernel it is indeed irrelevant, as the code will be reviewed, appraised and tested before releasing.
And yes, the utilitary mindset is more applicable towards code than it is to art. Unless we’re talking about stuff like ioccc, where the code itself is the form of art, code is just a mean, not the end.
You can see my other posts in this same thread but I think you are taking that claim as a given. If I’m judging two pieces of software, why should I only use utility to my needs as the axis upon which I judge them? Why is that ontologically the correct method of judgement?
Why shouldn’t I treat alignment with my values, the degree to which the code fostered a community that was pro-social, or the beauty of the code as the means by which I judge the code?
Because the main utility of Art is to be observed. The main utility of code is to be compiled into a piece of software.
Why shouldn’t I treat alignment with my values, the degree to which the code fostered a community that was pro-social, or the beauty of the code […]
I never said you shouldn’t. Just that it’s secondary to code’s functionality. Also, specifically in case of the Linux kernel, the community and its values stay the same. All that changed is a clause in the rules.
Again, and I brought up more details elsewhere in this thread. This is assuming utility as the principal axis. You highlighting art as having a utility "to be observed* is more of this neo-liberal hyper optimization psychology.
I am awash in projects that compile. Frankly, for most use cases, getting the code to compile is a pretty easy step. But all those other axis? Those are much tougher.
So, yes, “does it compile and run” is generally table stakes as I can’t interact much with the code without that step. However, comparing it to art, that is functionally the equivalent to “is it visible to a human somehow” as far as requirements to be considered art.
Because of this, the utility of code, that is “does it serve my needs”, is not the principal axis by which to judge it for me. It is just one of many axis’ that are used to judge.
This isn’t limited to code by the way. Every field, and every technology, gets this treatment. It is simply not enough to make a product that does a task. I’m looking for conviviality.
You see, it is the principled axis though. Let me paint an analogy: suppose, you’re very thirsty, but there’s no water to be found. You see chips, dried fruit, cakes, biscuits, but no water. Would you really care about how ethically all of those were sourced, how nice they are, or how much the cook loved to make them? If someone started to tell you all of this snacks’n’deserts lore while you were literally dying of thirst, you’d most probably become very irritated, because all of those beautiful snacks and desserts is not what you need right now. What you need is water, and hour by hour you’re starting to care less and less about how muddy it should be, or where it comes from.
What I’m saying is, when a certain niche is overflowing with various pieces, it might seem like utility is not primary, but the opposite becomes really apparent as soon as there’s nothing to fill in that said niche. The rest is just a privilege that we all have, thanks to the abundance of literally everything that we live in. I too have the privilege to avoid projects written in Python, simply because i have a personal preference against it, or to avoid shady vibe-coded slop. With linux kernel tho? I mean, if someone clones it, and does a better job at not letting bugs into production, while releasing at the same pace or quicker than the current kernel project does, i’ll switch to it too. Except i doubt somebody could compete with a team of seasoned vets, that know how to use their tools and can with ~95% accuracy tell which parts of code would break at a first glance. Until then, i’ll stay on vanilla linux kernel, because it does its job of keeping my pc functional, which i need to win some bread.
Your analogy adds a condition for need that my framework does not presuppose and, because of that, I feel it is a weak analogy.
My entire argument is that value is judged against a wide host of different axis. Do I have a literal deathly need for a drawing app to support Gaussian dithering? Like, will I die of that isn’t present? No. Obviously in a life or death situation we select the object which will most rapidly and most effectively meet our need. Though even under those circumstances there are limits a lá trolley problems.
On to your main point as to the value of non-utility features inside of an underserved niche. That really depends on the niche doesn’t it? If the niche is LoRa communication networks in disaster environments than perhaps I am more willing to tolerate something churned out by an LLM until something better comes along but if the niche is not human life preservation than it’s not dire enough to justify compromising on the other things I care about.
A more accurate anology that you might have asked me is "if you really wanted a croissant and you had the choice between a delicious croissant made with forced child labor, no croissant, or a pan é chocolat would you really not choose the croissant?
To which my response is “Yes, I would pick something else”.
My entire argument is that value is judged against a wide host of different axis.
And you continue to fail to see that I have never said otherwise. There is a certain logical leap between “this is the only factor that matters” and “this is objectively the main factor, but we have the luxury to not care about it because we live in a post-scarcity environment”. You can afford to not choose the croissant because you know there’s other food to choose from, and more over, that there are other croissants just like this one, but with no child labor inside.
On to your main point as to the value of non-utility features […]
There’s no such thing as “non-utility feature”. But there’s the order of importance of factors, which is, of course, subjective and highly-cotextual. If you personally value the fact that a given software was written without the use of LLMs, than its functionality, because you somehow deem it as “more moral”, you’re free to stay on the outdated kernel, or switch over to NetBSD. I guess that’s the part of our discussion where you explain to me why you think using LLMs in an opensource non-profit collaborative project with the given rule that the person who submits the code is still fully responsible for it and should be able to answer any technical question regarding it is wrong.
Completely this.
As long as the code is good,. does it matter where it came from?
Yes.
If a piece of art is “good” who cares where it came from? The “where it came from” is as integral to the “quality” of the art as the “art” itself.
This is a very “product” mindset, concerned with the end result and how it serves you. Myself, and many others, are not as concerned with that or they may be against AI for other ethical or environmental reasons.
The take you’re giving presupposes that the utility of the end result is the only axis upon which to judge something.
In the universe where the “where it came from” can’t affect the end quality, the question itself indeed becomes irrelevant. And in case of the Linux kernel it is indeed irrelevant, as the code will be reviewed, appraised and tested before releasing.
And yes, the utilitary mindset is more applicable towards code than it is to art. Unless we’re talking about stuff like ioccc, where the code itself is the form of art, code is just a mean, not the end.
Why is it more applicable to code than art?
You can see my other posts in this same thread but I think you are taking that claim as a given. If I’m judging two pieces of software, why should I only use utility to my needs as the axis upon which I judge them? Why is that ontologically the correct method of judgement?
Why shouldn’t I treat alignment with my values, the degree to which the code fostered a community that was pro-social, or the beauty of the code as the means by which I judge the code?
Because the main utility of Art is to be observed. The main utility of code is to be compiled into a piece of software.
I never said you shouldn’t. Just that it’s secondary to code’s functionality. Also, specifically in case of the Linux kernel, the community and its values stay the same. All that changed is a clause in the rules.
Again, and I brought up more details elsewhere in this thread. This is assuming utility as the principal axis. You highlighting art as having a utility "to be observed* is more of this neo-liberal hyper optimization psychology.
I am awash in projects that compile. Frankly, for most use cases, getting the code to compile is a pretty easy step. But all those other axis? Those are much tougher.
So, yes, “does it compile and run” is generally table stakes as I can’t interact much with the code without that step. However, comparing it to art, that is functionally the equivalent to “is it visible to a human somehow” as far as requirements to be considered art.
Because of this, the utility of code, that is “does it serve my needs”, is not the principal axis by which to judge it for me. It is just one of many axis’ that are used to judge.
This isn’t limited to code by the way. Every field, and every technology, gets this treatment. It is simply not enough to make a product that does a task. I’m looking for conviviality.
You see, it is the principled axis though. Let me paint an analogy: suppose, you’re very thirsty, but there’s no water to be found. You see chips, dried fruit, cakes, biscuits, but no water. Would you really care about how ethically all of those were sourced, how nice they are, or how much the cook loved to make them? If someone started to tell you all of this snacks’n’deserts lore while you were literally dying of thirst, you’d most probably become very irritated, because all of those beautiful snacks and desserts is not what you need right now. What you need is water, and hour by hour you’re starting to care less and less about how muddy it should be, or where it comes from.
What I’m saying is, when a certain niche is overflowing with various pieces, it might seem like utility is not primary, but the opposite becomes really apparent as soon as there’s nothing to fill in that said niche. The rest is just a privilege that we all have, thanks to the abundance of literally everything that we live in. I too have the privilege to avoid projects written in Python, simply because i have a personal preference against it, or to avoid shady vibe-coded slop. With linux kernel tho? I mean, if someone clones it, and does a better job at not letting bugs into production, while releasing at the same pace or quicker than the current kernel project does, i’ll switch to it too. Except i doubt somebody could compete with a team of seasoned vets, that know how to use their tools and can with ~95% accuracy tell which parts of code would break at a first glance. Until then, i’ll stay on vanilla linux kernel, because it does its job of keeping my pc functional, which i need to win some bread.
Your analogy adds a condition for need that my framework does not presuppose and, because of that, I feel it is a weak analogy.
My entire argument is that value is judged against a wide host of different axis. Do I have a literal deathly need for a drawing app to support Gaussian dithering? Like, will I die of that isn’t present? No. Obviously in a life or death situation we select the object which will most rapidly and most effectively meet our need. Though even under those circumstances there are limits a lá trolley problems.
On to your main point as to the value of non-utility features inside of an underserved niche. That really depends on the niche doesn’t it? If the niche is LoRa communication networks in disaster environments than perhaps I am more willing to tolerate something churned out by an LLM until something better comes along but if the niche is not human life preservation than it’s not dire enough to justify compromising on the other things I care about.
A more accurate anology that you might have asked me is "if you really wanted a croissant and you had the choice between a delicious croissant made with forced child labor, no croissant, or a pan é chocolat would you really not choose the croissant?
To which my response is “Yes, I would pick something else”.
And you continue to fail to see that I have never said otherwise. There is a certain logical leap between “this is the only factor that matters” and “this is objectively the main factor, but we have the luxury to not care about it because we live in a post-scarcity environment”. You can afford to not choose the croissant because you know there’s other food to choose from, and more over, that there are other croissants just like this one, but with no child labor inside.
There’s no such thing as “non-utility feature”. But there’s the order of importance of factors, which is, of course, subjective and highly-cotextual. If you personally value the fact that a given software was written without the use of LLMs, than its functionality, because you somehow deem it as “more moral”, you’re free to stay on the outdated kernel, or switch over to NetBSD. I guess that’s the part of our discussion where you explain to me why you think using LLMs in an opensource non-profit collaborative project with the given rule that the person who submits the code is still fully responsible for it and should be able to answer any technical question regarding it is wrong.