Re: The problem is ...
It always seems to me that the live version isn't as performant as it could be. YMMV.
42400 publicly visible posts • joined 16 Jun 2014
Forget the experimental and enthusiast distros. There are a small handful of desktop distros and a small handful of server distros.
If you want to experiment with a desktop Linux distro for a couple fo days, do you know how much it will cost you? A couple of days of your time. You don't even need another computer to test it on providing you've got one with enough disk to spare to install it dual boot.
You could even try a couple of distros. See what the differences are and realise how similar they are. Discover that it's not so much a matter of vast differences, more a question of finding where you feel most comfortable, rather like deciding on your favourite pub.
Try it. It doesn't hurt. You can keep it a secret if you don't want anybody to know that you have.
What amazes me is the number of people who call themselves IT professionals who haven't even tried, as professional development, something that won't cost them money.
We keep hearing this bit about applications. Yes, of course we run an OS to run applications. I certainly d. But do you really want applications where the vendor is persistently trying to inveigle you into subscriptions for what you're already running, or run them on their servers with your data a their mercy, or busy shoehorning AI into all those applcations?
When is enough enough?
"There are sometimes mismatches between the amount of electricity generated in a certain region and the electricity grid's ability to transmit that electricity from that region to another,"
Meanwhile, the data centre, whose effectiveness is being measured in inputs rather than outputs, is steadily eating a fixed amount of the generation which is then not available for transmission to the rest of the customer base, even if the generation falls below transmission capacity. At the extreme we'll hear about DCs unable to operate at low generation levels because transmission capacity isn't adequate to suck in power from the rest of the grid.
You're looking at it from the wrong end og the telescope. The people who are interested in this are not those looking to install the newest shiny. They are people who need to run something developed for that platform and which is performing a critical function not easily replaced. Are they going to take the risk of asking will it run on the latest version of libxml2, let alone the latest version of Python?
They probably don't even want any patches or for it to be "slightly" upgraded. They're paying the money because some fiat says the platform must be "supported" and the reality is that it has to stay just as it is, doing just the job it was installed to do, no more and certainly no less.
What about some very expensive piece of equipment, something so expensive it was scheduled to be amortised over a couple of decades? Something whose drivers were written over a decade ago by a vendor long closed down. In tha sort of environment issues are not going to be solved by new versions of the OS, they're going to be created by them.
Now imagine you're about to purchase s new piece of equipment of that nature. Would you want its controlling S/W to run on an OS whose vendor is not only promising such longevity but visibly delivering it on their earlier versions or would you want it to run on Windows?
"if it's a regulated environment"
This is surely the key to it. Regulated environments that require applications to be certified and the applications themselves are only certified to run on a specific platform. Just the sort of environment that doesn't sit well with forced upgrades.
1. $Topic was introduced (too long to go into detail here)
2. $Topic was explained (too long to go into detail here)
3. Explanation was summarised (too long to go into detail here)
The bits in parentheses are only added if doing without them is looked on as being sarcastic.
If the training course didn't go like that it was badly designed.
My first thought was what about a circular motion around the speaker. However the greater problem is with a sentence such as "He always took his dog with him on his meanderings."
"Meander" suggests that some of the movement will be towards and some away from the speaker while the dog would complicate things even further running back and forth, So should it be "take" half the time and "bring" the other half?
A word can be short and pithy but still wrong.
There is a verb "give". Derived from that is a noun "gift" - that which is given. There is no need whatsoever to use the noun as a verb because the verb already exists and yet that is done if the giving is to be presented as something particularly significant.
The simple test there would be to use the fancy verb "donate" with that donated as "donation" and ask oneself would one say that it had ben donationed? If not, don't say it had been gifted.
/rant
I suppose it could be applied to manuals too but my scheme for reviewing a UI, in particular a web site, would be a team of:
1. Such a first time user. one familiar with the domain but not the application.
2. A developer responsible for the application.
3. An invigilator
The ostensible purpose of the test is to determine how many steps the user takes to accomplish a set of tasks compared with the minimum number as established by the developer.
The user is only permitted to ask and the developer to answer questions of the form "where does it tell me how to ...". The declared role of the invigilator is to enforce this rule but the real role is to prevent violence between the other two. The real purpose of the test is to demonstrate to the developer just how awful the UI really is.
On occasion I've felt that this could have applications outside S/W development. Arrangements of signposting would be one when a destination signposted for several junctions suddenly ceases to be listed.
As someone who runs native Linux applications on the desklaptop that's the way it strikes me too but as Microsoft pushes so many users into the remote versions of their S/W it's hard to see how a Chromebook would differ in those terms.
Meanwhile a Linux OS running MS Office & other Windows S/W locally is going to confuse a number of commentards here but I suppose they can bleat about it being inconsistent with whatever UI MS currently imposes and other Windows users are complaining about.
"Yes I know I am seeing unicorns for the last paragraph"
Not a council system* but a former client of mine used an ERP system from a small supplier. They had a number of quite different scenarios for various parts of the business ranging from the main logistics business to a few maintenance contracts. They had enough knowledge within the business to handle most of the customisation in-house. That was an important success factor. It probably stemmed from a realisation at the top that the ERP was essential to the business which made it worth having that expertise in-house
The other, which makes the OP's paragraph less of a unicorn, is that, because the ERP supplier was small, where stuff couldn't be handled in-house by the customer it was possible to go to the supplier and negotiate acceptable prices for mods or new functionality some of which was rolled out to all the customer base. That again was made possible by in-house expertise. There was a penalty in that we had a few weekend shutdowns for table reorganisations.
* For very good bad reasons any discussion of \ERP here is going to end up discussing councils.
ERP has been around for a long time. I suppose there have always been failures but if these had been so big, so frequent and so well publicised it might never have become mainstream.
So what's going wrong now? My guess would be that in the past it's been driven by the business wanting a given set of facilities and possibly adopting them piecemeal so that adjustments are made - to the business itself or to the application configuration to bed everything in. Possibly even applications were modified on the base of early adopters' feedback. Because it was the managers on the business side who wanted the project they were naturally engaged with it.
Now we're seeing projects forced by vendors pushing customers to update and preferably update into their (vendors') own clouds. Customers aren't "jumping in", they're being pushed. Vendors are sufficiently bigger than their customers to not care and to be able to dictate. The business isn't really engaged any more; those who were have moved on, those in place now have no knowledge of how it was dome and expect it to be all turnkey.
My view of sudo is that, irrespective of the age of the version or the language in which it's written, it has a basic flaw. If a user's ID is known then root access is only one password away, even if it has to be used twice.
It's there to solve a problem that doesn't need to exist. In 1981 subsystems such as printing had their own admin IDs such as lpadmin.
"this is quite common behavior in packages that ship replacements for older, more complex tools"
There's the quandary. If an application had been stable for a long time is there justification in rewriting it? Are there more undiscovered issues in the original version that outweigh the new ones which will be, at least initially, introduced?
To get back to your original question, I'd say go Devuan, but being a Devuan user anyway Rice-Davies applies.
IME the Devuan installer is pretty well the same as the Debian installer. and I have, in the past, not selected any GUI at the tasksel stage of installation intending to install KDE from the command line and found it just installed Xfce anyway.
Also IME if you install one DE and try to replace it by another you can spend ages picking bits of the original DE's fluff out of your navel. The worst was in the early days of the great GNOME 2 re-creation & I tried all of them in turn. It might just have been overload and MATE happened to have been the last but I ended up having to do a clean reinstall of the OS after it.
"The only exception are smaller companies who frankly received a bargain"
Let me guess: those were early adopters who put up with early versions, whose feedback shaped the product, whose enthusiastic recommendation helped sell it and whose money was immensely more valuable to a fledgling vendor than a "reasonable" rate would be today.