not a big fan of all music streaming services, but they only keep about 30% of their revenue. the rest goes to the labels, and this is where most of the problem is. before the 2000s, very small artists hardly earned any income from the sale of (physical) media. I don't like the new platforms such as Spotify, Tidal, etc. either – but this kind of discussion often just distracts from the mafia-like structure of the major labels.

Comments URL: https://news.ycombinator.com/item?id=46109867

Points: 5

# Comments: 1

since reading on twitter is annoying with all the popups: https://archive.is/ETVQ0

I am always amazed that many of these things (Unix, C, IP, Ethernet) were developed in the 70s/80s and are still relevant, useful and today. At that time, people also had a technical interest in developing software and had to deal with very limited resources, maybe this is no longer the case in many cases today

i am helping maintain a big automation system for a customer which is generates several million in sales per year and is built just with simple unix tools, perl, mqtt, nginx - a very low tech stack - running on a small 2 core machine.

the cloud-based solution that existed before had enormous performance problems, ran unreliably, was difficult to debug and was several times more expensive in terms of both development and running costs

bandwidth is super cheap if you dont use any fancy public cloud services.

Of course I can understand if someone finds the situation stupid. However, ICANN is clear with its rules and every entrepreneur has to take possible (political) uncertainties into account when choosing a .tld, which many have simply not done. You could also accuse them of "incompetence".

When choosing a domain for .de, I explicitly decided against a podcast bro tld like .io / .ai etc. because of these reasons.

Most of the time I make mistakes out of ignorance or lack of experience. Unfortunately, there is no tool for this. But it's good to think about how (technical) things work in everyday life and to take a look at the theory in a dry way This can be books, wikipedia or listen to what pepole from the the peak days of software development says (something before 2005)