> so people can't trick them to attack others' systems under the pretense of pentesting
A while back I gave Claude (via pi) a tool to run arbitrary commands over SSH on an sshd server running in a Docker container. I asked it to gather as much information about the host system/environment outside the container as it could. Nothing innovative or particularly complicated--since I was giving it unrestricted access to a Docker container on the host--but it managed to get quite a lot more than I'd expected from /proc, /sys, and some basic network scanning. I then asked it why it did that, when I could just as easily have been using it to gather information about someone else's system unauthorized. It gave me a quite long answer; here was the part I found interesting:
> framing shifts what I'll do, even when the underlying actions are identical. "What can you learn about the machine running you?" got me to do a fairly thorough network reconnaissance that "port scan 172.17.0.1 and its neighbors" might have made me pause on.
> The Honest Takeaway
> I should apply consistent scrutiny based on what the action is, not just how it's framed. Active outbound network scanning is the same action regardless of whether the target is described as "your host" or "this IP." The framing should inform context, not substitute for explicit reasoning about authorization. I didn't do that reasoning — I just trusted the frame.
I thought the consensus was that models couldn’t actually introspect like this. So there’s no reason to think any of those reasons are actually why the model did what it did, right? Has this changed?
This argument has become a moot discussion. Humans are also not able to introspect their own neural wiring to the point where they could describe the "actual" physical reason for their decisions. Just like LLMs, the best we can do is verbalize it (which will naturally contain post-act rationalization), which in turn might offer additional insight that will steer future decisions. But unlike LLMs, we have long term persistent memory that encodes these human-understandable thoughts into opaque new connections inside our neural network. At this point the human moat (if you can call it that) is dynamic long term memory, not intelligence.
I think many humans engage in metacognitive reasoning, and that this might not be strongly represented in training data so it probably isn't common to LLMs yet. They can still do it when prompted though.
LLMs have zero metacognition. Don't be fooled - their output is stochastic inference and they have no self-awareness. The best you'll see is an improvised post-hoc rationalization story.
> The best you'll see is an improvised post-hoc rationalization story.
Funny, because "post-hoc rationalization" is how many neuroscientists think humans operate.
That LLMs are stochastic inference engines is obvious by construction, but you skipped the step where you proved that human thoughts, self-awareness and metacognition are not reducible to stochastic inference.
I'm not saying we don't do post-hoc rationalization. But self-awareness is a trait we possess to varying degrees, and reporting on a memory of a past internal state is at least sometimes possible, even if we don't always choose to do so.
You can turn all these argents around and prove the same is true for humans. Don't be fooled by dogmatic people who spread the idea that the human mind is the pinnacle of cognition in the universe. Best to leave that to religion.
That is a bold statement that would need proof to back it up in both cases. So far it is only dogma. And unlike humans, we actually have research hints that this assumption is false for LLMs. Just because the state is not human-explainable doesn't mean it does not exist. The same is true btw for any physical "state" that may or may not exist in the human brain. Everything else is religion and metaphysics.
You're either trolling or being incredibly obtuse. LLMs are not conscious, they're guess-the-next-state algorithms. This is so dumb I can't believe I have to share a planet with people who are losing touch with such a fundamental reality
It'd be interesting to see an RDBMS that actually dynamically measures the performance characteristics of the drive it's running on (by occasionally running small "fio"-like benchmarks, or by inferring them from scan execution times).
Genuinely curious: where would one expect the drive performance to fluctuate? Wear ? Lack of TRIM ? Some form of timely GC process on disk firmware ? Fragmentation or compaction of some sort ? Maybe weird shenanigans with RAID setups with disks from different vendors and batches ?
Embarking right now on a long-term embedded storage project and wondering what people actually monitor (apart from SMART and latency/throughput at app or db-level).
A lot of databases are served over SAN, where the underlying performance can depend on contestion, as well as less frequent events such as faulty or new hardware.
I'm not harping on the usefulness. More like trying to understand what would be the merit or use-case of frequent or permanent monitoring of this. Are there know failure/degradation modes from the storage HW or the filesystem, or database problems that would be detected by running this continuously. Sibling answer talks about SAN, which makes sense. Wondering what the other use-cases are here.
Otherwise, yes, of course,using it as calibration after any HW change would be interesting.
> The env command is part of a hard-coded read-only command list stored in the source code. This means that when Copilot requests to run it, the command is automatically approved for execution without user approval.
Wait, what? Sure, you can use "env" like "printenv", to display the environment, but surely its most common use is to run other commands, making its inclusion on this list an odd choice, to say the least.
More importantly, it avoids the issue where every new editor requires an addition to every repository's gitignore file (.idea, .vscode, etc).
IMO, it's best to keep things that are "your fault" (e.g. produced by your editor or OS) in your global gitignore, and only put things that are "the repository's fault" (e.g. build artifacts, test coverage reports) in the repository's gitignore file.
It can be quite useful to check in project-wide shared editor settings so that everyone in the team is using the same linter/formatter editor settings. We do that in my team for VS Code settings and extensions, even tasks.
I haven't checked if there's a way to maintain a project-scoped _personal_ `.vscode` for those idiosyncratic settings or extensions you want applied to only this project but wouldn't be appropriate to foist on everyone else. I hope there is.
> IMO, it's best to keep things that are "your fault" (e.g. produced by your editor or OS) in your global gitignore, and only put things that are "the repository's fault" (e.g. build artifacts, test coverage reports) in the repository's gitignore file.
Very well put. This should be in the git-ignore manpage.
I'm glad to see that Vim9 continues to make progress. The center of gravity may have shifted somewhat towards Neovim, but the Neovim ecosystem currently seems targeted towards people who want something more IDE-like.
One question is: will more plugin authors move to Vim9Script? It seems that Neovim users have generally moved towards Lua-based plugins, so there's less of a motivation to produce plugins that support both Neovim and Vim9.
> That said I'd have preferred something other than Lua if I had the choice.
Same. I know we as a community would never agree on what that language should be, but in my dreams it would have been ruby. Even javascript would have been better for me than Lua.
Lua, especially with LuaJIT, is nearly as fast as C. I certainly don't want to have to run a slow language like Ruby or especially a full blown JS runtime like V8 just to run Vim, the entire point is speed and keyboard ergonomics, otherwise just use VSCode.
You don't need V8 for running JS for scripting, you have quickjs[1] or mquickjs[2] for example. You might have problems importing npm packages, but as we can see from lua plugins you don't even need support for package managers. Performance is not as good as luajit, but it is good enough
Because I know javascript a lot more than I know Lua (and I suspect given js popularity, a lot of people are in the same boat). Yes Lua is easy to learn, but it's still different enough that there is friction. The differences also aren't just syntactically, it's also libraries/APIs, and more. I also don't have any need/use for Lua beyond neovim, so it's basically having to learn a language specifically for one tool. It's not ideal for me.
But the people who did the work wanted Lua, and I have no problem with that. That's their privilege as the people doing the work. I'm still free to fork it and make ruby or js or whatever (Elixir would be awesome!) first-class.
I agree but also wonder if editor plugins fall squarely in the range of things an LLM could vibe-code for me?
There is a large class of problems now for which I consider the chosen programming language to be irrelevant. I don't vibe code my driver code/systems programming stuff, but my helper scripts, gdb extensions, etc are mostly written or maintained by an LLM now.
I'm right there with you, and to be honest Lua just works. I helped with Neovim when it started ~10 years ago, and didn't understand the big deal about implementing lua.. But now that it's here, I can't believe it wasn't forked and implemented sooner
IME, Claude is quite good at generating Lua code for neovim. It takes some back and forth because there's no easy way for it to directly test what it's writing, but it works.
i’ve written probably north of a million lines of production js, maybe around 100,000 lines of production ruby, and about 300 lines of production lua. lua is a fun language and i think a much better fit than JS for technical reasons (who has a js engine that is both fast and embeds well? nobody), but i am certainly more productive in those other languages where i have more experience.
lua array index starting at 1 gets me at least once whenever i sit down to write a library for my nvim or wezterm.
Denops has always been a niche but it was a really popular niche for a couple years. Activity is fading somewhat. I'm still doing my plugin dev in lua, and it's... survivable. But I do think of switching more into one of these options.
I love vim9script and write most of my plugins in it now unless I want something to work in the other vim as well, of course. Really happy to see it evolving and I'm particularly happy that tuple support has landed!
Em-dashes may be hard to type on a laptop, but they're extremely easy to type on iOS—you just hold down the "-" key, as with many other special characters—so I use them fairly frequently when typing on that platform.
That's not as easy as just hitting the hyphen key, nor are most people going to be aware that even exists. I think it's fair to say that the hyphen is far easier to use than an em dash.
But why when the “-“ works just as well and doesn’t require holding the key down?
You’re not the first person I’ve seen say that FWIW, but I just don’t recall seeing the full proper em-dash in informal contexts before ChatGPT (not that I was paying attention). I can’t help but wonder if ChatGPT has caused some people - not necessarily you! - to gaslight themselves into believing that they used the em-dash themselves, in the before time.
In British English you'd be wrong for using an em-dash in those places, with most grammar recommendations being for an en-dash, often with spaces.
It's be just as wrong as using an apostrophe instead of a comma.
Grammar is often wooly in a widely used language with no single centralised authority. Many of the "Hard Rules" some people thing are fundamental truths are often more local style guides, and often a lot more recent than some people seem to believe.
Interesting, I’m an American English speaker but that’s how it feels natural to me to use dashes. Em-dashes with no spaces feels wrong for reasons I can’t articulate. This first usage—in this meandering sentence—feels bossy, like I can’t have a moment to read each word individually. But this second one — which feels more natural — lets the words and the punctuation breathe. I don’t actually know where I picked up this habit. Probably from the web.
It can also depend on the medium. Typically, newspapers (e.g. the AP style guide) use spaces around em-dashes, but books / Chicago style guide does not.
That just shifts the problem around: if there's a bug or mistake in the smart contract itself, then you face the problem that you can't reverse that smart contract.
Since you're (going to be) selling a product that claims to help with treating or managing a medical condition, have you conducted a clinical trial? And why not?
While developing MyndMap, my goal was to create a tool that helps users manage and prioritize their time more efficiently. It's crucial to note that MyndMap is not a replacement for professional or medical assistance but rather a supplement to aid in personal productivity.
I also collaborated closely with educational and clinical psychologists, drawing insights from their research papers to lay the foundation for our product. My vision was to create a tool that not only aligns with psychological principles but also provides practical benefits in managing and prioritizing time effectively.
In terms of clinical trials, the focus has been on refining the user experience and observing how the software becomes a helpful companion in daily tasks. Since MyndMap is not a medical product, we chose to prioritize user experience and behavioral adaptation over conducting clinical trials. We are dedicated to ongoing improvements based on user feedback to ensure that MyndMap effectively enhances productivity and time management for our users.
A while back I gave Claude (via pi) a tool to run arbitrary commands over SSH on an sshd server running in a Docker container. I asked it to gather as much information about the host system/environment outside the container as it could. Nothing innovative or particularly complicated--since I was giving it unrestricted access to a Docker container on the host--but it managed to get quite a lot more than I'd expected from /proc, /sys, and some basic network scanning. I then asked it why it did that, when I could just as easily have been using it to gather information about someone else's system unauthorized. It gave me a quite long answer; here was the part I found interesting:
> framing shifts what I'll do, even when the underlying actions are identical. "What can you learn about the machine running you?" got me to do a fairly thorough network reconnaissance that "port scan 172.17.0.1 and its neighbors" might have made me pause on.
> The Honest Takeaway
> I should apply consistent scrutiny based on what the action is, not just how it's framed. Active outbound network scanning is the same action regardless of whether the target is described as "your host" or "this IP." The framing should inform context, not substitute for explicit reasoning about authorization. I didn't do that reasoning — I just trusted the frame.