What extension do you use in vscode to connect it to local llama.cpp? Or do you auth with github copilot and then point to localhost? Or something else?
HN user
fitzn
VP, AI and Architecture at SmartBear (smartbear.com)
Co-Founder at Reflect S20 (https://reflect.run)
The problem with IPv6 jokes is that very few people are making them.
Boom
Non-Linear Compression! We had a tiny idea back in the day in this space but never got too far with it (https://www.usenix.org/conference/hotstorage12/workshop-prog...).
I am pumped to see this. Thanks for sharing.
Yep - agreed. Thanks!
Just making sure I understand the "one round trip" point. If the client has chained 3 calls together, that still requires 3 messages sent from the client to the server. Correct?
That is, the client is not packaging up all its logic and sending a single blob that describes the fully-chained logic to the server on its initial request. Right?
When I first read it, I was thinking it meant 1 client message and 1 server response. But I think "one round trip" more or less message "1 server message in response to potentially many client messages". That's a fair use of "1 RTT", but took me a moment to understand.
Just to make that distinction clear from a different angle, suppose the client were _really_ _really_ slow and it did not send the second promise message to the server until AFTER the server had computed the result for promise1. Would the server have already responded to the client with the result? That would be a way to incur multiple RTTs, albeit the application wouldn't care since it's bottlenecked by the client CPU, not the network in this case.
I realize this is unlikely. I'm just using it to elucidate the system-level guarantee for my understanding.
As always, thanks for sharing this, Kenton!
Reflect tests mobile apps by converting plain text instructions into appium commands at runtime using AI. Your tests are just the text steps.
https://reflect.run/mobile-testing/
disclaimer: I co-founded Reflect.
It would have been cool to read stories about a few more examples of slingshots, as the author calls them.
The best engineers make more than your entire payroll. They have opinions on tech debt and timelines. They have remote jobs, if they want them. They don’t go “oh, well, this is your third company, so I guess I’ll defer to you on all product decisions”. They care about comp, a trait you consider disqualifying. They can care about work-life balance, because they’re not desperate enough to feel the need not to. And however successful your company has been so far, they have other options they like better.
Yep
I read it quickly, but I think all of the attack scenarios rely on there also being an MCP Server that advertises the tool for reading from the local hard disk. That seems like a bad tool to have in any circumstance, other than maybe a sandboxed one (e.g., container, VM). So, biggest bang for your security buck is to not install the local disk reading tool in your LLM apps.
They won in 3.6 secs, but second place took 3.73 (or 3.74 if being consistent with the winning time). So, did second place also optimize the PoW or were they presumably on an FPGA as well?
The previous submission the author describes as being some expensive FPGA one was 4+ seconds. You'd think he'd mention something about how second place on his week was potentially the second fastest submission of all time, no?
Regarding Internet connectivity regardless of the orbit or location, something like YC co Bifrost Orbital (https://bifrostorbital.com/), might be an option.
This article resonated with me and puts into words some of the feelings I had towards the end of my PhD. This part:
An interesting case in software engineering is dismissal for lack of “evaluation.” It would be, of course, ridiculous to deny the benefits that the emphasis on systematic empirical measurement has brought to software engineering in the last three decades. But it has become difficult today to publish conceptual work not yet backed by systematic quantitative studies.
struck a chord with me. The top-tier CS systems conferences for me (OSDI and SOSP) have gotten to the point where you basically have to be writing the paper about the system you built at a FAANG that serves 1B users daily to get accepted.
It's hard for a novel idea and first-cut implementation to compete with systems built over many years with a team of a dozen software engineers. Obviously, those big systems deserve tons of credit and it's amazing that Big Tech publishes those papers! Credit to them. But it's also the case that novel ideas with an implementation that hasn't seen 1B users yet still have value.
I suppose the argument is that workshops serve that purpose of novel ideas with unproven implementation. There's some truth to that, but as the article highlights, the full conference papers are the real currency.
Thank you very much for writing this up. Good, thought-provoking ideas here.
Doctors, lawyers, teachers and other licensed professionals do continuing education every two or three years. Software engineers are not licensed professionals, so there is no legal standard of quality that all software engineers are guaranteed to have met (and continue to meet). Hence, the interview is an assessment along with all other parts of the application.
Cool stuff. I'm probably missing this, but where in the code are you ensuring that all feature vectors have the same number of dimensions (i.e., length)? From what I can tell, for a text value from sqlite, the code converts each char to a float and stores those bits in the vector. This could work if the hamming distance accounts for different length vectors, but that function appears to assume they are the same. Thanks for the clarification.
What open source model are you using when you hit groq?
I just benchmarked some perf for some of my larger context window queries last week and groq's API took 1.6 seconds versus 1.8 to 2.2 for OpenAI GPT-3.5-turbo. So, it wasn't much faster. I almost emailed their support to see if I was doing something wrong. Would love to hear any details about your workload or the complexity of your queries.
Fun read. It has some similar ideas to https://dedis.cs.yale.edu/2010/det/ but that was actually focused on multicore processing and the communication across cores.
Congrats on the launch.
As mentioned earlier, my needs for analytics are very limited. I think I’d be fine generating statistics based on raw web server logs (like GoAccess does), but I do not have access to those and I don’t fancy running my own web server. (Spoiler alert: it’d have been much easier to do that.)
This is actually what I did here: https://github.com/fitzn/sieve
But your project is much more legit and prettier looking :)
I'm being lazy, but what API does this use? Is it public or "partners" only?
Very cool app.
Reflect | Software Engineer | Philadelphia, PA (onsite) | Full-time | https://reflect.run
Reflect (https://reflect.run) is a no-code testing platform for web applications. Developers and QA testers use Reflect to create end-to-end tests for their web apps, and we let them do it 10x-100x faster than traditional code-based tools. At Reflect, our goal is simple: to be the best platform for end-to-end testing web applications. We're hiring a Software Engineer to join our small, but growing, team in the Philadelphia, PA area.
Your day-to-day responsibilities:
- Build and maintain features in our product areas:
- Cloud-based browser to translate user actions into tests (Scala and Typescript)
- Intuitive UIs to manage and orchestrate tests (Typescript and HTML/CSS)
- Synthesize customer feedback and propose technical designs for new features- Own the design, implementation and maintenance of one or more product features
- Respond to live site incidents with the rest of the team
---
To Apply: https://www.workatastartup.com/jobs/46431
---
What we value in our employees:
- Intelligence - we're solving a hard problem that requires deep analytical thinking
- Humility & Flexibility - we're a small company and everyone wears multiple hats
- Work Ethic - everyone can identify and solve problems on their own
- Communication - we're moving fast and interdependent; we must proactively communicate
Learn more about Reflect: https://reflect.run
This is wild.
The initial comment was related to attribution for "who built" some piece of software based on lines of code. The analogous argument would then be assigning attribution for the built aircraft to whoever produced the heaviest components. Given that that would be illogical, I think the analogy is apt.
If you're like me and have never heard of soundhound, here is their site: https://www.soundhound.com/
I guess it's an API to add Siri-like voice control to your app.
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
- Bill Gates
If you're into risk, then an awesome book is Against the Gods, by Peter Bernstein.
The key points from the article for explaining this phenomenon:
The exit values in VC have increased significantly over the last decade leading to escalating entry values. That makes sense. But the two things that have not changed materially over the last decade are the dilution from seed to exit and the power-law distribution of outcomes in an early stage portfolio.
And a little before that:
If you believe your top-performing investment, out of 100 investments, will end up being worth $100 billion, then the numbers change a lot. You end up with a 13x fund instead of a 1.3x fund, before fees and carry.
So, VCs are still just doing the math like they always have. The rate of $1B companies being created today is 10x (? I don't know) higher than it was a decade ago, so the rate of $100B is probably going to be higher. A single $100B company in your portfolio of 100 companies makes it all work (really work). Still a lot has to go right from seed to $100B, but that's no different. There might be more money available in VC today. Feels like pop culture and society in general is much more interested in start-ups, VCs, etc. Maybe that's my bubble, though.
I totally agree, and this jives with my feeling that no-code is an evolution or a codification of the best practices and principles "hammered out" as you say over the years by regular software development.
I do think it's a major shift but not in a mutually exclusive way, and maybe not a "paradigm" shift. I think initially, no-code tools were touted as being for non-developers. But now there is a realization that no-code tools are more like "automation" for completing a task. In that mindset, anyone (developer or not) can benefit from using them since it can be/should be/is more efficient. To the extent that no-code tools let a non-developer build and test an end-to-end app as their business, I think that's rare today but I would say we're on our way towards it.
I liken the no-code movement to the introduction of a higher-level programming language. For certain tasks, the higher-level language is more than adequate and a developer (or user) who knows nothing about OSes, file systems or networking, can build an application and probably create value and make money. But the higher-level language doesn't replace the lower-level language overnight, and for certain tasks it'll never replace it.
To use the example you mentioned, if you just want to display a webpage for your co-workers that lets them filter a SQL table, it might take you a few minutes to build that in Retool. If there is a class of such webpages or webapps that could make you money, then it's easy to see Retool as a new higher-level language for building those types of apps.
So, my view is that it's not a paradigm shift for building software, but rather the next step on an evolution towards a more automated process of building software.
Disclosure: I founded a no-code web testing app https://reflect.run
This is clever and a great read. Reminds me a bit of finding hashes, for example, that are within a certain Hamming distance to a target value (hash). If the distance you're interested in is small (e.g., 1 bit), then it might be faster to check for 64 exact target values than to check all values for off-by-1 bit. Very cool. Thank you for posting.