I mean, if your argument is just semantics, that’s just… pedantic.
You could draw that line anywhere. The NPCs I play against in a strategy game could be “intelligence.”
You know what people mean. People are talking about ~anthropic cognition, which is clearly not what’s going on in current LLMs. They can do intelligent things, maybe they are an “intelligent” by some definition you define, but they are not even close to animalistic cognition.
I disagree with most here.
You need to reduce swappiness even more, and tweak some other variables (like the memory “threshold” Linux starts to swap, and disk cache aggressiveness) to stop Linux from swapping so opportunistically under such a light load.
IMO, Linux is configured for “old” systems by default: slow HDDs, and constrained RAM pools, where disk IO really, really needs caching, and where idle background processes take a large fraction of RAM.
You have superfluous RAM for your workload. And very fast disk IO that isn’t such a hindrance to apps anyway. And a disk you don’t want to wear. This is the opposite scenario: you don’t want Linux to swap unless it absolutely has to.
For reference, this is part of my config. It’s rather niche and you probably shouldn’t use it, but you should consider looking up the variables:
# Keep min reserve reasonable for 8GB usable space
vm.min_free_kbytes = 262144 # Lower absolute minimum to 256MB
vm.watermark_scale_factor = 10 # Lower to 0.1% (which is ~128MB on 128GB)
# Disable watermark boosting completely
vm.watermark_boost_factor = 0
# Normal-ish metadata pressure so desktop doesn't stutter on disk reads
vm.vfs_cache_pressure = 120
# Allow reasonable swapping of inactive anonymous desktop pages, could be lower
vm.swappiness = 10
# Dirty bytes limits to limit caching
vm.dirty_background_bytes = 67108864
vm.dirty_bytes = 268435456
# Disable compaction & proactive scans to stop freezing with large portions of RAM mlocked
vm.compaction_proactiveness = 0
vm.compact_unevictable_allowed = 0
vm.page-cluster = 0 # 4kb pages for SSD
My system still uses RAM as disk cache with this config, it just won’t go out of its way to swap just to keep that cache, especially I lower swappiness to 1-3.
I also have a 1GB zram pool, prioritized over ssd swap. But you should make yours even larger (maybe 4GB?). This will intercept anything that does swap first.
I also start some applications with systemd-run and specify memory caps and swap limits (often forbidding them from swapping entirely).
It makes a night-and-day difference for some workloads on my system, that would otherwise swap pointlessly, just tank performance and even de-stabilize the system.
It’s “free ram” until stuff actually goes in swap.
It depends on the scenario, of course. Maybe you have huge, totally idle processes, and active ones working from an HDD that need cache desperately, in which case this is good.
But my experience with Linux is that is waaay to aggressive with this, in most configs, and I get far better performance from configs that avoid swap until it absolutely has to be used.
They “get the job done,” perhaps even provably, but:
It’s less flexible for fighting anti-adblocking.
Hence, it’s more work for Adblock devs/listmakers to maintain.
You can see the UBO devs already complaining/stressing about it. Hence them recently dropping Facebook from their 1st-party lists because they’re tired of fighting paid devs, or increased reports of UBO Lite specific issues.
I think that’s Google’s real intent.
They aren’t trying to kill adblocking, just make it inconvenient enough so the vast majority don’t use it effectively. It’s a form of “soft” censorship, sort of.
You have to launch Chrome with this command-line argument:
--disable-features=ExtensionManifestV2Unsupported,ExtensionManifestV2Disabled
And then, I think you have to re-enable it with config flags as well:
chrome://flags/#extension-manifest-v2-deprecation-warning [Disabled]
chrome://flags/#extension-manifest-v2-deprecation-disabled [Disabled]
chrome://flags/#extension-manifest-v2-deprecation-unsupported [Disabled]
chrome://flags/#allow-legacy-mv2-extensions [Enabled]
I have not tried this personally, though.
As far as I can tell, that paper explores a model’s ability to assess its own future text output beyond what “regurgitating training data” would suggest. It makes sense that it could do this better than an outside model; it’s exploring its inner state with each token, though the test is still interesting.
That has nothing to do with sampling, though.
…Maybe an analogy would illustrate this better. First, I don’t mean to anthrophomorphize LLMs, but the human brain is a good example.
The paper is analogous to asking a human brain to assess its own thoughts and tedencies. Of course it can do this well; it can think conscously and run thoughts through its subconscious parts.
What OP is proposing, is analogous to “tell your eye receptors to see less green.” Or “get your vocal cords to omit a certain frequency when you speak.”
There is no wiring in the human brain to do this. Vocal cords and cells that sense green in the eye are effectively “external machinery” to the brain that it does not have such control over.
LLM sampling is the same.
Tokenization and sampling are external machinery. They are code, hardcoded programming, completely outside the LLM weights. You can’t tell an LLM to alter its own sampling because its literally impossible, and it can’t manipulate its own logit spread mathematically because that’s invisible inner machinery.
Could you do this with custom sampler/logit manipulation code and a tool harness?
Sure. Maybe.
But Claude is not rigged to do that, and a system prompt won’t change that.
…Okay. Technically, that’s true, going by strict semantics.
But the Helium and Ungoogled Chromium are going to lose MV2, soon. I feel like “still supports uBlock Origin” doesn’t sufficiently convey that to Lemmy commenters trying to read the situation. That’s all I meant, though I was perhaps imprecise with my words.
In other words, practically, if a users want to use UBO, they should know these browsers will not support that in the near future even if, strictly speaking, they support it right this second.
I believe this means Brave will lose support too, unless they intend to extensively modify Chromium to maintain compatibility themselves (which would be odd, as Brave doesn’t really need UBO since it has its own adblocking engine?)
True, sometimes. But they don’t have the sheer manpower dedicated to security that Mozilla has, nor the institutional policies that try to mitigate losing a key/account or something like that. Also, technically, vanilla Firefox is first to get the zero-day patches before they filter downstream.
Not that the forks are dangerous or anything, generally.
For a second, I thought this required creators to watch 8000 hours of videos, and felt relief.
It would at least throw up an obstacle for bot/spam accounts. They’d have to make the effort of watching a bunch of videos.
…But no.
Well…
With a fork, one is very dependent on the browser dev. Not just on their benevolence, but on their security practices too. And on them pulling in upstream security patches, quickly.
TBH, this is why I do finance stuff on vanilla Firefox. I love browser forks, I really do, but I’m a bit more cautious with them, too.
First, screw Chrome.
BUT. These headlines are clickbait.
UBO has been disabled in Chrome for a long, long time. This is nothing new. Its old news.
Ublock Lite replaced it, and it’s not going away. It’s inferior and problematic and harder on devs, yes, but unfortunately Chrome users didn’t seem notice.
What’s being disabled is a crazy-difficult-to-enable flag that basically zero Chrome users actually used, and that only (a few) downstream Chromium forks use.
Not for long. The patch that removes support is coming to Vivaldi soon.
The updates aren’t just disabling it anymore, they’re stripping the path out entirely, so it would be difficult to maintain support.
This is not true.
The flag that UnGoogled Chromium used to support it is going away, and AFAIK there is no fix. Helium inherited the same patch from UnGoogled Chromium.
They will both lose support. See their relevant GitHub issues.
Brave uses a custom, integrated adblocking engine; it technically doesn’t need UBO.
The Commedore phone, if you want something minimalistic that does have Android compatibility.
That’s a significant security risk, unfortunately.
If that happens, I’d suggest a fork with a built in blocker, one that still gets security patches from upstream Firefox.
Okay.
I don’t agree. But let’s say I agree.
…Just don’t use Claude?
Use an LLM without a watermark; there are hundreds to pick from.
In other words, if one is going to try to hide automated writing, I think there should be a bare minimum effort to do so. That includes:
Reading/checking the text, to see if it makes any sense.
Actually trying to pass it as human.
90% of slop is brain melting slop because this minimum bar isn’t even met. And all Claude’s watermark would do is catch that bottom of the barrel; it wouldn’t censor anyone.
As an addendum I forgot:
Your idea was actually already implemented:
https://github.com/ggml-org/llama.cpp/pull/9742
XTC is a novel sampler that turns truncation on its head: Instead of pruning the least likely tokens, under certain circumstances, it removes the most likely tokens from consideration.
It’s a very cool idea: it chops off the most likely token when the rest of the sampling indicates it probably can.
In my tests back then, the results were… mixed, but the idea is fascinating.
But you can’t do this with Claude, as its a closed model and their sampling is years behind cutting edge.
See: https://gist.github.com/Hellisotherpeople/71ba712f9f899adcb08b94bce20d5397
That’s like 98% of abuse, though. The vast majority of AI abuse is thoughtless, utter laziness.
Bad actors who actually care about “evading detection” wouldn’t use Claude, anyway.
This won’t fix the inbreeding issue, anyway. The bias is extremely slight, but random, and orthogonal to Claude’s own “slop patterns” and tendencies. And theres tons of other LLM content that will end up in their dataset outside their control.
Besides, as much as Claude accusess others of it, everyone’s training on everyone else’s output and they know it.
I mean… it’s an issue. OP’s system is swapping the SSD when it clearly should not be doing it. My system had horrible usability issues in some scenarios without a lot of reconfiguration, and thrashed my SSD for no benefit.
The default heuristic is not good for our systems, and OP’s situation is a pretty common scenario. That’s a fact. How is that not an issue?
And support for TRIM and whatever else was added for SSD support is not really the issue, here. That’s working fine.