"the installation of packages that do require systemd. PHP, for example, requires it."
Fortunately the PHP that underlies Nextcloud on my RP server never read that and continues to run happily on Devuan.
32762 publicly visible posts • joined 16 Jun 2014
"Because the point of the computer is to run the applications...I’m tired of operating systems."
Your collection of running applications - I take it you have several there at any one time - is a collection of chunks of code needing access to resources such as CPU, memory and peripherals. How do they get that access? It it was just one application, yes it could run on top of bare metal but how would you then get a second to run when the first has direct control? And a third? And a fourth?
The job of an OS is to share those resources out so that each application gets its share, keeps applications from accessing each other's resources while letting them communicate with each other as necessary. It passes control from one chunk of code to another so that although there's a continuous thread of execution (or several nowadays) the user is presented with the illusion of separate applications all with access to their hardware.
What you describe is a complex multi-layered OS starting with, but very definitely including, your hypervisor, the VMs and the OSes inside the VMs. There may be a good reason for that hypervisor but you do have a much more complicated setup than a single OS running on bare metal. It's not surprising you're tired of OSes and that they and their VMs use a lot of resources for themselves to do the job they've been set. If indeed there's a good reason for that setup then that's the price that has to be paid to meet the requirement; if there isn't then it's the price for an unnecessarily complex arrangement.
Nobody's asking you to change your hardware or what runs on it*. But a lot of people have bought a lot of hardware in the last 10 years** and they've all had to install an appropriate OS on it and will continue to do so. Articles and discussions such as this are part of deciding just what is appropriate and reviewing if the original decision remains appropriate. In fact you must have had some process for deciding on what was appropriate for your requirements even if you don't feel a need for reviewing it.
* Nobody was even asking you to read the article if it had no interest in it.
** Just as a lot of people will have set up home in the last 10 years and needed to buy a kitchen table.
"If it is so bad why don't you develop/code a better version?"
If by "better version" you mean a better version of systemd then you have to remember that its problems lie as much in the concept as the implementation. A "better" version of systemd would still be systemd.
If by "better version" you mean a better version of init then there's no need. Better inits already exist.
What is really needed is a better version of FOSS politics than that which got systemd foisted on us.
If you want fine-grained control the better way would be to revert to the original concept: lpadmin owns the printers, bin owns the contents of /bin (it you still have it), /usr/bin and so on. You then have the granularity, you don't have to hand out the root password to those who don't need it and you don't end up with the situation where you might demand 2FA for users to access the services and 1FA for access to control those services.
"It [sudo]was invented to allow admins to give more granular access to some facilities in a more flexible way than UNIX groups on a UNIX-like system without giving full superuser access.
If you've ever run a UNIX-like OS in a larger environment..."
This entire issue seems to be the usual ongoing battle of convenience vs security.
I've run Unix from V7 onwards in production environments.
1. Back then there were several administrative accounts for different functions. For instance help-desk users could be given access to the lpadmin account to let them sort out printer woes. This was a sensible way to implement such granular access. The helpdesk user could su from their ordinary account to lpadmin with the lpadmin password, sort out the printer but with no extra privileges and then CTRL-D back to their ordinary account.
2. This seems to have been looked on as inconvenient and the other UIDs dropped out of use and everyone used root but at least it needed an extra password to gain access.
3. Mass use of root was then looked on as insecure so sudo was invented. The supposedly granular extra facilities were accessed by giving the user's ordinary password again.
4. Of course maintaining all these granularities in the sudoers file is inconvenient so we now have Ubuntu and its friends - including MX - having a standard user gain full root access just using their own password. 2FA it isn't
We've gone back to stage 2 but without the safeguard of a second password. Yes, I follow the arguments as to why sudo was invented but the reality is that it's being used in a way that is counterproductive to what it set out to achieve. In this round of convenience vs security convenience has won.
"Because MX Linux is derived from Debian I assume it has inherited sudo as well."
Debian and Devuan do indeed have sudo. However you can take it or leave it because the installation sets up a root account which Ubuntu and friends don't and it doesn't, by default, set up users in the sudoers file which Ubuntu and friends do. Out of the box the old way is the way to so things. Any time I have to set up a Ubuntu derived OS one of the first things to do is set up a root password. It also expects the likes of the KDE partition manager to present the root password.
I tried in install on my little nettop.device. It had a small but adequate unused logical volume group with Mint installed in regular partitions. Debian seems no longer able to install into logical volumes - would this? Yes it could see the logical volumes but needed a slightly larger root volume than I'd set up. Not a problem, there was space left and as I was using the KDE live ISO the KDE partition manager was available and could make the change without dropping to the command line. Not good. It needed the demo user password instead of roots. However installation did offer to set up an optional root password so maybe it would then default to Debian style. No such luck - the installed version still follows the Ubuntu approach.
Installation, BTW, starts copying the files in parallel with entering the user data. It doesn't however, set up the network connect, at least it doesn't for wireless, so it doesn't copy updated packages from the repository, leaving an update required at the end of the install. Of course when it gets to about 96% complete it has to do a grub install and grub probing takes up the other 90% of install time followed by rebuilding initrd which takes the final 90%. The subsequent update built a couple of kernel modules. I can't remember ever encountering this on Debian. It's painfully slow on this little box and if it were a regular feature of updates would be a bit of a pain - probably not as bad as Windows updates but better avoided.
Although it's Debian derived it seems to work more in a Mint sort of way. In fact the kernel announces itself as a Mint kernel in the logs. It'll take a while before I decide whether to use it to replace Mint on the nettop. I don't think it will replace Devuan on the bigger laptops.
"I'm sure Devuan ultimately works but its documentation is absolutely dire."
If by ultimately works you mean its release schedule lags behind Debian then I agree. It may mean your very latest H/W might not have drivers in the install image. Otherwise it just works as in the way Debian just works but better in not having the systemd obfuscation.
As for documentation Debian documentation will fit better than Arch and I've never heard of anyone calling the Debian Administrator's Handbook dire. A pre-systemd version will obviously be needed to cover sysvinit.
I should add that I ran the then next version of Devuan on a Pi Nextcloud server months before it was officially released and I currently have the Daedalus, the Bookworm based version running on a laptop and will probably get round to updating the main laptop shortly.
The allegedly brick-like Motorola was one of the smaller phones available at the time. A fewmodels had lead-acid batteries, especially those for BT System 4* although that might have been shut down by then. I remember one BT Mobile product, the Steel came in two varieties, Light Steel and Heavy Steel depending on the size of the attached battery but the names were only relative. This was the time when portable computers were referred to as "luggables" and mobility for many phones depended on them being installed in a car.
*Talk of 2G, 3G, 4G & 5G always amuses me. If the pre-cellular was 4, TACS, the analogue cellular system, was 5 & GSM started at 6.
"They can change their design at any time they wish, but for some reason they have chosen not to."
Design decisions become limitations. Once the implementation has been built round the decision any attempt to change the decision is apt to impinge on a lot of the decisions made in the course of implementation. I can imagine how it would be hard to disentangle it if it also acted as login screen and other stuff. Just thinking about it reminds be of another tangled mass of code that's best avoided.
See my note above re use in hospitals. What seems to be needed is a class of device best described as a smartphone with wifi, VOIP but no access to mobile phone bands. Preferably such devices would be run on a local-only network with only a gateway for VOIP to the outside world. This would meet the need for a mobile client for the organisation's own systems, essential voice communication and better security than a general purpose phone.
"Oh wait, did they even have work phones ?"
Yes.
Over the last few months we've spent too much time in the local hospitals. The nursing staff all seem to be equipped with phones. I hope it's a secure app they're using but they regularly use them for recording blood pressure readings.
"The Reg FOSS desk is very happy that he hasn't had to edit an init script in many years, and does not miss such things even one tiny bit, but all the same it's going to irk some people."
It's a long time since I had to edit an init script. It's like restoring from backup. You don't miss doing it if you haven't had to but when you need it you really need it. With init scripts if there's a problem you can either put tracing statements into the script or run it from the command line, stepping through it. Good luck doing that with a black box. Systemd hasn't put me to that trouble, partly because it hasn't had the chance. Years back I had a shedload of trouble sorting out a problem with upstart which is similarly opaque.
But what do they mean by cement? My understanding of cement is Portland cement - the calcined mix of clay and lime. Mortar - the stuff that holds the bricks together contains mostly of sand with some cement. Concrete, the stuff your foundation are made of, consists mostly of aggregate, sand and cement. The amount of cement is an order of magnitude less than the volume of the foundations.
There seem to have been very recent changes. Waterfox has escaped from System 1. Basilisk has separated from Palemoon. BinaryOutcast seems to be busy rebuilding the website - it appears to have gone through some sort of trauma; I don't know if the browser has been discontinued and only Interlink is surviving. There also seems to be a new Thunderbird fork, Epyrus on the go related to all this.
The issue for me, and, presumably for many, is that after Mozilla made their changes (TBH I never really followed their Quantum, Australis or whatever it was and all that other branding stuff) they could no longer follow existing desktop theming and just looked as if they didn't belong - not as ugly as GTK4 but certainly not as intuitive to use. The marketing and crayon departments are in charge - both at the browser vendors and the websites - and they want New, New, New whilst a good user interface needs, the opposite: clarity resulting from consistency and familiarity (which is consistency with the past).
"For a while, it remained possible in the Waterfox Classic fork of pre-Quantum Firefox, but today, sadly, that browser is barely usable anymore."
What about Palemoon and/or Basilisk?
Actually an article on the Mozilla spin-offs would be welcome. I've read the long article on the Palemoon site and left with the impression that it's the XUL Liberation Front vs the Liberation Front for XUL or something along those lines. Throw in Epyrus & the Matt Tobin projects for good measure.
"greenhouse gases are a byproduct of an economy wedded to cheap energy in one case, and in the other single points of failure in an industry wedded to huge datasets in under-engineered systems"
In the first case you have to remember that as a result of allegedly environmentally based Luddism use of nuclear was minimised for decades. In the other we have the opposite of Luddism - a rush to either transfer data out of the data centre to somebody else's computer somewhere on the internet or to keep it in-house but insufficiently separated from the internet.
Thanks, a link to a very useful article I may need to read it again and follow up the references. The lest bit - on whether models had developed the ability to reason and that it might not be possible to decide left me wondering about the reasoning of those doing the tests. Did none of them additionally ask the model to explain how it reached its conclusions?
I'm glad you liked the twist.
Sounds like you produced what I call "ravioli code".
If your analogy is correct there would be just the same amount of code there, just packaged differently. The main object of the refactoring was to reduce the LoC and hence the amount of memory consumed at run-time.
I get the impression that some people have been brainwashed by the low resolution of digital cameras and don't realise what photography can actually do with a large format. The information in a large negative would be hard to match in digital although Leica did,as I recall, try setting what was essentially a scanner mechanism on the focal plane of a large format camera. The time needed to set up a shot on a large format means that the result reflects a degree of thought denied to that of a point and click.
"the only way to test the output of a change is to actually deploy it in production."
One program in the system I looked after had been written by a programmer who, thankfully, had left long ago. It always annoyed me because of her odd programming style. It largely consisted of much the same code repeated multiple times. It was ripe for refactoring as we say now but maybe not at the time.
Late one afternoon I decided to tackle it.
One block of code was repeated several times. Copy that into a function and replace all the repetitions with a function call. Very straightforward. This must have shrunk the LoC to about half.
The remainder of the repetition consisted of two similar but not quite identical blocks of code each repeated several times. Not quite so straightforward. Copy one version into a new function adding a switch parameter then add the different sections of the version using the switch parameter to decide which t call.
Replace the repetitions with function calls taking care to use the correct value of the switch.
We now have a much simpler program, a fraction of its original size. It ought to be easier to understand what it's supposed to do which was one of the objectives of the change. But the remainder is still a bit of a tangled mess. Sorting through it to work out just what data would be need to test all the alternative paths would still take ages.
Well it was really all very much a mechanical replacement - the same code is being run, just from one of the two new functions instead of inline. Of course it must still work exactly the same as before.
It was now early evening. Why not put it live?
So I put it live.
Of course it worked exactly the same as before - what did you expect?
"Just like Jansen, Kirkby inherits a massive cost-cutting programme that will see up to 55,000 BT jobs wiped by out by 2030."
I think the target is to reduce staff to board, C suite, an outsourcing contract manager, their PAs and receptionist, a tea-lady an extensive catering staff and a cleaner.