That is not the point I was making.

Yes, and no.

The Linux kernel has one key difference. At its core, it is a reimplementation of the Unix/POSIX system design, based upon several decades of prior art in both design and implementation. This has meant that while the developers are certainly talented and hard-working, for the most part they have not been undertaking complex original design. They are reimplementing a system which is well understood and which has already been implemented several times over.

When it comes to greenfield development needing detailed requirements, design specifications, implementation, testing and iterative rework, I suspect that in-person collaboration comes more into its own.

Note that we can see this even within the Linux kernel. While they have done a pretty good job reimplementing the classic interfaces, this cannot be said of the newer features which have been done from scratch. A lot of the newer features like cgroups, epoll, btrfs, and such are individually functional but can interact badly. Each feature has been developed in isolation without consideration for the implications (e.g. security implications) of its integration into the wider system, and I think the disconnected mode of development is partly responsible for this. Contrast with in-person interactions, and a lot of design flaws and limitations might have been shaken out very early on with some immediate critical feedback.

The other aspect to consider is that if you make the assumption that Linux developers are a set of self-selected high-performing experts, they are uniquely capable of operating in a disconnected fashion. If you look at the spread of experience, capabilities and performance in a typical company, it's quite clear that not everyone is suited to working completely independently. Many people need in-person interactions to keep them focussed, on-track, motivated and productive.

The Linux developers had the luxury of skipping the design and jumping straight into the fun stuff: coding and implementation. But look at Btrfs as a single example. They started coding before the design was final, then iterated on the design several times requiring costly and buggy revising of the code, then froze the on-disc format before the design was ready for that, and are now stuck in a tarpit of their own making where they are unable to fix all the design mistakes and are in a purgatory of endless bugfixing of the mess they created. Contrast with ZFS where the design was formalised and validated by a small team of experts before any coding started. And it worked without serious dataloss since day one. I do believe that the in-person approach has a lot of value.

I don't think I'll lose any sleep over this (I live on the coast near Dundee). Of all the potential problems we have to worry about, having our homes devastated by a tsunami are so low on the list they are barely worth mentioning.

Err, the userland is from FreeBSD. It's all BSD-licensed. The only bits that weren't were things like the bash shell (now zsh by default) and the GNU toolchain (now LLVM). I think you can make that argument for some specific GPL-licensed parts, but the vast majority is BSD, and for those parts the argument doesn't hold up. They had nothing restricting them from updating this stuff, but they chose to let it stagnate.

You aren't describing "reusing", you are describing "recycling".

When bottles are genuinely reused, they are usually picked up by the company that owns them. When they deliver crates of new filled bottles to shops, businesses, homes etc., they will collect the empties. They will go directly back to the bottling plant for cleaning and refilling. For homes and businesses, they can be returned directly. For shops, the customer will have to return them, possibly for a return deposit. All this can work cheaply, simply, and smoothly. And did for years before we moved over to plastic.

It's "consumer-grade UNIX" at best. The userland is around 12 years out of date. Not sure why you got downvoted, that's trivial to verify. Just look at the dates on each tool. It varies, but most of it has remained untouched, and compared with a current FreeBSD or Linux system, it's missing all of the bugfixes, new command-line options and features developed since then. Its compatibility and interoperability with other UNIX systems has been compromised as a result. It's all too common to have to special-case MacOS because it's missing trivial options. Like "readlink -f".

It's a shame because you're absolutely correct that in the early days of MacOS X, its UNIX base was a big selling point. But that clearly hasn't been a priority for quite a number of years.

https://en.wikipedia.org/wiki/...

Get people hooked, and then extract money with microtransactions.

What's old is new again. They are calling it "DLC" nowadays.

Computers are our slaves. They are told to perform tasks, and they obey their instructions to the letter, uncomplainingly and without recompense. They are also not human or even alive, and the terminology used here has no bearing upon real-life slavery. They are dumb machines which do the jobs they are told do.

For IDE you might have a point (I'm not familiar enough to comment). For other buses, e.g. I2C or SPI there is a very clear difference between the master, which issues commands, and the slave which acts upon the command and provides a response. We could get all worked up about the "bad" terminology in use here, but I really struggle to see it as a problem of any particular significance. There are far more important (and genuine) problems in the world more worthy of our attention. These are non-problems created by overprivileged people with far too much time on their hands, very little brain, and no real purpose in life other than to cause unnecessary trouble for others. Will the world be a better place if we waste tens of thousands of man-hours to erase a bit of engineering history? Not one little bit. Will any real-world slavery be stopped, or any residual trauma from people with slavery in their families past be eased? Not at all. The only people benefitting here are the SJWs who revel in wielding their capricious and arbitrary power over others in the name of virtue. They are bullies, and not nice people at all.

This is an incorrect understanding of what "master" means. A "master copy" does not mean immutable. It means it's the primary and authoritative source of record, from which all other copies and versions are derived. It does not, and never has, meant an immutable and final form. It might be used to mean that in the audio world, but that's not what the rest of the world uses the term to mean. The way it is used in git is perfectly standard, and has been used in this context in business terminology the world over for centuries.

Err, yes it does. "Blacklist" came from banking where customers who were debtors who defaulted on their loans were recorded on a list with a black border. A literal "black list". It has nothing to with skin colour. It's still used in the banking world today, albeit no longer in physical form. It is a means for accepting or rejecting future business with a particular person, and so it is quite natural to adopt the same naming conventions for dealing with network packets. After all, the "blacklist" terminology long escaped the banking world into the common vernacular and is use for all sorts of diverse purposes today.

It's stuff like this that makes it impossible to take virtue-signalling SJWs seriously. They disrupt our lives for things which make zero improvement to the world we inhabit. If "blacklists" were historical tools for racial oppression of people with black skin, they might have a point. But there is no basis in historical fact for making these changes. They achieve nothing and are utterly pointless.

Not just in the US, I see it in UK acadaemia as well. There are millions of pounds for funding shiny new equipment. But funding the ongoing running costs, consumables, maintenance, technical support staff and the like? Not so much. So you end up with huge capital expenditures going to waste or being underutilised, not because there is any fault with the kit, but because there's no dedicated staff to maintain and support it, train people to use it, and pay for the ongoing running costs. I've worked in some places that do a very good job, but in other places there's prestige to be gained by getting the funding to buy the biggest and shiniest toy with all the extra knobs on. But the people who get the funding and do the purchasing are rarely the people who actually have to use the kit, the actual requirements often come second. In many cases, making do with something a quarter of the price would do the job just as well, and be much more affordable when bits need replacing. Hell, buy two up front and still have half the cash left over for consumables and staffing. Unfortunately, funding and budgeting is insane and makes no sense, and many of the people involved aren't even sufficiently competent to run their own household budgets.

Arecibo is a great shame, but I think it's fair to say it's had a good long run, and would have had to be decommissioned at some point. After the damage that's been inflicted and the generally poor state it's in now, it may well be much cheaper to start over than repair it. Assuming there's still a demand for it, hopefully there will be the possibility for a new one to be built again in the future. But you are likely to be completely correct that had it been funded properly, routine maintenance should have prevented the problems from happening in the first place.

Absolutely. Linux is slowly but surely losing the main selling points which led to its initial adoption and success. Being that it was an open Unix-like system which was adaptable to meet any purpose. A key part of that was being simple and understandable by anyone who cared to look at it. With that gone, it's just as opaque and unpredictable as Windows, but with the added disadvantage of having poorer hardware support. It's now on a par with Windows in terms of reliability, so I got to the point where I switched back to Windows after 20 years and run Linux in a VM as needed.

The main problem here is that when Linux was first developed it simply had to copy pre-existing designs. Be that POSIX, BSD, Solaris, X11, even Windows. The design work was basically done, and the primary task was reimplementation. Implementing stuff is fun and absolutely of merit, but it's a lot simpler than design work. The new stuff, most of freedesktop's work, lacks the good design of the components it replaces, and in many cases doesn't take into account the state of the art and ends up being regressive. D-BUS, for example. Intended for desktop use, now crept into systemd at the heart of the system. Not only is it not specified very well, there were and are alternative IPC libraries and tools which are hands down better, but weren't considered. The quality of the design and implementation is what's letting us all down here. And due to the political battles which have been fought and won, we basically have to take it or leave it. I chose to leave, and now use FreeBSD in preference to Linux. Not perfect, and certainly not totally immune to all the brain damage, but still better than what Linux has chosen to become for the time being.

I found another annoyance this week. If I use remote desktop to connect to a Win10 system with a fullHD display, and I'm using a nice 4K display, it scales everything up, and it looks really nice. But if I disconnect and then go to the other system to use it directly, all the applications retain the scaling, and everything is massive with no way to revert it back to the original scaling for the fullHD display. Not the end of the world, but it's just another weird scaling defect.

No... you haven't actually read the question. The GPL is a *distribution licence* and the point you linked to is about *distributing* a combined work of GPL and non-GPL code. It is not an end use licence and does not cover what you can do on your own system. Stop the ranting for a moment, and think about it...