Re: Don't rush them!
Maybe he had a day off.
42396 publicly visible posts • joined 16 Jun 2014
True, but that doesn't excuse not trying harder, especially when you see reports of updates breaking stuff or failing to install. I don't know about OpenBSD but the weekend's Linux Kernel/Debian issue was a really rare event and quickly sorted.
I left W10 checking for updates, went to the dentist. did some shopping, came back and - still searching. Then threw an error. I very rarely use that and quite frankly, fail to see why anyone relies on it for serious work.
"Now, the only thing everyone knows is that he watches porn on the job and abuses his knowledge to wreak havoc when being caught."
Also FRB customers know their bank fires somebody who does that and doesn't get round to revoking their access for a few hours.
Not "who?" but "what?". And the answer to that it is "the outcome". Landing you in court might be an extreme example. Losing all your advertisers might be another although Musk seems not to have quite joined the dots on this one yet. It all depends on what's done with the output.
The problematic Debian kernel version was 6.1.0-14.landed here at the weekend. I installed that about 6 pm yesterday but didn't immediately reboot so continued running on 13. I'd seen a news item about an ext4 problem but it didn't register that this might contain it. Later in the evening I rebooted and maybe an hour afterwards an alert came up for a new update. I checked that & found it was for kernel 15. Realising that 2 kernel updates a day meant that there must have been a problem with the first so immediately installed and rebooted and then looked into the history finding the references in the article and this discussion https://lwn.net/Articles/954285/
This left me with the problem - did I do the big sorting out of email archives before or after the reboot? I think i was after but AFAICS, no damage done. Deep breath! This, BTW, was in Devuan but as far as non-systemd stuff is concerned, it's Debian
Debian 12.4 with the corrected kernel was out by the end of the day, BTW. See amacater's post towards the end of the LWN comments.
As far as I can make out from the discussion the later patch was - ironically - supposed to deal with the possibility of corruption in the event of a system crash under certain circumstances which is the sort of thing that's like;y to get a high priority for back-porting and the earlier patch that didn't get back-ported may have been the performance-related one.
Once Debian went it was always going to be followed by most of the distros that are based on it (except for a few deliberate standouts such as Devuan). Chief among the distros that follow it directly is Ubuntu and that then dragged in all those that follow Ubuntu such as Mint.
I'm not sure why you would find Devuan more difficult than Debian. IME it Just Works as you'd expect Debian to do (if we draw a veil over linux-image-6.1.014 and Debian 12.3).
"Part of me wonders if there's a Bloody-Stupid-Johnson type thing going on here, where patrons keep funding Poettering out of morbid fascination as to what he'll screw up next."
Remember who employs him and worry about
Systemd 365: It is a single binary blob. Everything else is eliminated and the entire system is now a thin client to run application in Microsoft's cloud. Google & AWS are complaining to the regulators and working on reverse engineering so they can fork it.
A separate /var is useful, and I set it up to reformat at install time - I've seen an install messed up because there was prior content there. Of course this is a bit of an issue if the distro puts web server data and/or database data there. They should be in /srv and symlinked back to /var in case the system expects them to be there.
"with System V initscripts I can follow what happens"
You can even run them on the terminal to debug them with single stepping. Or you can insert some logging commands to see what's happening when run for real.
I spent a very long time trying to debug video on a MythTV box running Upstart because I couldn't work out how to monitor what was happening. It turned out that the TV was lying about its video resolution reporting itself as having the screen of a PDA. Then along came systemd like Upstart on steroids.
"A user ID is supposed to uniquely identify the user. It's not supposed to be an extra password. So email address is perfect for that."
If the string representing the user is not unique to the user/password combination as well as unique on the particular system then it isn't unique. And therein lies the problem.
You and I probably come at this from different directions. Mine is one where, in addition to spending about half my working life in IT, I spent another third investigating crime whilst fully aware that investigation was a poor second to prevention.
We know that many people will use the same password, don't we?
We know that many people have only one email address, don't we?
Is it a good idea to help save users from themselves?
Maybe you'd answer "no" to the last one although a moment's thought should tell you they'll blame you if something like this happens to them. However, if we answer "yes" what steps can a system designer do to implement this?
One is to insist on a strong password and hope they don't use the same password elsewhere; if they have trouble remembering a password they'll probably reuse it, even if it is a strong one so that doesn't necessarily protect them at all so you can't be sure it will be unique.
Another is to use 2FA. That's a pain if the text is sent to a phone with a flat battery (a common state of mine) or takes an age to arrive for some reason (been there too). That's failing your requirement of making it easy for the customer to pay. What's more it has its own set of problems. It becomes a problem if the phone is lost or stolen, especially if there's information on there which indicates which site the owner uses. If that happens to your phone you should quickly realise that you are no longer you; whoever has hold of your phone is now you. And if as a site operator you use a third party to handle the 2FA you've just increased your chances of a supply chain attack.
You could try checking Have I Been Pwned to see if the credentials are there, warn the user if they are and insist on a different password. It's not 100% as the combination could have been stolen but not made its way there and even if it hasn't been stolen yet it's still lousy forward security.
So it comes down to not trusting the user to use a unique password nor to choose a unique user name if asked but to simply assign an arbitrary account code and rely on the miniscule probability that the user doesn't have the same one elsewhere. There's nothing stopping you taking an email address as well - you'll probably need it anyway - but just realise it makes a crap user ID for anything other than the user's email.
Credential stuffing. Same UserID and password. Same password because the user is lazy. Same UserID because sites insist on using email address for that and most users only have one. The reused password is irrelevant (the password's being weak is a separate matter) if the site issues arbitrary UserIDs. Email address as UserID is the gift that keeps giving - for the criminals.
Some may be very "dangerous" if forgotten.
Wife's birthdays being the most dangerous.
A good while ago I was on the phone to an insurance sompany and had to give my wife's birthday. The agent told me I had it wrong (they had day and month numbers swapped). I assume he must have been young and unmarried.
"The 14" Macbook Pro ... a higher resolution screen,"
I expect if I were comparing the two I'd take the bigger screen over the smaller pixels. And still complain it's too small. I suppose it depends what you're doing but a lot of my time is spent with two documents open side by side, one being worked on, one reference, and 15" is too small for comfort, however many pixels are squeezed into them.
"Musk broke the rules and agreed to the deal in lieu of a court case – as most companies to to avoid further liability cases."
Which goes back to my original point. Allow him to rescind the agreement if he wants to and let the case go back to the original court. His choice - keep the trap shut or take the consequences of not doing so.
I was reading somewhere of an idea to locate data-centres near wind turbines - in fact, right inside the hollow tower. The rationale was that the grid can't cope with the turbine output at highest wind levels and gets shut down entirely. By consuming some of the power on-site the grid doesn't get overloaded. As turbines are normally well away from possible uses of waste heat it would be a case of either/or.