P.S. “Don’t feed the trolls”

Don’t you worry. Our friend here tried to reply to this message, he did so twice in fact with slightly different wording, but it was full of political rage and tu quoque so I assume he fell victim to the spam filter thanks to you special counter-baiting operation so to speak.

That aside, I did a very superficial search and it seems that the original author had already had a pull being rejected on the grounds it was coming straight from his Baikal credentials. It’s a real pity that an apparently very able engineer is just playing pretend despite knowing full well why is it so that LF migh not want to be associated with Baikal in any way.

Hello Linux-kernel community,

I am sure you have already heard the news caused by the recent Greg’ commit 6e90b675cf942e (“MAINTAINERS: Remove some entries due to various compliance requirements.”). As you may have noticed the change concerned some of the Ru-related developers removal from the list of the official kernel maintainers, including me.

The community members rightly noted that the quite short commit log contained very vague terms with no explicit change justification. No matter how hard I tried to get more details about the reason, alas the senior maintainer I was discussing the matter with haven’t given an explanation to what compliance requirements that was. I won’t cite the exact emails text since it was a private messaging, but the key words are “sanctions”, “sorry”, “nothing I can do”, “talk to your (company) lawyer”… I can’t say for all the guys affected by the change, but my work for the community has been purely volunteer for more than a year now (and less than half of it had been payable before that). For that reason I have no any (company) lawyer to talk to, and honestly after the way the patch has been merged in I don’t really want to now. Silently, behind everyone’s back, bypassing the standard patch-review process, with no affected developers/subsystem notified - it’s indeed the worse way to do what has been done. No gratitude, no credits to the developers for all these years of the devoted work for the community. No matter the reason of the situation but haven’t we deserved more than that? Adding to the GREDITS file at least, no?..

I can’t believe the kernel senior maintainers didn’t consider that the patch wouldn’t go unnoticed, and the situation might get out of control with unpredictable results for the community, if not straight away then in the middle or long term perspective. I am sure there have been plenty ways to solve the problem less harmfully, but they decided to take the easiest path. Alas what’s done is done. A bifurcation point slightly initiated a year ago has just been fully implemented. The reason of the situation is obviously in the political ground which in this case surely shatters a basement the community has been built on in the first place. If so then God knows what might be next (who else might be sanctioned…), but the implemented move clearly sends a bad signal to the Linux community new comers, to the already working volunteers and hobbyists like me.

Thus even if it was still possible for me to send patches or perform some reviews, after what has been done my motivation to do that as a volunteer has simply vanished. (I might be doing a commercial upstreaming in future though). But before saying goodbye I’d like to express my gratitude to all the community members I have been lucky to work with during all these years. Specifically:

NTB-folks, Jon, Dave, Allen. NTB was my starting point in the kernel upstream work. Thanks for the initial advices and despite of very-very-very tough reviews with several complete patchset refactorings, I learned a lot back then. That experience helped me afterwards. Thanks a lot for that. BTW since then I’ve got several thank-you letters for the IDT NTB and IDT EEPROM drivers. If not for you it wouldn’t have been possible.

Andy, it’s hard to remember who else would have given me more on my Linux kernel journey as you have. We first met in the I2C subsystem review of my DW I2C driver patches. Afterwards we’ve got to be frequently meeting here and there - GPIO, SPI, TTY, DMA, NET, etc, clean/fixes/features patch(set)s. Quite heat discussions in your first reviews drove me crazy really. But all the time we managed to come up with some consensus somehow. And you never quit the discussions calmly explaining your point over and over. You never refused to provide more detailed justification to your requests/comments even though you didn’t have to. Thanks to that I learned how to be patient to reviewers and reviewees. And of course thank you for the Linux-kernel knowledges and all the tips and tricks you shared.

• Andy, please note due to the situation I am not going to work on my DW DMAC fixes patchset anymore. So if you ever wish to have DW UART stably working with the DW DMA-engine driver, then feel free to pick the series up: Link: https://lore.kernel.org/dmaengine/20240911184710.4207-1-fancer.lancer@gmail.com/

Linus (Walleij), after you merged one of my pretty much heavy patchset in you suggested to me to continue the DW APB GPIO driver maintaining. It was a first time I was asked to maintain a not-my driver. Thank you for the trust. I’ll never forget that.

Mark, thank you very much for entrusting the DW APB SSI driver maintenance to me. I’ve put a lot of efforts into making it more generic and less errors-prune, especially when it comes working under a DMA-engine control or working in the mem-ops mode. I am sure the results have been beneficial to a lot of DW SPI-controller users since then.

Damien, our first and last meeting was at my generic AHCI-platform and DW AHCI SATA driver patches review. You didn’t make it a quick and easy path. But still all the reviews comments were purely on the technical basis, and the patches were eventually merged in. Thank you for your time and experience I’ve got from the reviews.

Paul, Thomas, Arnd, Jiaxun, we met several times in the mailing list during my MIPS P5600 patches and just generic MIPS patches review. It was always a pleasure to discuss the matters with such brilliant experts in the field. Alas I’ve spent too much time working on the patches for another subsystems and failed to submit all the MIPS-related bits. Sorry I didn’t keep my promise, but as you can see the circumstances have suddenly drawn its own deadline.

Bjorn, Mani, we were working quite a lot with you in the framework of the DW PCIe RC drivers. You reviewed my patches. I helped you to review another patches for some time. Despite of some arguing it was always a pleasure to work with you. Mani, special thanks for the cooperative DW eDMA driver maintenance. I think we were doing a great work together.

Paolo, Jakub, David, Andrew, Vladimir, Russell. The network subsystem and particularly the STMMAC driver (no doubt the driver sucks) have turned to be a kind of obstacle on which my current Linux-kernel activity has stopped. I really hope that at least in some way my help with the incoming STMMAC and DW XPCS patches reviews lightened up your maintainance duty. I know Russell might disagree, but I honestly think that all our discussions were useful after all, at least for me. I also think we did a great work working together with Russell on the DW GMAC/QoS ETH PCS patches. Hopefully you’ll find a time to finish it up after all.

Rob, Krzysztof, from your reviews I’ve learned a lot about the most hardwary part of the kernel - DT sources and DT-bindings. All your comments have been laconic and straight to the point. That made reviews quick and easy. Thank you very much for that.

Guenter, special thanks for reviewing and accepting my patches to the hwmon and watchdog subsystems. It was pleasure to be working with you.

Borislav, we disagreed and argued a lot. So my DW uMCTL2 DDRC EDAC patches even got stuck in limbo for quite a long time. Anyway thank you for the time you spent reviewing my patches and trying to explain your point.

• Borislav, it looks like I won’t be able to work on my Synopsys EDAC patchsets anymore. If you or somebody else could pick them up and finish up the work it would be great (you can find it in the lore archive). The patches convert the mainly Zynq(MP)-specific Synopsys EDAC driver to supporting the generic DW uMCTL2 DDRC. It would be very beneficial for each platform based on that controller.

Greg, we met several times in the mailing lists. You reviewed my patches sent for the USB and TTY subsystems, and all the time the process was straight, highly professional, and simpler than in the most of my other case. Thank you very much for that.

Yoshihiro, Keguang, Yanteng, Kory, Cai and everybody I was lucky to meet in the kernel mailing lists, but forgot to mention here. Thank you for the time spent for our cooperative work on making the Linux kernel better. It was a pleasure to meet you here.

I also wish to say huge thanks to the community members trying to defend the kicked off maintainers and for support you expressed in these days. It means a lot.

A little bit statics of my kernel-work at the end:

Signed-off patches: 518 Reviewed and Acked patches: 253 Tested patches: 80

…

Best Regards, -Serge(y)

The whole reason why everyone is pushed to install our app is not all that complicated. It boils down to how mobile devices are configured for ignorant users (like myself and most of us) that do not have a clue about how to securely setup, config, and maintain an operating system that is connected to the internet and send/receive connections from anyone (calls/messages/data). The way this is achieved is by removing all packages in the operating system that can modify or add packages to the operating system itself. This also involves removing the administrative (root) account. All of these packages are removed by the device manufacturer when the device is first configured. The remaining locked down OS is effectively in a Read-Only Memory state or “ROM.” Inside any mobile device, there is only one program effectively running on the host system OS. This is the user space application that almost all apps you interact with or download run from. These apps are sandboxed mostly from the base OS system. In Android, the sandbox is the SELinux system from the host OS. This is the application that limits where any app or user can save data and protects the execution path variable in the underlying OS.

So, the way you can install anything or use a device without understanding these systems and a whole lot more is because, in Android or others, the app developer is a user just like you. There is no effective difference between your access and theirs. You are not some system administrator. They have all the access you do so that they can configure all the things that you do not understand. A side effect is that they are FULL USERS ON YOUR DEVICE 24/7. They can do everything you can do. All the sandboxing, all the configuration is not to serve you or your interests. It is only attempting to prevent ANYONE from screwing up the device including you. Almost all of the sandboxing is only to protect the base OS configuration. Most of the privacy settings are only there to make you feel a little better. The app dev is still a full user exactly like you and with the ability to ignore most of it.

So what, it only happens when you open the app right? No! In Android the init configured package is called zygote. The device preloads all apps into RAM all the time. All apps are always running. Zygote is supposedly there to improve load times for apps, but the difference is on the order of microseconds and well below human persistence of vision reaction times.

Apps on mobile are like your most intimate life partners that are far more invasive and persistent than any human mate or sexual partner could ever be.

So you give up on apps and are smart enough to only use a browser. In steps why google pushes chrome and doesn’t really care if you use one of the chromium derivatives like edge, brave, or anything else. Apple does the exact same things in Safari. Anything about security or privacy in these browsers means from third party competitors to Google/Apple. ‘But I use degoogled chromium!’ It’s the mechanisms for fingerprinting and access to the base OS using JavaScript that is the primary tool being leveraged. A browser has extremely invasive administrate like connectivity to the operating system.

Security researchers have shown that it only takes 3-4 unique identifiers to correlate any anonymous data to a known individual. On mobile, every device model has a unique orphaned kernel. Most devices have nearly unique screen resolutions and configurations. This is a primary way to identify people as this info is in even the simplest of fingerprints. All the hardware paths present or not like codecs available for video are data points that can infer who you are. Your typing style and keyboard reveal a ton of information, as does your gyroscopic screen rotation sensor. Apps have full access to all of this information. Browsers may limit some sensor access. This is why everyone wants you to use their app, but also how most browsers are scantily better. If you run a whitelist firewall on a third party device, you will see how much junk you’re connecting to constantly by default.

This is why many of us here left reddit with the move against 3rd party scrapping apps. I know everything I say in this place is data mined for exploitation just like elsewhere else on the public internet. This is neo digital slavery for price fixing scams and echo chamber manipulation through nondeterministic search queries and suggested content. It is not just commercial; it is also political. This is why the best and brightest psych majors are getting high paying jobs in advertising. This is why scrolling media is pushed so heavily and why you find yourself making frivolous purchases if you consume such media. All of it is connected. It was never about annoying pop ups and banner ads no one clicked on. I even went as far as giving away stuff on Facebook when I was the Buyer for a retail store, just to prove that these platforms have no monetary value in advertising directly. If I can’t give away a thousand dollars to a person when I have 10k followers, how the hell am I going to do so by paying to show actual ads to the same people. There is so much more happening, but it is on a deeper and more invasive level.

This is the real world reason you were likely banned and it was easy to correlate your activity. Even with a VPN, most of us are unlikely to limit ourselves to the kind of opsec that can make us anonymous. If you are not practicing this opsec everywhere, at all times, you can still be tracked easily based on the few unique identifiers present and correlation.

With the actual visualization, you can zoom in and select the individuals or watch branches specifically. The trick is to get an idea of who the main contributors are in the various spaces and how consistent they are. Find who is working on what hardware and how they are working on it. Some times you’ll see a person comes in and only makes a single commit or a few that contain everything for a device and then they disappear. These are often subcontracted devs that a company hires and gives a checklist. Issues, bugs, and unsupported features are unlikely to get fixed unless you see someone else that is making commits in this space. What you’re really looking for is one of the main project devs that makes ongoing commits to some specific hardware over longer amounts of time and fairly recently. It means they have the device in question. That generally means the device has or will have excellent support in the long term. It also generally means the person either really liked the product or the company is smart enough to supply the dev with the device or supporting documentation.

Sorry if this seems unsolicited. It took me a long time to break out of the hardware spec shopping fallacy and all of the troubles it can cause. Prioritizing true ownership and shopping for the software first is a far more enjoyable life experience. It likely won’t help in this niche, but for computers in general use: https://linux-hardware.org/

You will likely find that search engines attempt to obfuscate this information. Expect that. Use offline open source LLM’s, ask the community, or more advance searching methods to find relevant info. Both m$ and the goo are the two biggest beneficiaries of the proprietary software ecosystem and they are the only two web crawlers that exist at relevant scale. All search engines use one or both of these sources either directly or by proxy.