11·
4 days agoIt is a bot that identifies CSAM images. They are a very skilled dev. The problem is content recognition on a server. So in abstract, it is the same problem.
- 3 Posts
- 29 Comments
Joined 2 years ago
Cake day: June 9th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Search for posts or contact db0. IIRC they worked with LW admin and others to create a filter for this using a very small AI model. It should be on their Git.
Plan 9
Need max AVX instructions. Anything with P/E cores is junk. Only enterprise P cores have the max AVX instructions. When P/E are mixed the advanced AVX is disabled in microcode because the CPU scheduler is unable to determine if a process thread contains an AVX instruction and there is no asymmetrical scheduler that handles this. Prior to early 12k series Intel, the microcode for P enterprise could allegedly run if swapped manually. This was “fused off” to prevent it, probably because Linux could easily be adapted to asymmetrical scheduling but Windows would probably not. The whole reason W11 had to be made was because of the E-cores and the way the scheduler and spin up of idol cores works, at least according to someone on Linux Plumbers for the CPU scheduler ~2020. There are already asymmetric schedulers in Android ARM.
Anyways I think it was on Gamer’s Nexus in the last week or two that Intel was doing some all P core consumer stuff. I’d look at that. According to chips and cheese, the primary CPU bottleneck for tensors is the bus width and clock management of the L2 to L1 cache.
I do alright with my laptop, but haven’t tried R1 stuff yet. The 70B llama2 stuff that I ran was untenable for CPU only with a 12700 with just CPU. It is a little slower than my reading pace when split with a 16 GB GPU, and that was running a 4 bit quantization version.
Not unless an http port is open too. If the only port is https, you have to have the certificate. Like with my AI stuff it acts like the host is down if I try to connect with http. You have to have the certificate to decrypt anything at all from the host.
Sorta, you have to install your certificate authority into the browser and it might complain about verifying that but it will still connect with the encryption.
deleted by creator
I mean more like a self signed TLS certificate with your own host manually set in the browser. Then only make the TLS port available, or something like that. If you have access to both(all) devices, you should be able to fully encrypt by bruit force and without registering the certificate with anyone. That is what I do with AI at home.
I’ve half ass thought about this but never have tried to actually self host. If you have access to all devices, why not just use your own self signed certificates to encrypt everything and require the certificate for all connections? Then there is never a way to log in or connect right? The only reason for any authentication is to make it possible to use any connection to dial into your server. So is that a bug or a feature. Maybe I’m missing something fundamental in this abstract concept that someone will tell me?
By default it will break out many things. I use db as an extra layer of containers in addition to a python venv with most AI stuff. I also use it to get the Arch AUR on Fedora too.
Best advice I can give is to mess with your user name, groups, and SELinux context if you really want to know what is happening where and how. Also have a look at how Fedora Silverblue does bashrc for the toolbox command and start with something similar. Come up with a solid scheme for saving and searching your terminal commands history too.
3·1 month agoYou can use the fedora direct sources to search their discourse forum. Google and Microsoft are likely warping your search results intentionally to drive you back onto Windows. Search is not deterministic any more. It is individually targeted.
I have never used KDE much, so I have no idea. You are probably looking for KDE settings. These would likely be part of gsettings in GNOME. That is not really a fedora thing. You need to look in the KDE documentation. This is the kind of thing that gets easier with time but can be frustrating at first.
Sorry I’m not more helpful than this. It is 2am in California and I didn’t want to leave you with no replies at all.
I’ve tried 3 times so far in Python/gradio/Oobabooga and never managed to get certs to work or found a complete visual reference guide that demonstrates a complete working example like what I am looking for in a home network. (Only really commenting to subscribe to watch this post develop, and solicit advice:)
https://invent.kde.org/graphics/okular
I like Okular’s ability to scan and convert tabled data in PDFs too. There is an option to turn off DRM nonsense. That can do page edits and stuff. If you want to create pages with images you need an office suite.
I missed Odin 3 for a few years until I switched to Graphene and never looked back. In tried the FOSS package it didn’t work for me and the documentation was beyond my skills at the time.
I miss the stupid people comradery, sometimes. People act funny when you’re a normal stupid person and use Linux without the hoodie and a Matrix screen saver.
No. AFAIK the primary issue is that microcode is not open
I’ve had this happen with AI stuff that runs in a Python venv. It only happens with apps that use multi threading, and usually when something is interrupted in an unintended or unaccounted for way. I usually see it when I start screwing with code stuff, but also from changing the softmax settings during generation or crashing other stuff while hacking around. There may be a bug of some kind, but I think it likely has more to do with killing the root threading process and leaving an abandoned child that doesn’t get handled by the kernel process scheduler in the standard way. If this happens I restart too.
No one has fully open source bios, not even S76 last I checked
Wow:
Oleksiy Protas
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.
Serge Semin
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)
Abstract solutions for content recognition with a bot on a server is not a platform specific issue. The dev is skilled and likely on Matrix too.