81 karma · joined June 23, 2017
Vibes are not a meaningful comparison.
You can't compare different quantizations(Q4_K_M & Q4_K_XL) and also use a temp of 0.7 and use that for any meaningful comparison.
All difference you notice could be either due to temp randomness or quantization differences even if the original weights are exactly the same.
Also these were likely sourced differently so the quantizers could've used different quantization importance matrizes or process.
The weights are the same, the weights are all that matters.
Never heard about that.
llama-server --model-url "https://huggingface.co/bartowski/DeepSeek-R1-Distill-Qwen-32B-GGUF/resolve/main/DeepSeek-R1-Distill-Qwen-32B-IQ4_XS.gguf"
Will get you up and running in one single command.Still a bit of an annoyance, but one I don't notice once it's set up.
Port forwarding works and you can get a raw wireguard config to dockerize it.
For general use in e.g. open hotspots I still use mullvad/mozilla vpn as I trust them more. (And can pay cashfor mullvad)
Others might be good, but no idea who exactly, many small unknown companies in the list that could be either great or shitty.
Auth-codes given on the website were expired and they took 2 weeks to give me the correct ones near the end of the registry period.
Support was extremely unresponsive. As this this was a side project I couldn't spent time on every day my domain went into quarantine for a short time. They answered 2 days before the end of the rental period, when requesting the auth codes ~2.5 weeks before.
Will never use them again after this experience.
Porkbun is my new home for most stuff and domains.lt for .lt which porkbun doesn't offer yet sadly.
On any x86 UEFI system I tried i never had any issues at all, but Pi's I remember as a huge PITA...
Or is this just a general ARM issue ?
Also to be productive you have to utilize the rest of the erlang ecosystem, so at least some superficial knowledge in elixir & erlang is helpful for for some use-cases.
Syntactically I actually don't think it's that for off, but I dunno what GP was thinking, maybe that it leans more into functional patterns & sugar for those whereas rust/go can also be used in a procedural style. (Though at least personally I am using way more functional patterns in rust than I expected)
And you can also get an electron-like stack going, that is actually much less bloated than "normal" electron, by using tauri-webview, which uses the OS-provided webview and combining it with one of the many cool rust WASM-based reactive web-ui frameworks, like leptos or dioxus. This gets you compiled sizes of ~10s of MB compared to electrons 100s of MBs.
There's also bindings to a lot of traditional ui libs, like GTK, QT & Tk.
I'm currently going for the 2nd option (with leptos for the web part) as I'm used to the web-stack and am very productive with this approach, but native UI also seems very tempting to dig into further.
Some related links:
He can get pretty heated in arguments on the LKML for sure, but those are arguments between devs, and usually for the benefit of the user.
I still think this way of working out disagreements sucks, but as a user it does not really affect me at all.
And other OS'es abuse their users on a whole other level and I'm quite sore that some of apples/microsofts middle managers can also be quite abusive to their devs behind closed doors, with linux it's just all in the open...
How long did it take to get to that 90% ? AFAIK they first mentioned FSD ~2016(Self-driving itself even earlier).
As the last 20% of work are often 80% of the effort we can estimate that those remaining 10 % take ~ 40% of the time. They've been at it for ~8 years , which gives an expected release of ~ 2029.
We'll see what Waymo and other competition has until then.
It would've probably lead to massive confusion due to users not getting the "nix-way" and it seems like easy hack-ability is part of the steam-decks value proposition.
There's no fundamental difference between input and output tokens technically.
The internal model space is exactly the same after evaluating some given set of token, no matter which of them were produced by the prompter or the model.
The 16k output token limit is just an arbitrary limit in the chatgpt interface.
- 1. use MagiskSU for rooting
- 2. add some modules to bypass SafetyNet/PlayIntegrity (https://github.com/chiteroman/PlayIntegrityFix/releases)
- 3. For especially annoying apps add some modules to hide well-known "root apps" from the applist, so these apps don't know they're installed (https://github.com/LSPosed/LSPosed.github.io/releases + https://github.com/Dr-TSNG/Hide-My-Applist/releases) [I only needed it to get Pokemon-Go to work, banking worked without it]
My local banking apps and even google wallet work mostly fine with these workarounds. Though it breaks every few months, which is then usually quickly fixed with a magisk+module update.
- https://www.meta.com/us/en/quest/accessories/quest-2-control...
- https://www.meta.com/us/en/quest/accessories/quest-touch-plu...
On the software side they have been pretty great with support IMO, e.g. by adding 120Hz to the Quest 2 quite some time after release and opening up the Oculus GO, after they discontinued it. Maybe not valve-level but definitely much more than I expected from meta, and their hardware was a third of the price of valve's, despite having an actual APU in them!
It's not and it shouldn't be, but it is most definitely required if you want to criticize it's integration into the kernel due to its supposed flaws/merits in a "technical" discussion.
Nobody is forcing anyone to learn rust, the RiL folks are fine with maintaining bindings and handling the fallout of C API changes. They didn't even get to say that, because they were shouted at for asking a question.
> If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.
Which is basically exactly what the RiL community is doing. In the posted video you can see them TRYING their best to learn about the undocumented invariants of a C API and getting nothing but flak for it for completely made up reasons. I might be hard to understand, but many of the strongest advocates of rust know C well and are opposed to using it themselves for good reasons. The folks maintaining C API don't have to care much about the rust part, except maybe giving a friendly heads-up when they change API's they depend on, like you would in any kernel development work where you are impacting another subsystem.
Apparently this is too much to ask from some of these C grandpas.
While these guys have undoubtedly made great contributions to Linux and FOSS and I'll be forever thankful for that, some of their behavior towards the RiL community has been appalling and petty. They have been resistant to any sort of change, even if it does not impact them at all, are quick to criticize without any attempt at understanding the efforts and benefits of Rust integration or even making any technically coherent argument. Constructive criticism and open discussion is important, but it should be based on accurate information and a willingness to learn instead of knee-jerk reactions and reacting to people wanting to learn about the API of your subsystem with outright and unwarranted hostility.
Here are some counter-points:
Regulation:
- Very little effort is made to evaluate risk of over-regulating, regulatory capture and counterproductive wrong regulation
- The downside of under-regulating is vastly overemphasized, most arguments boil down to "we have to act FAST now or x BAD thing might happen"
- The risk of over/wrongly regulating is vastly under emphasized with the same FUD reasons.
- according to one of the many straw-men argument in the pod I'm a libertarian against any and all regulation because I criticize possible regulatory capture, I would enthusiastically support regulation that foundation models have to be:
-- given freely to public researchers/academics for in-depth independent safety-research
-- open weighted after a while (e.g. after ~ a year, safety concerns should be mostly ruled out and new generations are out so ROI is already likely there. [e.g. there's NO safety reason at all for ClosedAI to not release gpt-3.5, llama3 is better already])
Proposed FLOP cut-off of SB 1047:
- according to the pod, the cut off is much more advanced than anything currently released.
- The 10^26 FLOP cutoff is way to low, llama-405b is ~4×10^25 FLOPs
- 405B is maybe 20% smarter than 70B, while taking over an order of magnitude more FLOPS to train, the cutoff itself is very likely not much smarter than the current SOTA.
- IMO none of the current SOTA models are very dangerous, but kill switch regulation is.
Kill-Switches:
- SB 1047 is (non-explicitly) calling for kill-switches over the cut-off due to liability of the model creators and market dynamics
- Any kill-switch regulation means a complete dead-end to any advanced open-weights AI. This means that huge corporations and governments will control any and all advanced AI-development. This is top-down control of the maths you are allowed to run on your computer IMO that is Orwellian as fuck.
China:
- mentioning china is FUD 101, it's basically AI's "think of the children"
- If they think they can stop china from building their own advanced LLMs, they're delusional. This regulation might even help them to get there faster. They don't even need to steal, there maybe a year or two behind the SOTA and catching up fast.
I just don't get how so many people on a site with "hacker" in the name want to make it impossible to hack on these things for anyone not employed by the big corporate AI research labs.