But they can't use that specific one again, it doesn't matter if they take the bill to a bank and get new ones, because the serial numbers won't be the same.
My experience with my Google home before I unplugged it is that it would randomly kick on - even in relative silence, unless the clack of a keyboard and maybe a fan whir could be misheard as "okay Google"
I would notice because it sat on my computer desk.
To be clear, I don't think it was nefarious that it would, just that I realized I wasn't using it as much as I thought I would and decided to unplug it.
wpa_supplicant just does the heavy lifting of connecting to the WiFi network.
The WiFi device itself is handled by the kernel's brcmfmac driver, and there is the usual firmware (also requires a .txt file) or you can use something like nexmon, which tweeks the firmware (and a patched driver to use it) for using monitor mode, injection and a few other misc things people have done with the firmware.
Are you sure? I've worked with a myriad of ARM devices, and I would say that despite their small size, Hardkernel are one of the most responsive companies when I have had issues.
Hardware vendors hardly are the best sources for OS images, except maybe for very new boards. When I shop for a board I always look if it is supported by community driven projects such as Armbian, DietPI or even plain Debian.
Im excited to look at the wifi on the RP4! Any word on the chipset used for that?
On a more personal note - thank you for your service.
You got any advice for pulling the aircrack_ng/rtl8812au driver from github and making it into a patch for building in-kernel? I really like having signed-module verification, but I also really want this driver.
The credits at the end of the post thank folks who worked on the CYW43455 integration, which matchs up with the raspberry expectation of being a (former) Broadcom part.
I thought SoftBank is Japanese, not Chinese? SoftBank bought ARM, not a Chinese company, otherwise it would be a bit weird for ARM (assuming they're Chinese now) to cut ties with Huewai.
Just about every other board out there is just as plug and play as the RPI.
I'm not saying that to downplay the RPI - the community it has around it is great, but long gone are the days of trying to get Linux running on a random arm board. And I should know, I have over 100 different arm machines at my place.
The lack of contributors has a lot to do with Lennart's (apologies if I misspelled his name) attitude early on in systemd's development.
I have no idea if it has changed, as I gave up trying to get things fixed.
The one issue I still have with systemd is the way it handles the kernel's command line.
I work with Chromebooks a lot, using software that isn't ChromeOS. The cool thing is that they can use FIT images so you can load multile kernels and device tree bindings into one image. So I can use the same sdcard on the Acer tegra Chromebook, Samsung's Chromebook, as well as the ASUS Flip Chromebook. However, to boot from sdcard you have to enable developer mode. When you enable developer mode, it adds a flag to the kernel command line "debug" - systemd sees that and thinks you want systemd in debug mode (wat?) Unfortunately there is no way to override this. I've tried passing the log level as info, which sort of works, until journalctl starts, and IT parses the debug flag in the command line and ignores the flag that sets the log level to info.
No amount of explaining this helped and I (and many others who have had various issues) gave up on trying to help make systemd better.
The only workaround to this is to stop using 1 sdcard amongst all of my Chromebooks and use individual sdcards per machine that uses a u-boot built for each Chromebook that does not pass the debug flag.
I like systemd and many of it's features are helpful, but when you run into issues, it's almost always an uphill battle to fix them, even when you provide a patch.
> adds a flag to the kernel command line "debug" - systemd sees that and thinks you want systemd in debug mode
A reasonable assumption, given that systemd is taking care of the whole OS, and if you want the kernel in debug mode, you’d reasonably want the system in debug mode too. But it’s not obviously correct, either, and ultimately it boils down to “who owns the kernel command line flags”. There was some kerfuffle about exactly that between the kernel and systemd people, but they eventually worked it out – I think systemd no longer tries to assert ownership of the "debug" kernel command line parameter.
Ah yes, debug parsing. Didn't that attract Torvalds' ire some time ago when it was found that it made systemd flood the kernels log buffer with "junk" data?
Then again the other guy in the systemd team, Sievers, have a long history of pissing the kernel people off with out of the blue unilateral decisions.
I just worry when their buddy GKH is given the reins of the kernel when Torvalds steps down...
Lack of contributors? systemd had over 300 different contributors the last 12 months. That makes it in the top 2% of open source projects (tracked by OpenHub). Which is very impressive for being such a low level component.
https://www.openhub.net/p/systemd
Anyone who follows the systemd-devel mailing list and the systemd github repo knows that there's just around four maintainers regularly active to varying degrees, including Lennart.
Maybe they added it after you read it, but when I read the post they specifically mention it's bad and provide a link to read more on why it's bad.
Sure an alternative would be great but the point of the article is to get up and running with the pi-hole software so they went with the fastest install.
