No, Synology and QNAP are active bug reporters to the Samba project. I fix bugs for them both on a regular basis. Funnily enough, the Apple client engineers are also very active Samba bug reporters :-).

Have you actually *read* the GPLv2 ? I'm assuming not based on your statement. The GPLv2 text is here:

https://www.gnu.org/licenses/o...

Please note the following statement copied *DIRECTLY FROM THE TEXT ABOVE*:

"The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."

Please note the last sentence containing the words: "plus the scripts used to control compilation and installation of the executable."

Thanks for your reading comprehension.

I didn't have these handy when I posted this originally.

PDF of the full legal complaint. It's really nicely written (IMHO) and IANAL of course :-).

https://sfconservancy.org/docs...

Press kit:

https://shoestring.agency/wp-c...

Really nice non-technical write up from sjvn (yeah I know /. is a technical crowd, but it's nice to be able to have something to use to explain to non-technical friends):

https://www.zdnet.com/article/...

> The ARM reference design offers a guarantee that such side channels don't exist.

Nonsense. All modern CPUs have speculative execution side channels by nature. The only way to protect against these attacks is to change how we write software to insert speculation barriers in security-critical code paths.

The difference is that Intel doesn't just have speculative execution side channels, they had a pile of critical *security domain crossing* speculative execution side channels. All CPUs can leak data in speculation from your process into the side channel (which might be monitored by another process), but Intel has a pile of bugs which can leak data from *a completely different, innocent process*, or even the kernel (meltdown), or a VM hypervisor (L1TF). Those aren't inherent in CPU design, those are a result of what is clearly a major culture issue inside Intel.

> Spectre and Meltdown bed to differ.

Spectre and Meltdown are not covert channel issues. Spectre is a collection of speculative execution *side channel* issues, and Meltdown is a privilege domain crossing speculative execution *side channel* (the only one that hit other CPUs as well as Intel IIRC; other than Meltdown I think Intel has a monopoly on goofs this bad, e.g. L1TF). Covert channels are not the same thing as side channels, as they require cooperation from both sides.

There isn't really any proof that Waymo vehicles are driverless, only that the driver isn't in the vehicle. If you compare a dozen dubiously driverless vehicles to a million collecting data every moment and already doing a pretty good job at autonomy, which do you think will succeed?

The fact that the driver is not in the vehicle does not mean that there is no driver.

SMB3 is usually encrypted by default. The "locks" on it are very well designed these days.

Microsoft considers SMB3 with transport encryption secure enough that it's used as an ingress point for their Azure cloud.

There are no known vulnerabilities in the SMB3 protocol. Implementations however, of course, can and do contain bugs.

I believe that this was figured out in the amateur observer community before NASA confirmed it. I saw it go by in my twitter feed. Not sure I can find it now...

Linear Energy Transfer

It's not radioactive. When high-energy particles strike it, they break apart into lower-energy particles that are more harmful. So, you need enough shielding to catch the particles that break apart in the top layer of your shielding.