Re: Redundant things are there for a reason.
Are the brain organoids being grown for transplant into the Boeing board?
40471 publicly visible posts • joined 16 Jun 2014
Quantum effects are there in your everyday life.
One is fluorescence - a molecule absorbs and re-emits light but loses some of the energy to heat. Non-quantum physics would expect the loss to show up in the dimming of the fluorescence. Because of quantum effects the emitted light is of longer wavelength because the energy of a photon depends on wavelength, red having less energy than blue. What's rather more mind-boggling is the duality of light - and that used to be part of my everyday life in the form of fluorescence microscopy. The fluorescence depended on he photon aspect of light but the illumination depended on interference effects in filters and a dichroic mirror to keep light in the excitation and fluorescence bands going where they were supposed to and nowhere else.
Surely the fact that the instructions for recovery by booting into safe mode indicates that there is a state where either the driver wasn't loaded or else it didn't try to read the offending file if it did. There's a halfway house of some sort. It will be a matter of risk management as to exactly what is now and what that might be in the future.
The updates are pulled in automatically so don't go through the IT department at all and if they did testing would be automated. Given that testing the specific functionality isn't going to be likely (do you want to keep samples of all the latest malware anywhere on your network?) about the only test is going to be determining whether it falls over or slows the system. Maybe some firewall rules that only allow intermittent access to the update server and not all the fleet at once might be possible, automateable and even allow for the inclusion of a sacrificial box as a trip-wire.
The instructions for fixing it implied it wasn't essential for booting into safe mode but that wasn't possible without manual entry of the key if Bitlocker was used. It seems there's a gap there between safely fetching keys from a server and not opening up networking to a degree that would be unacceptable without services such as CloudStrike.
Backward compatibility is fine provided that what it's compatible with is good practice and documented as what's supposed to happen. That doesn't include things like use-after-free. It also doesn't include using a few features for their own applications but not documenting them for vendors of competing products.
"Today, KDE suffers from far too many options scattered across illogically and unsystematically organized menus"
I'm a bit puzzled by this.
Do you mean the application menu hierarchy? That's editable so the organisation can be whatever you find logical.
System settings - there are a few oddities but not many that strike me. I can't see why Appearance and Personalisation are separate but Users and Startup&shutdown really should not be in those but in System Administration. At first it does appear illogical that Applications is in Personalisation but it has to be remembered that this is intrinsically a multi-user system and different users may have different choices here.
"A potential role for Oracle as an overseer of TikTok's source code was also rejected, on grounds that the sheer volume of the codebase – two billion lines as of 2022 – meant that a review would require at least three years of work on the code used at that time."
What? No AI pixie-dust to get the job done today?
"the ongoing efforts to have Big Tech pay for the traffic it generates"
I've always found this puzzling. I'm sure Big Tech has to pay for its internet connections. Did the vendors price them wrong? Very likely as they'd have been played off against each other and some salesman won with a low-ball bid.
In any hierarchical organisation those at the top of the hierarchy the only ability you can be sure will be found in those at the top will be the ability to climb hierarchies*. Any other abilities will be a bonus.
* Exception has to be made for those where the position is inherited. There what you get is a matter of pot-luck, hence the saying "rags to rags in three generations" is so often true.
You were doing alright until your descent into casual ageism. I suppose I could put it down to your being young, naive, having not yet lived long enough to gain experience of the world to mentally equip yourself with the understanding that there have always been "modern times" and that these particular "modern times" depend heavily on the inventions of some of those now retired and thus in your despised category of "retirees".
"Users are given control over the update policy."
Except that when the S/W fetches its own updates automatically, which I understand to have been the case here, that's a bit trickier. Some subterfuge might be necessary. Say your firewall is set to block the update server most of the time. Then it's opened for a time to let the canary update. If the canary remains perched then you can open it for the production servers for a short period. There's still the possibility of a race condition when an update is released between the closing of the canary window and the closing of the production window.
"In almost every case, development and support were kept apart as separate worlds"
I had the good fortune, when I started in IT, to have a team that did both with in-house S/W. It's always seemed to me that where that could be managed* it was the better system. The worst arrangement was where Unix admin & DBA were not only separate teams but we didn't even set eyes on each other.
* Obviously if it was bought-in S/W the customer's support/operations are going to be separate from the vendor's developers**
** I have, however, ended up debugging a vendor's code that was crashing a client's system but that was because the product was source-available
And what about liaison with support to find out whether Right Now is a good time operationally for this particular deployment? It's they who will have to cope with any changes of behaviour and if there are no changes why are you deploying it?
"It wasn't even a code problem."
It wasn't just a code problem but there were certainly two code problems. One is mentioned in the article - the validator. But there was also a problem with the code running in the kernel - it didn't check the duff data and reject it. Maybe it didn't check at all, maybe it had the same code as the validator but one thing is sure - code running at that level should be very defensively written. Every malware slinger out there now knows that, on the evidence of this, that if you can get something that looks like a channel file into your victim's Crowdstrike directory there's a good chance it will be picked up unchallenged.
After a week's field course in East Anglia I was tying stuff on the LWB Landrover to return to London. Halfway back I realised I'd put the lecturer's penknife down on the roof and left it there. First out of the door when we got back and enthusiastically on the step to help unpack, more in hope then confidence. And it was still there.
So far it seems customers are overall happy with locked into the arrangement. Don't dismiss those engineers and technicians who are, in your words, ranting on the internet. Some of them may actually be today's decision makers. Some of them may be influencing today's decision makers. Some of them may be tomorrow's decision makers. By the time Oracle actually see customers dropping them there'll have been a lot of commitments made, plans worked out and projects well advanced. It will be too late to drop prices.