KyleJ61782

Basically like little vaccine telomeres?

Especially since it's not listed in the title after clicking the link.

For all intents and purposes, yes. Besides making software easy to install, package managers figure out all the dependencies that a given package requires and install those as well. Can you install yum/dnf on Debian? I'm sure there's a way to do it. But good luck handling all the dependencies for a given package. Plus, there will be file conflicts when dnf installs a base dependency that apt already installed.

In other words, nothing good comes from trying to install two different package managers on one system.

That was already a possibility even before all of this DoH publicity. Mozilla, etc. pushing DoH publicizes it's availability, but there was nothing in the past preventing malware from tunneling all sorts of traffic over HTTPS. DNS inspection isn't an end all, be all for malware security. It just gets the low hanging fruit.

Using the NTDLL calls breaks stuff because NTDLL doesn't understand anything about the overlaid subsystems. NT was originally designed to support multiple subsystems in addition to Win32, like the Interix (POSIX compliant) subsystem and the OS/2 subsystem I believe. I think (I could be wrong on this) that this was possible by switching the system call table depending upon which process was currently active (doable by switching the system call vector).

Technically the Windows native layer supports fork()-like abilities, but the problem is that the Win32 subsystem and dependent layers (GUI, etc.) don't have fork() copy-on-write capability. So even if you were able to fork a process, you'd still have to deal with duplicating all of the stuff built on top. In fact, the old POSIX compatible subsystem layer utilized this functionality to actually provide a compliant fork().

Of course this all ignores the fact that Win32 processes are heavier duty than Linux processes (though I don't know if that's due to Win32 subsystem overhead or not). Look at any benchmark and you see an order of magnitude difference in process creation times. You're much better off creating threads instead.

> > But I and I'm sure many others would not be focusing upon that, though I can appreciate that mentality due to the way media/tabloids cover such and all issues in life

> That's a personal attack quite out of order.

Not really. It's just a societal commentary on how we've conditioned ourselves by the media we consume into passing quick blame instead of taking a slow, reasoned approach to analyzing the event, seeing the compounding factors at stake and only in the face of gross negligence assigning blame.

This. Very much this. In the presentations I've seen on the matter, the most vulnerable systems are those measuring and carrying telemetry back from various meters around the power system. One doesn't have to directly compromise the system to have an effect. Simply providing bad data to automated protection systems could be enough to cause instability.

Primarily it's due to function overloading. Different implementations may use different means to consistently and uniquely "mangle" function names on symbols to uniquely identify them in the library export. This mangling depends upon numerous factors, including parameter types and calling convention (if there are multiple conventions on a platform).

The size of the executable doesn't really matter after the first load as subsequent loads share the mapped section so it doesn't need to be loaded from disk again. Loading an executable multiple times after the first time really shouldn't take all that long from an OS perspective...just some mapping of shared pages.

Honest question: do you have a real-world example that indicates that the extra pointers added due to multiple inheritance actually results in performance degradation due to extra cache pressure?

I concur with the description of the Delphi implementation, as I've navigated it numerous times myself. I guess I don't understand the author's negative tone with regard to the C++/Delphi implementation. There's going to be overhead with any choice made and C++ and Delphi made the choice to sacrifice memory usage for speed. Furthermore, the only part that really scales with the number of objects is the extra vtable pointer for each implemented interface in each newly constructed object. Hardly a significant overhead in today's memory-prolific computing environment. Also, pointer fixup thunks and unconditional jumps are easy to speculatively handle.

Within galaxies, however, gravity dominates dark energy expansion, right? If so, with enough measurement accuracy shouldn't we be able to look for standard candles within our galaxy that either show or don't show said mass differences while compensating for any shift due to relative motion? I'd think that given enough accuracy we'd have something that's testable eventually.