Yes and no.

If you run task manager or something in Proton? It just shows Proton processes:

But all linux process, and tons of information about them, are readable in the /proc directory. They’re just files, accessible to the program.

Try ls /proc yourself.

There’s nothing stopping anti cheat from checking that, if it’s configured to do it.

…Are any actually checking /proc?

Shrug.

I wouldn’t be surprised, though. Anticheat devs are aware of linux cheating software.

I answered below already, but Windows infostealers and spyware can absolutely work in proton.

It’s no security beyond some file paths being different, from the software’s point of view.

What I tend to do is run dedicated partitions for games and other entertainment, where I could wipe them without consequence, and if they got infected with infostealers or spyware there wouldn’t be anything to get anyway.

And then the partition where anything sensitive is done/saved (like finances) is separate and inaccessible to that boot.

Well that’s conflicting because at least one other user said that the spyware doesn’t function well enough to work as intended in Proton.

It absolutely can.

There are real instances where I could’ve run Windows infostealer malware via WINE that would get my stuff.

What you’re hoping is for it to malfunction on accident, basically. That might happen. But hope is not security.

If you’re worried, you can fence off file access to programs in Linux.

Encoder-decoder language models and all sorts of stuff were used for translation and spellcheck, long before “LLM” was in anyone’s vocabulary. Embeddings models were used in documentation searches, in IDEs, and other places. Whenever you used any search engine, pre Sam Altman, you were likely hitting text models too.

They worked alright.

It was not an issue. No one hated them; they are simple tools with a specific function.

I think people need to be careful of spilling (quite reasonable) hate of Tech Bro AI into the wider, older field of machine learning. In spite of the effort to conflate them, they aren’t the same thing.

I think this is what “want an EV, research it heavily” folks tend to end up with, where Teslas leans more “want an EV, don’t research it quite as heavily” crowd.

Not that either brand makes bad cars.

I just mean the Hyundai/Kia EVs are less “sexy” on the surface. Their charge and range is lower, but if you look into it, it’s an engineering compromise for faster charging. Hyundai isn’t a very “glamorous” brand, but their recent cars have been excellent, and if you actually look into Tesla, well… gestures at X. Lower end Teslas are priced somewhat attractively and tend to have better resale value than Hyundai at the moment, and it’s quite rational to assume “well, they’ve been making EVs longer.” But if you research it, Teslas have a more hidden costs over time, and even though some systems like the heatpumps are less refined than Teslas, Hyundai engineered the heck out of the car.

That makes sense. The image host I used is pretty unreliable.

Which is the second issue. No image hosts even support JXL or AVIF, except catbox.moe, which is down now! It’s infuriating.

What platform is that, out of curiosity? Im pretty sure everything should load an AVIF.

Om Android, or iOS?

JXL is working alright for me.

As an example with a lot of dynamic range, here’s a JXL:

AVIF:

Both render in my desktop and iPhone browsers, just fine. I bet at least one renders for you. And I made them from RAWs from a really old camera!

The problem is, as you say… arbitrary lack of support. As an example, I can’t upload either file to Lemmy. Brand new social media software, and it doesnt’ recognize JXL or AVIF as valid image types, even though they should render just fine? Most image hosts wont take JXL either, hence I had to upload them to litterbox since catbox is down!

An HEIF, on the other hand, has basically 0 support outside of Apple:

All three of these render correctly on my phone, but only the top two do on other devices.

All the HEIC files from my camera are still busted.

To be fair, its a tricky issue. Its camera makers’ fault for using a format no one else wants to touch, and rendering them as HDR files instead of SDR with gain maps, as is standard practice for smartphones.

…But still, its annoying. They render fine on my iPhone, on Windows, or KDE Linux, out of the box. But they’re completely garbled in Immich :(

Vibecoded self promo is a growing, specific spam problem though.

And a appreciable fraction of Lemmy/Piefed is “anti AI absolutist.”

I think that’s pretty unique.

Be sure to try the ik_llama.cpp fork. Basically, it specializes in MoE CPU offloading on Nvidia cards, and more efficient quantization types than mainline llama.cpp:

https://github.com/ikawrakow/ik_llama.cpp/

And see this repo for specific 3090 configs: https://github.com/noonghunna/club-3090

Honestly I should just write up my general setup in this community too.

Because, with a cursory glance, it doesn’t always look like spam.

A classic example I see starts with “I built a…” in the title, has a wall of text in the description, and actually promises to do something interesting. Only upon deeply inspecting the code (or trying it yourself)… it becomes clear it’s hallucinated nonsense.

And it’s not always malicious, either. A lot of devs get deep in AI psychosis and truly believe they’ve building something revolutionary with their vibe coding agent.

And sometimes these projects are interesting!

Hence it would be EXTREMELY helpful to have this tagged, up front. To me, an [AIP] is gigantic red flag to warrant extra caution, but not necessarily a smoking gun, and would help “regular” homebuilt projects stand out from the vibecoded ones.

And [AIT] is just nice to have. Some users don’t want to see any AI in /c/selfhosted, period. Hence AI discussion posts get reported as spam because people interpret it as spam, and this would clarify that nebulous distinction, while giving those users a way to easily filter AI posts out.

Normally I’d agree, but the tagging rule won’t affect the majority of posts. I think it’s an acceptable complication, in this case.

Especially with how much vibecoded spam is in the horizon.

Vibecoded spam is deliberately engineered to look “high effort,” so even with the vagueness of such a rule, it wouldn’t cover the spam so well.

Failure to provide a disclosure after using the tag would mean removing the post. It could be locked, but I would have to assume the majority of the spam-type postings that happened to make it past the rule 7 criteria are the ones who will not provide the requested disclosure. I think it makes for a good filter this way, but please comment if you think otherwise.

Sounds reasonable to me!

I think the major choice is for y’all (the mod team), as enforcing a tagging system is going to increase the moderation workload. Though I guess it would cut back on AI reports, like you said.

I have no recommendations for an existing bot.

…You could use an embeddings model for a little extra automation though.

This is a pre-LLM thing, but basically you could feed a script new untagged posts, use a embeddings model to compare the text of their bodies to a keyword (“AI”?), and spit out a number as a rough “similarity” metric. If it’s above a certain threshold (eg if the post seems AI related), send a message to the moderation team to check it, or maybe even post a rules reminder in the comments.

And FYI, embeddings models are tiny, so it doesn’t need special resources to run or anything.

They 100% do. They’re probably serving “naive” FP8 via VLLM, which is worse than you’d think, especially if they flip on the awful FP8 KV cache.

In a local quant, you can stop quantized models from falling apart at higher CTX by leaving the attention heads at a higher quantization. As an example, with MiMo 2.5, I have all the MoE MLP layers at IQ3_KT, the dense experts at Q6K, but all the attention layers at Q8_0.

For Qwen 27B, I’m still experimenting, but leaning towards IQ4_KT for the MLPs, Q6K for attention, and Q8_0 for the small, very sensitive KV heads. Or a similar scheme as an exl3 quant.

That being said, sometimes even unquantized models fall apart in certain long context scenarios because the max advertised context is a lie. You just have to test them and see, but Qwen has certainly done this in the past.

As always, the game plan seems to be “disrupt, own the market, enshittify”.

But with a slimy veneer of SEO/engagement spamming as the primary business strategy.

It’s drops off, but not as much as you’d think.

MiMo uses 5:1 SWA, so its long-context compute doesn’t increase as catastrophically as older models. That, and most of the “slowness” comes from the MoE layers being on CPU (whereas the attention layers that get heavier at high context are all on the 3090).

That’s the beauty of these MoEs: they’re just the right size for the “compute-lite” parts to stay in CPU RAM.

I will measure it tomorrow. It is a constant ~9-10TPS for short queries, but definitely slower near my current max context of 85K.

And do you mean prompt compaction? I don’t automate that; when I use that particular model, I tend to use it in Mikupad, aka “raw” notepad mode, and manipulate the context directly. This is so I can do things like chop out conversations, pick different tokens from the logprobs, or edit its own replies/thinking and continue mid reply.

I like manually handling this because, being a local model, prompts are cached. Streaming starts quickly if most of the prompt stays cached, which is actually a really nice advantage over APIs.

Goood clanker. Pats my desktop.