Re: Jedes Schrift'l ist ein Gift'l
Dammit!!! German.
40471 publicly visible posts • joined 16 Jun 2014
"and ten routers needlessly consuming power in a cupboard somewhere."
The skinflint manglement probably insisted on those being the ISP's routers. In that case they could be remotely managed at the whim of the ISP. Been there with my home router the one time I used the ISP's box instead of my own. I needed to make some changes to the DHCP pool I'd set up & found that since the last set-up they'd locked local management.
"One of the main criteria is if over 80% the income is from one "client" then you're actually employed."
I doubt it's as simple as that. On that basis if a plumber comes to service your boiler then unless he's somehow simultaneously getting at least a quarter of the amount you're paying him from somewhere else he's your employee at the time. If a jobbing gardener spends a whole day working on your garden is he getting the equivalent of quarter of a day's gardening pay somewhere else?
Like you, I doubt this sort of legislation would be introduced in the UK. The equivalent already exists here: it's called IR35. It means that HMRC can take their pound of flesh from the individual worker, no need to take on larger businesses who might be better equipped to fight back.
One thing the police and forensic scientists have to do is list things and the lists include clothing. You have to be careful to get the adjectives right. An "old lady's coat" isn't the same thing as a "lady's old "coat".
Witness statements might not be on the GCSE-English curriculum. Perhaps they should be. English is a more subtle language than it's often given credit for.
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.