The meaning of copyright is changing as these images are being divorced from their physical medium.

It can be read that the film was found and sold - a practice that was probably fine when an image had a physical manifestation.

But yes, we are at juncture now with copyrights, as more and more things are virtual.

Now, can you justify your sentiment? Which was what I asked about?

(Or is it more fun to just cycle around in indifferent ontological ramblings?)

Answer to the edit:

I am not upset by the numbers. I am asking how you will ensure a society with equality and democracy under your proposed system.

In particular, taxes are an effective way to ensure equality - something that you are probably seeing in the numbers you refer.

In the US we see that trump is increasing taxes on consumers (Tariffs) while lifting taxes from the highest earners.

To cut to the core: I am asking if you are pro oligarchies? and if not, how do your propose that we ensure the equality needed to uphold a democracy?

First, you seems to conflate "free markets" (Whatever free means here?) with decentralized spending. How does that make sense?

And more importantly: If we can agree that a democracy ought to be an aspiration for a society, and a functioning democracy requires some minimum level of equality, how will you ensure that under your "free market"?

Maybe the difference, 16% points, is what affords the European a fair treatment upon illness where half of that is "shareholder value" in the US.

Feel free to link the study you used so we don't just have to trust some internet rando.

It is probably unrealistic to expect documentation to be complete as it is not clear where the border on inclusiveness goes.

Take eg. AWSs node packages. Here they spend words recommending using async / await which IMHO is firmly outside the scope of library docs.

I am curious on what you feel is missing? is it elements concrete to the piece of software you use, or is it pieces that can be deemed expected knowledge from a professional software developer.

It is all about risk.

FDA enables civilization to grow above a certain threshold.

Nobody really cares about you and your sandwich.

But whenever we introduce single point of risk into the society these needs to be managed.

Fair enough, you are personally responsible and don't eat the sandwich.

The rest of the US was not.

- at least you retain your right to claim "What did I say".

Anyways, one of the things about growing up is realizing that there is more to the world than just innovation.

There is a very easy way to get around such a requirement from legislation: Just call it licensing instead of a purchase.

The need for such a legislation is corporations reckless use of the words "purchase" and "buy" for goods that have been licensed.

The insurance premium is also entirely tax deductible and nowhere enough to cover the scheme - the scheme which is highly regulated, well, because the government pays for it.

Denmark has a 2.9% unemployment rate: https://www.dst.dk/en/Statistik/emner/arbejde-og-indkomst/be...

I don't entirely know how that compare to the US.

I also agree, that the author probably not meant to establish an axiom: The axiom being established, while not having any support right now, does seem like something we can reduce in the future. The author also uses the word "currently" in their axiom, which contradicts axioms (or is temporal axioms a thing?).

I think the author merely meant to establish the scene for the article. Something I truly appreciate.

> If you believe LLM have qualia, you also believe a ...

You use the word believe twice here. I am actively not talking about beliefs.

I just realise, that the author indeed gave themselves an out:

> ... currently computers do not really understand words.

The author might believe that future computers can understand words. This is interesting. Questions being _what_ needs to be in order for them to understand? Could that be an emergent feature of current architectures? That would also contradict large parts of the article.

Firstly, do understand that I am not saying that LLMs (or ChatGPT) do understand.

I am merely saying that we don't have any sound frameworks to assess it.

For the rest of your rant: I definitely see that you don't derive any value from ChatGPT. As such I really hope you are not paying for it - or wasting your time on it. What other people decide to spend their money on is really their business. I don't think any normal functioning people have the expectation that a real person is answering them when they use ChatGPT - as such it is hardly a fraud.

        First we must lay down certain axioms (smart word for the common sense/ground rules we all agree upon and accept as true).
        
        One of such would be the fact that currently computers do not really understand words. ...

For articles like this to be interesting, this can not be accepted as an axiom. It's justification is what's interesting,

If you have a list of maximally 10 elements that needs to be sorted and you opt for quicksort over bubble sort in a context where bubble sorts time/space guarantees perfectly solved the requirements, well, then you absolutely wrote bad code.

This is what a more senior developer understands, where a junior would jump in and write worse code.

> What they really mean is that good programmers should think ahead and craft their code with an eye minimizing future modifications.

The critique is exactly that this can not happen in real world projects because you can only speculate what requirements for the code base is down the road.

To counter this I usually apply two princinples:

1. Occam's razor - implement the simplest solution

2. Write code that is readable and understandable, so it is easier to change the code with the requirements.

The last being completely opposite to what the author of the article thinks.

The worst thing I can think of is somebody needlessly DRYing up a code base prematurely - this is in my opinion a junior behavior.

The reason why good code is code that is easy to read, is because products evolve, and so does the code.

Suddenly the taxonomy of that enum starts to shift, and the name that was perfect yesterday does not make sense tomorrow.

These changes happen gradually and a basic acceptance of the code base not being on par with the product understanding is necessary in order to have any kind of velocity on not only spend time refactoring.