The "future work" section of the paper covers the smearing part! The authors acknowledge that it is unknown whether the results translate to smeared paint.
This is probably little of a grey area. I don't think that the IP-address by itself is considered personal data since it usually doesn't single out a specific living person. Unless you pair it with other information, like date and time.
But if IP was considered personal data you would need an active consent from the user where you also inform them why you are doing this, which paragraph in GDPR gives you legal right to do this, how long the data is stored and you will need a data processing agreement with Cloudflare. You will also need to be able to prove that you made sufficient effort to make sure you are not handling data of someone under 16 years of age.
People often think that GDPR is made to forbid processing of personal data. Actually you can pretty much do anything with peoples information and still be GDPR compliant. It's more that it becomes such a hassle to do it and still be compliant that it's just not worth it to collect personal data "just because you can".
My understanding was that fbdev is deprecated (but I was unable to find good info on this) and that one should use dumb buffers (https://manpages.debian.org/testing/libdrm-dev/drm-memory.7....) for this simple stuff / somewhat portable software rendering. At least Qt allows to do this for embedded devices without hardware rendering.
Yes. fbdev is kept alive for compatibility (and fbcon) reasons, but it's a really outdated API and drivers have to jump through hoops to support it. Please use dumb buffers when necessary. See a simple example here: https://github.com/magcius/drmdemo
How can I write a simple device driver using dumb buffers? I have searched far and wide but I can't find anything. I'm forced to write a framebuffer driver. Once you dip into DRI shit get's insanely complex quick.
But even then, not every display-enabled SoC is well modeled as a dumb framebuffer. The Raspberry Pi itself provides hardware overlays, and it's quite problematic to expose them under that kind of model. The DRM infrastructure seems to be a lot more general and flexible.
I wouldn't recommend an RPi for product development. There are better SoCs, like i.MX, with documented graphics pipelines and graphic/video/camera overlays that are easy to use.
A while ago I stumbled over a proposal to move a shared pointer (this was C++ code) to a thread in order to trigger the freeing of a legacy data structure there (the multi-thousand delete calls caused the watchdog of the main thread to fail).
However, keeping the shared pointer reference in the main thread for too long resulted in the possibility that the "clean-up" thread ran while the main thread still had a hold on the shared pointer... Resulting in a low chance of the "clean-up" thread doing nothing and the main thread still locking up. People here got taught to use shared pointers to prevent memory management errors, but it can really cause a lot of unexpected non-determinism when used blindly.
Even ignoring the shared_ptr abuse, at least for allocating and freeing many small objects Java would most probably be (a lot?) faster than non-optimized allocations and frees in native binaries. But in my case it was legacy code running on an embedded device.
