The idea is to create so many they couldn't help to jump back and forth. To (hopefully) leak into another brane and (hopefully) leak back.

If they just sit in the middle of nowhere, it's a hope that an abnormally large source from another brane just happens to emit in that particular spot at the right time. In other words, beyond improbable.

Though better, that still provides attackers with a ready-to-roll dictionary (after a rainbow table attack) tailor made to the salted passwords.

Read: They are terrified they didn't handle things right and might have some sort of injection attack somewhere.

Well, not necessarily but it does suggest that they have it in plain text *or* fail to use a salt, which is nearly as bad.

Unless you have a rootkit made of a signed linux kernel with kexec enabled. At which point you can boot all day long with unsigned stuff in the middle. Which is one reason why a mechanism where SecureBoot could have told the difference between Microsoft and Linux would have been better. MS has to worry about how *everyone's* functionality can go as potential threats into the system. In short, Secureboot is *also* a mitigation with similarly large gaps as a mitigation.

To be loaded as a driver, the driver must be signed. Yes an exploit in a driver means that things could be circumvented, but the attack vector gets increasingly difficult to navigate. You have to know about a set of driver bugs that are ubiquitous enough to bother exploiting and hope the market hasn't patched over the issue before being caught. Also the chances that said bug can be exploited in a manner to perform a targeted attack on the system partition....

In short, yes a kernel-level bug could still hypothetically let some malware at it if some sort of namespace isolation were applied in the obvious case. In practice I see that as a small attack vector. I would wonder if the fact that MS has to liberally allow other OS vendors to get signed bootloaders presents as practical a risk as the 'uncloseable' vector of a kernel exploit to circumvent OS level protection.

I would have had less of an issue if the firmware shipped without signing key until your OS vendor of choice registers their key at OS install time, rather than having the key from MS pre-applied to random board before any OS were applied, meaning only those seeking to *replace* an OS would have to sweat tearing down Secureboot setup. This would also have left MS to be able to more strictly certify that the bootloader is *Microsoft* rather than some other boot loader that MS also signed to make a good show of being in a competitive marketplace. As it stands, it's on one hand too restrictive and yet not measuring a specific enough thing for optimal security.

In Windows, it's not unheard of that a piece of malware with sufficient access interjects itself where the next boot will be picked up before the OS has a chance to set up it's own protection. Of course my complaint is that this vector would have easily been sidestepped without a huge firmware mess. If the OS set up access to that area as very very very very special, requiring signed code within the OS to modify that section of the platform, then the problem would have been solved. You want to write to the *system* partition? Oh, you need a special signature from the OS vendor to get that access. Otherwise processes are running in a namespace that silently masks the existence of the system partition.

What are the chances that a vendor that declines to update 4.3 to 4.4 would be willing to do an update for a 4.3.x if Google bothered to do it.

I think it smells bad, but trying to target users with vendors holding back 4.4 but willing to do another 4.3.x update is tricky. This is why google moved toward moving stuff in a more modular fashion: to get the ability to update relevant portions without demanding the vendor get in the middle.

Of course, in that case you still don't need the fake engine. The natural sound of the engine is plenty adequate. Ford more screwed with the tone to make it sound like a bigger engine. Pull the fuse and you still hear it, just sounds different.

There are plenty of videos now of people doing comparitve drive with the fuse in or out. With fuse out, it sounds much more like one would expect a 4-cylinder turbo to sound. It's not exactly terrible, but it is markedly different than the sound of the V6. The manipulation brings it more in line with a larger engine for people too insecure to be reminded they are driving a 4 cylinder.

I can understand the perspective that a single repository for more of the userspace resembles the *development* of traditional Unix systems, the argument made is usually not about where it is developed, but reducing the principle of having small simple utilities with straightforward interactions with other componets. For example, Most traditional Unix systems have terrible implementations of a shell interpreter and things like fileutils. It is an awkward, but not too terrible a situation since you can replace that stuff with GNU equivalents trivially without horribly breaking the OS. An administrator that understands enough to write scripts can discern the nature of interaction even if that administrator isn't a full-on software developer. systemd design trends in many ways toward requiring someone needing to dig in to have more development competency than previous designs. As a developer, I understand the attraction of some of the architecture choices, but I think they lose perspective of what it's like to be an administrator on the ground. Someone who doesn't live and breath your code has a harder time wrapping their heads around how it should be working when something requires customization, replacement, or debug.

In general, systemd is all-or-nothnig about a lot of things. They figure out a way to achieve what could be considered a sensible goal, but then go about it in highly disruptive ways. The sense is they throw up their hands and say 'well, this is the only way to do it, and it's worth it' rather than rethinking how the end could be achieved in a less disruptive way.

I actually went to one the other weekend. They actually had a good selection of resistors, capacitors, and so on. As others have said, I can't think of another brick and mortar anywhere near me where I could pick up components *now* if I wanted. I think there was a phase where they got all of that out of their stores to chase yet another business strategy. I think that was a mistake because it removed radio shack from the minds of the few people who still would go there to chase a market that didn't place any value whatsoever in their company.

I really wish they had settled into some run-rate business model that could've sustained them while continuing to stock those piece parts.

Your point is a big part of why management should be very careful about apparent 'cost savings' In a large amount of cases, management is chasing a buzzword more than carefully examining what comprises their budget for in-house versus cloud hosted.

Part of the cost savings of the cloud operator is having them do things to the data that most companies would never approve for themselves. Additionally, only a relatively small portion of the expense is moved 'to the cloud'. A lot of work still *should* happen that is lumped into the presumed cost of being internal versus external. So either a new budget starts growing to cover the cost previously not broken out or work stops happening that may critically matter.

Actually, if anything the typical cloud experience doubles down on proprietary tools. Sure the vendor may be availing themselves of open technologies on the backend, but the vast majority of them use proprietary interfaces to interact with their customers.

ntp is surprisingly complex to deal with a surprisingly complex thing. If tlsdate was a decent enough utility, then we'd still be using the time protocol of rdate as the go-to time sync strategy. Precision and quality is much lower.

There's also a couple of tricky things. One is that it could be dropped in TLS 1.3. Another is that it doesn't play with the concept of TLS certificate expiry.

Basically, this is a potentially handy utility to take the place of rdate, not something that begins to touch ntp.

Some men just want to watch the world burn.