Reddit's one is crazy, I didn't know it exists until I was researching some tax laws in my country. I saw a Reddit thread in my language and it took me a while to realize it's a US-centric subreddit just automatically translated. Translating content about US laws makes 0 sense!
Good chunk of the world already has all of those, so it looks like talking about UBI is right on track there. I suppose countries like USA would need to figure out the basics first though, I agree any basic income seems redundant if one trip to ER wipes out several months worth of UBI anyway
UBI by definition is paid to everyone, regardless of their income. That's contrasted with GMI, guaranteed minimal income, which supplements your current income to some minimal level, which would work as you described
There is no problem. OP said we should be using open _agents_, not open _models_. You can use an open agent with any model, open or closed, while using something like Claude Code locks you in to one model vendor
why are people insisting that an em-dash is exclusive to llms somehow, when on a mac it's super easy to type dash, en-dash and em-dash — just type dash, option + dash or shift + option + dash. I got used to defaulting to em-dash (even if incorrectly) and now I'll be categorized as an llm for that?
I think that's what it always says — even when the business owners submits a change it's just a request, and the actual update is — technically — done by Google.
Even better, the original position of the send button is literally in the place where it shouldn't be, according to Android design guidelines throughout the years. Even Material2 doesn't put the _primary_ screen action on the top app bar, most chat apps (where you _send_ content) have the send button in a different place etc., so obviously the users would find the big-ass button faster if it takes away some 20% of the useful content
Bluetooth audio devices that I use tend to change the protocol as soon as it switches to headset mode (with microphone enabled), which works terribly for music. I imagine the protocol used when the microphone is enabled might have completely different latency characteristics than the one used purely for audio, so a chirp might be measuring completely different thing
Wondering if I'll get corrected, but my _napkin math_ is looking at the model download size — I estimate it needs at least this amount of vram/ram, and usually the difference in size between various models is large enough not to worry if the real requirements are size +5% or 10% or 15%. LM studio also shows you which models your machine should handle
What I don't get is whether the mechanics of selecting letters are supposed to be significant. It's pretty odd to click `a b c`, then missclick `a` again and end up with `b c` which means I have to click `b` and `c` only to go for `a b c d` all over again
Thank you for hints but the answer is about the same as I can find online - it just works with existing tools like Claude app or Cursor or Cline, but I specifically want to understand the mechanisms used and how I can take advantage of MCP servers using _local_ llms.
Personally I try to disable GPS in my smartphone when hiking unless I need to check the maps — I prefer to have my communication device not dead when I need it, and modern smartphones are terrible with battery life
This seems like a good thread to post — can someone give an intuitive explanation of how MCP is supposed to work? I tried to set it up with LM Studio and a local LLM but couldn't for the life of me figure out what I actually need to do. MCP servers seems straightforward, I guess I need an MCP client somewhere, but I'm lost on how the LLM actually knows what tools are available and how/when a translation between "get x from external tool y" translates to actually getting `x` and how the LLM can then use it.
From what I could find online, it just works in Claude desktop app and there are some online efforts for mcp clients, but even ollama maintainers are confused about the implementation (https://github.com/ollama/ollama/issues/7865)
> not the best choice for cpu-bound work, which is likely what you're running into with pandas
I'm not a Python user, why is it not good for cpu-bound work? I see the defaults assume some I/O work, but with `max_workers=~cpu_count` it should be what typical dispatchers for CPU-bound work do in other languages
I wish Github didn't just purge entire repositories/accounts in the event like this, although I know why they do this. But there's now no way to analyze the repository/exploit anymore
Is there a way to set it up to work without any cloud features at all? The docs for local llm say
> Some features may use a custom model like Apply, Autocomplete, Agent, so these proxy settings won’t be relevant, and your code will be sent to Firebender servers for processing.
Which suggests that there's always some cloud component? How usable is the plugin with fully local setup?
I agree with ArtemZ — I get the rule but it's a shame because it prevents calling out companies posting the same job over and over, who don't have basic decency to respond, let alone give feedback, to applicants.
> I find that absolutely insane, if you cannot hold a basic conversation about your life without using AI then something is terribly wrong.
I'm genuinely curious what questions you ask during the behavioral interview. Most companies ask questions like "recall a time when..." and I know people who struggle with these kinds of questions despite being good teammates, either because they find it difficult to explain the situation, or due to stress. And recruitment process is not a "basic conversation" — as a recruiter you're in far more comfortable position. I find it hard to believe anyone would use an LLM if you ask them question like "what were your responsibilities in your last role", and I do see how they might've primed the chat to help them communicate an answer to a question like "tell me about a situation when you had a conflict with your manager"
> ... You may opt out of receiving any, or all, of these communications from us by following the unsubscribe link or the instructions provided in any email we send.
I wish Garmin worked on their SDK and documentation — I wrote a quick app for personal use, and it made me appreciate folks who write Garmin watch apps much more. The documentation is incredibly bad, half the things I had to figure out using trial and error, and even then I wouldn't know how to build/test for other watches than the one I own. I'd have gladly worked on the app and put it in the store, I think it'd useful to some people, but I'd have to put far more effort than it's worth.