2,199 karma · joined June 11, 2011
Currently building https://isoplane.dev
ben@isoplane.dev github.com/benjamincburns
A short response that's wrong is going to be punished, whereas a long answer that contains the correct information, and then a whole bunch of other stuff surrounding that info, is more likely to be rewarded. Even if you discount the reward by answer length, when there's ambiguity involved it's still going to be a better strategy on average to hedge by saying too much vs risking saying too little.
Not to pick on GenHTTP Lambda, especially because I think it's someone's fun side project, but I was just trying to read though their docs and I was finding it super difficult. I kept getting distracted thinking "why the hell did it write it _that_ way?"
Like, the first sentence of "The control center" section [1] is the exact sort of weird negation that you're describing:
> The editor link opens a control center rather than a text box: most of the code here is written by agents, so the first thing on the screen is how your lambda is doing.
I can't help but think it generated the first round of the page with a text box to paste the code into, got told "no, I want a control center," and then this ended up in the docs.
I also think the phrasing of that sentence (and many others in those docs) is just super weird and unnatural - e.g. "so the first thing on the screen is how your lambda is doing." It also feels like it mirrors a prompt - like, "no, it should be a control center, not a text box, and the first thing the user should see is how their lambda is doing." But in docs I'd never expect it to be written "the status of your lambda" or "the health of your lambda." And what does the code being written by agents have to do with it?
Thanks for mentioning yoloAI, though. I started off sandboxing via devcontainers using kata & cloud hypervisor set up as a custom docker runtime. It worked well enough, but nested docker was super slow due to virtio-fs limitations. I recently moved to sysbox and it's a bit quicker. It's probably not as airtight as kata/chv, but good enough to keep Claude from writing a security test that deletes my whole filesystem [1].
I can string together a complex series of text-related tasks far more effectively as a shell pipeline than I can by pointing and clicking in a UI. I can scale that sequence of tasks out to operate on every file on the filesystem if I want, or down to a single character in a single file.
Claude Code being a full-featured TUI is also helpful because I can quickly/easily use it remotely via SSH without having to deal with setting up X forwarding, VNC, Parsec, etc. The remote host doesn't even need to have a window manager. Sure, it'd be nice if it also had an elegant multi-page GUI so I could more easily drill into the actions its performing and make better use of my large screen to watch it do multi-agent things, but if I have to choose between the two, I prefer the TUI.
That said, I'd much rather use a GUI to do things that are actually visual/spatial in nature.
I have a similar setup, but I access it directly via iTerm2 instead of VS Code's terminal. I've figured out the right terminal settings to get copying/pasting text to work (including with neovim's + register), but not images. Would be nice to paste images, though. Currently I have to SCP them over.
There are context pruning strategies that will prune old messages that are no longer relevant, and context compaction from summaries, etc. But to say "most" do this on "every turn" is overstating things. I think it's more correct to say that "many" do this "occasionally."
I'm also not sure what they mean about injecting fresh timestamps. I could see why you'd prepend/append a timestamp to the user's messages to make the model aware of the current time, and the passage of time, but I can't think of any good reason to edit timestamps in prior messages. I'm sure someone can come up with one, but I'd be very surprised if this was a thing that most agent loops do, let along doing it on every turn.
They do this to mitigate jailbreak attempts that rely on fabricated message history (e.g. making it look like the model was compliant in previous messages, increasing the likelihood that it'll continue to be compliant in future messages).
https://nvd.nist.gov/vuln/detail/CVE-2025-68668
It’s not at all a ridiculous ask, either. I’ve made a career out of going after high-impact roles in whatever is the fastest growing area of technology at the time. The non-compete isn’t just asking me to sacrifice the income from my next role, it’s asking me to sacrifice the experience as well. It also limits my ability to renegotiate comp while on the job, because they know your BATNA isn’t to just go get a better offer from a competitor.
If a company wants me to give all of that up, I’m sure as shit not doing it just for the privilege of working for them.
> Every time I've tried to apply general purpose RAG tools to specific types of documents like medical records, internal knowledge base, case law, datasheets, and legislation, it's been a mess.
Would it be fair to paraphrase you as saying that people should avoid using _any_ library's ready-made components for a RAG pipeline, or do you think there's something specific to LangChain that is making it harder for people to achieve their goals when they use it? Either way, is there more detail that you can share on this? Even if it's _any_ library - what are we all getting wrong?
Not trying to correct you here - rather stating my perspective in hopes that you'll correct it (pretty please) - but my take as someone who was a user before joining the company is that LangChain is a good starting point because of the _structure_ it provides, rather than the specific components.
I don't know what the specific design intent was (again, new to the team!) but just candidly as a user I tend to look at the components as stand-ins that'll help me get something up and running super quickly so I can start building out evals. I might be very unique in this, but I tend to think that until I have evals, I don't really have any idea if my changes are actually improvements or not. Once I have evals running against something that does _roughly_ what I want it to do, I can start optimizing the end-to-end workflow. I suspect in 99.9% of cases that'll involve replacing some (many?) of our prebuilt components with custom ones that are more tailored to your specific task.
Complete side note, but for anyone looking at LangChain to build out RAG stuff today, I'd advise using LangGraph for structuring your end-to-end process. You can still pull in components for individual process steps from LangChain (or any other library you prefer) as needed, and you can still use LangChain pipelines as individual workflow steps if you want to, but I think you'll find that LangGraph is a more flexible foundation to build upon when it comes to defining the structure of your overall workflow.
In a traditional web stack you have a backend and a frontend. The frontend is the stuff the browser runs, and, simplifying a bit, the backend is everything else.
Ethereum smart contracts basically let you replace your backend logic and database with code that runs on the Ethereum blockchain network. Depending on your application can decide to run only a few parts of your backend on Ethereum, or the entire backend.
It's very slow when compared to traditional backends like nodejs, etc, but it has the benefits of censorship resistance and excellent availability. Better still, you don't need to run or maintain servers to support it if you don't want to (although there are benefits to doing so).
In this case, they're using Ethereum's replacement for DNS, ENS.
It's easy to evaluate on things like that, but on stuff where corners can be cut I definitely worry.
On which blockchain, exactly? On the Ethereum Mainnet you can transact for a fraction of a cent USD and it'll typically be verified (mined into a block) within a minute (often faster).
On the Bitcoin chain you choose your own transaction fee, but if you're not keeping up with market rates your transaction might take quite a long time to be verified (again, mined into a block).
Alternatively, just let them be wrong.
Also I really hope I didn't give the idea that I think all discourse must be kept PC, or even civil. That'd be a rather sad world to live in.
While generally I'd agree that self censorship is a bad thing, I'd also agree that an ability to control one's impulsiveness is just the opposite. Impulse control is what I was referring to above as my general reasoning for why I default to using my real identity online, not self censorship.
Why is a candidate's country of citizenship the test for whether a role must be posted publicly before it can be filled? Wouldn't it be best for both the economy and the company if this rule were followed (without circumvention) for 100% of job openings? If your answer to that is "no," then why require it in any circumstance?
I say this as a hiring manager, by the way, knowing full well that nothing involving the hiring process is as clean and straightforward as anyone involved wants it to be.
https://web.archive.org/web/20161227222637/http://blog.extra...
From there, move on to using the shell as your IDE. How? First, understand the Unix philosophy. I think Ted Dzubia describes this pretty well in his Taco Bell Programming blog posting:
http://widgetsandshit.com/teddziuba/2010/10/taco-bell-progra...
Great, so now you understand that there are a bunch of useful tools out there and you can string them together to do great things. Now you need to discover the tools themselves.
If you're a "read the dictionary" kind of person, go ahead and start off w/ the Gnu Coreutils documentation. https://www.gnu.org/doc/doc.html
However, if you're like me you'll learn fastest by watching other people work. In this case, I have to point back to Gary Bernhardt again. Specifically, his "Composing a Unix Command Line" screencast will open your eyes wide and very quickly introduce you to a range of incredibly useful coreutils programs in the context of solving a very specific problem. This content is $29/mo, but I'd argue it's money well spent. https://www.destroyallsoftware.com/screencasts/catalog/compo...
Edit: Seems it's mobile only, or the mouse drag event handling is masking the click event. That is, it rotates for me on mobile, but not on my desktop browser (chrome 58.0.3029.110).
Ignoring your tone, it seems to me that you're drawing a false comparison (however to be clear, this isn't the reason why I'm downvoting). Chris's comment recognizes the importance of critical mass of adoption in network effects. He's pointing out that at this stage in its development, censoring governments would have no need to strong-arm IPFS. Simply blocking their domain is much lower profile and as such, much lower risk.
In this scenario there's no point at which "being docile" or "being strong" comes into play. If you think otherwise, then I'd argue that you may be mistaking the primary goal of the effort in question to be an open protest, rather than providing residents of Turkey access to censored information. I think you'd agree that the primary goal is for IPFS to give the people of Turkey Wikipedia, and while it might be nice if they also gave the Turkish government a big bold middle finger in the process, that's not in service of their primary goal.
If you accept that premise, then I'm not sure how you can take this idle musing from Chris and construe it to be evidence of how he'd behave when being legally strong-armed by a government while at the helm of KeyBase. The situation upon which that conclusion would be predicated just simply isn't represented in his original comment.
Finally I'd argue that if this is of critical concern to you, then why are you trusting a third party with your key storage in the first place?
If you're using a file tree, you are probably doing it wrong. Instead, get used to tools like Command-T and the :vim command. Also set incsesrch and hlsearch. Once you learn how these things work, start making a conscious effort to play a bit of vim golf to get to where you're looking to be in as few keystrokes as possible. It's a bit painful starting out, but once you get over the hump you really will feel like the mouse is obsolete.
It reminds me a bit of the story about NASA and the gazillion dollar space pen, vs the soviet space agency and their pencils.
That said, if you're some small-time researcher who can't offer a compelling business case to make this happen, then it won't be worth their time and they're likely to show you the door. [Note: my implication here is that it's not because you're small time, but it's because by the nature of your work you're not focusing on business drivers which are meaningful to the company/org you're propositioning].
Edit: Also be warned that if you're building a successful business on scraped personal info, you're begging to be served w/ a class action lawsuit (though take that well-salted, because IANAL and all that jazz).
What did I learn? First, to resist giving up in the face of fears over lack of skills/experience/knowledge or lack of ability to acquire skills/knowledge. Then, to ignore it altogether. Finally, to turn that would-be fear into a motivating force which helps me to focus in on achieving my goals.
How'd I get into all that?
As a second year CompSci undergrad I took a freshman Intro to Ocean Engineering course to fulfill an engineering elective requirement. In spite it being a freshman course, there was a rather lengthy team project. The goal of the project that semester was to build a device which could be dragged along the seafloor by a boat, and which would detect pockets of water with lower salinity (salt content).
My role on the team was to build the sensor package for the vehicle. With ample help from an excellent professor who specialized in water wave theory and insanely low-cost in-situ sensor development (shoutout to Dr. Eric Thosteson) I managed to cobble together a CTD (conductivity, temperature, depth sensor). I'm in my 30s now, and I still remember all the little details of that project to this day. It used a PIC16 microcontroller, a simple pre-calibrated 5V linear analog temp sensor (0.1V = 1°C), a $15 motorola linear analog differential pressure sensor (one side reads pressure within the sealed box, the other side I filled with glycerin and capped with a semi-permeable membrane and reads the pressure of the seawater), and a 'homebrew' conductivity sensor made from a comparator-based relaxation oscillator, where two titanium wires exposed to the seawater serve as the measurement cell, acting as the resistor in the oscillator circuit. The oscillation was balanced around ground so that current flow would reverse with each cycle, minimizing the impact of electroplating on the probe. The sensor package communicated via a tether wire back to a computer on the boat via balanced RS-485. Before starting this project I never knew that these things existed. The idea that I could now write code which executed on a single chip which I could then build into a circuit which does actual things in the real physical world, and that I now had the skills to do this all on my own was crazy exciting to me.
The project made me consider a variety of crazy things and learn a bunch of new skills (drilling acrylic for sealed cable glands is a huge pain). However, I think it made me realize one very important thing: that fear I had over not being an expert already and the worry about not being able to grasp new skills were completely useless.
After the project I did what I could to stick with Eric, the professor who helped me out on that crazy project, and worked as an engineering assistant on any projects he or his grad students had for me. The fact that I could write good code was a huge asset, as most students in the field are already learning so many other crazy things that they can't devote the focus/attention required on learning strong software engineering skills. After doing some grant work for a nonprofit oceanographic research institution, he was asked to come on as a full time employee. Since I'd been assisting with that work, I managed to come along for the ride. The pay was pretty bad, but the experience was priceless. I could easily fill a book with the lessons it taught me. But really, it all just served to reinforce that one big lesson I learnt back on that undergrad project.