Peter Duffy <pe...@pwduffy.org.uk> wrote: > So customers pay to be insulated from complexity. Just so obviously a > blatant restating of the M$ attitude - which is the reason why there are > so many clueless computer users the world over, and by extension, so > much cybercrime.
That’s a “complicated” discussion. Take the car analogy that’s previously been raised - and they are usually not good analogies anyway, be hey-ho. In the early days of motoring, you had a lot to learn and cars were non-trivial to drive and to keep going - to the extent that many users employed someone to do the driving for them. Roll forward through the years, and cars have got more and more complicated, but also easier and easier to operate and more and more reliable. At one time I used to carry a basic tool kit all the time, now I don’t as a) the car is quite unlikely to break down and b) there’s probably nothing I can do anyway. But now, anyone with basic skills can make a car get them from A to B, in relative comfort, and typically without drama. By analogy, back in the days when “computers” really only meant the likes of big IBM iron, few could “drive” it - to the point that most business people employed people to do the driving and they simply said where they want to go (e.g. get some numbers out on a printed report). Now, for many, they do their own driving using BI tools, dashboards, and the like. But in both cases, when the modern, complicated but very easy to use, but highly reliable system develops a fault - then it needs an increasingly high-tech person and tools to fix it. But it’s not the fault of the tool that users are clueless - that’s the fault of the industries and society for pushing the agenda of users not needing to know anything about what they are doing. The classic example is the volume of, sometimes entertaining, material to be found on ‘internet where people have managed to completely f-up something in Excel because “it’s only a case of some random clicking, who cares about skills or training”. The vendors of anything are only too keen to persuade users that their product is easy to use (perhaps mentioning Boing and the 737-Max is in poor taste), but the reality is that most people value “ease of use” and far too many don’t value actually having a f’in clue what they’re doing. > But if systemd makes it more difficult to solve problems, and makes the > system more unreliable, then the customers aren't even getting what they > paid for before systemd was introduced. The problem is obviously proving > whether or not systemd really does make a system more > unreliable/undiagnosable. Well provided nothing goes wrong, clearly SystemD is easier to use for an admin without a clue. Clearly writing a unit file to start something is so much easier than having to learn how to write in Bash. I think that much is hard to disagree with. And if the tools make looking at a journal file easier, (I’ve no idea), then that bit is also true. So in some ways it’s a step along the road of making things easier for the general user, or in this case, the power user or novice admin. So yes, the user does get what they are asking for - but the downside is that when it breaks, it’s harder to fix. Reliability is perhaps a different matter. But then back to the car analogy … There’s no shortage of problems with modern technology in cars - a common complaint is that the age by which a car isn’t worth repairing due to the crossover from decreasing value and increasing repair costs is reducing. Only yesterday my car was in for a recall (so it wasn’t me paying) to replace a faulty airbag - the faulty airbag being one fitted a while ago to replace a differently faulty airbag fitted during manufacture. So in that case, the presence of the airbag has increased the scope fo faults - my old Land Rover has no air bags (in fact the only electronics in it is the aftermarket magnetic pickup & amplifier replacing the points in the distributor. But people value the safety from having airbags, so we (collectively) accept the downsides of having them (complexity, cost, and loss of space that would otherwise be available for storage. > I've wondered for a long time if it would be independently possible to > make systemd optional. I think you found that the answer is no. IIF, and that’s a massive IF, SystemD had only been “another init system” then yes. But there are so many dependencies where devs of all sorts of software have to make an either/or choice of whether to support SystemD (which you can’t do if you want your package to run on the majority of platforms) or support the “traditional” way, that it would mean every package developer putting a lot of work in to deal with the alternatives. E.g. simple logging of diagnostics etc would mean having two lots of logging code to handle syslog or SystemD logging. On this, I am in agreement with Steve Litt - the SystemD project has an incentive to maximise their intrusion into every aspect of system operation. Because the harder they can make it for devs to make they software run on SystemD or any other init system, the more they can make other software depend on SystemD and thus make it harder to keep SystemD optional in the wider view. So having had SystemD create such a gulf between the requirements to run on “traditional” systems dn SystemD systems, effectively any shim would have to recreate a heck of a lot of SystemD. <sarcasm>And we all know that such a shim would be trivial to write given the well documented and stable interfaces between the SystemD components </sarcasm> >> Peter Duffy said on Thu, 25 Nov 2021 13:51:18 +0000 >> >>> I've said it before and I'll say it again. All this could have been >>> avoided - if systemd had been made optional from day 1. People who >>> liked it could use it; people who didn't like it could use something >>> else. And in the Debian world, I distinctly recall there being an air of “don’t worry, it’s optional anyway” alongside the “and it’s only another init system” arguments. It was only once it was too late and the GR had been fudged to get a pro-SystemD vote that people realised that it was never going to be optional. Simon _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
