emptycan

I don't agree intent has any relevance here vs the other issues at hand, and it is news to me that there is some actual distinct expectation of privacy with regards to wavelength as you state.

Visible and IR wavelengths don't reach outside through non-windows, because of physics - but I don't think there is any inherent expectation of privacy - quite the opposite. If you leave your front bay window open and people outside can see in, and you call the police for privacy invasion they will laugh in your face in most places - in fact if you are doing something deemed obscene or distasteful you may be the one arrested - and for good reason. They'll tell you to get something to block the light like a curtain.

Whether or not people intend it - wifi signals easily will make it to the street - and they're on shared spectrum. Especially if you're going to pollute the public ISM band - it's sort of on you to take whatever precautions you need to stay safe whether that is better encryption, a faraday cage or just abstaining and finding alternative means.

If you start blasting loud noises 24/7 constantly in your neighborhood and someone complains, is your response going to be well, "I don't intend for this garbage to reach my neighbors"?

> Yeah it's comical because Linux has so obviously driven a lot of people away from kernel development.

I hear this "a lot" very often, but then it seems to be from people who have no real interest in technical work of kernel/OS core development. Linux is not the only way to scratch your itch for interest in low-level system dev. Like, this is just personal experience, but I have heard this on the order of 50-100 times: someone parroting how toxic Linux kernel dev is because of drama they heard -- but then you kind of dig a little bit and see what kinds of software stuff interests them, what do they work on -- probably only once or twice has it been anything embedded, hardware related, close to the metal. I would need compelling evidence to change my opinion that most of the complainers have no interest in the work being done by the community they are complaining about -- and I am fully aware that a number of people have departed Linux development, but we are talking about a tiny number of the thousands of contributors over the years -- you can't please everyone.

The hobby OS, emulation and demo scene is a pretty good indicator for "natural"* gender breakdown. These tend to be tight, tiny communities or often lone wolves working on projects. It is male dominated. This can't be explained by any systemic or community gatekeeping - because there is no system nor any mandatory community for participation or distribution. Nothing prevents anyone from putting their work out there.

* I am not discounting there may be other systemic reasons that set up this condition - but it has to be societal conditions that are in place in early childhood -- something that happens a bit before one considers contributing to the Linux kernel.

That's quite a leap from "scan SSID" to knowing "all about your home network" and sounds like hyperbole. What can I gather from just passively scanning SSID and possibly putting out some probes on a properly configured WiFi network? I imagine some things like number of hosts, MAC addresses, traffic stats - which is not ideal, but hardly what I would call knowing "all about it".

I'm quite the privacy nut, but I always think its ridiculous that people cry foul about what people do with data that is being broadcast over the airwaves. If you really care about privacy and don't trust WPA2 then don't fucking use WiFi!

Yes it is - that's what /SS is for.

Simplicity of what exactly? From the perspective of the device/hardware, SPI is much simpler. A UART based solution tends to be relatively much more complex on the hardware/device side. You can implement a basic compliant SPI slave in a tiny bit of silicon - like a handful of flip flops simple. Moreover, you realize many of the simplest SPI devices don't have an oscillator, so you're still going to need a clock line - and if its truly a UART/asynchronous it may not be convenient to get a high enough speed external clock.