I've had a feeling for a while that there was going to be a war on software based on LLMs controlled by "bad actors." LLMs have gotten really good at finding security vulnerabilities and in the hands of bad actors, it can really ravage the public infrastructure we all rely on. Unfortunately, I've felt like OSS was going to be the first sacrificial lamb so to speak because the code is out there, so easy to identify.

I'm launching zeroquarry.com now for open source maintainers to be able to scan their own code before a bad actor does. Just bring your own LLM key and I'll pay for the hosting infrastructure, development costs, etc for at least the next several months. most scans cost about $5-$20 in tokens using frontier models.

https://youtu.be/bbLYw7j90hA for a demo of how it works

Right now, I'm focused purely on OSS and getting feedback on the product: no option to pay for it. You bring you API key(s), choose your model(s), and run. I've limited the scans to 2x per month for now and 1 concurrent scan at a time by default to try to avoid abuse, but if you're a maintainer of an OSS project and you would like higher limits, just reach out and provide details on your project and I'll bump up pretty much as high as needed. email is shane at the domain

I was going to delay launch until later, but the it's something I've been working on for a few months and the Mythos news really prompted me to move a bit faster. Feedback is generally welcome both here or at the e-mail address above

Comments URL: https://news.ycombinator.com/item?id=47932372

Points: 1

# Comments: 0

Remote: Indifferent. I've worked partially remote from 2015-2025 and in-person before/after. I like both

Willing to relocate: no

Technologies: python, SQL and most major BI tools, javascript, elasticsearch, LLMs and surrounding tooling, various API gateways

CV: https://connelly.casa/?url=/Users/Public/Desktop/Shane%20Con...

LinkedIn: https://www.linkedin.com/in/shaneconnelly/

Email: in the CV

I'm a technologist turned product manager and into product leadership. Most of my career has been leading product teams in complex B2B applied ML/AI and "big data" products. I was product lead for Elasticsearch @ Elastic, Kong @ Kong, Vectara's head of product, and currently CPO @ SPREAD AI. We've recently relocated our family to Australia due to my wife changing positions, and realistically can't be at a company where everyone in the company is in/near Germany except me (the hours just don't work for a company that isn't committed to remote work).

SPREAD builds B2B software for mechatronics customers like cars and defense systems. We help them design, build and diagnose problems with their systems faster. We do it with a combination of a well-designed ontology we've spent years working on as well as AI-based systems. Right now, we're looking for a technical writer and also someone to start our support organization.

Candidates must be in Germany already, though specific location within the country doesn't matter that much

The second time, I pushed strongly and made sure the entire executive team knew that we would be misleading our users. I pointed to the horizon and talked about the problems with "forever" language. I had to push very strongly back on the marketing team to change verbiage and then they silently made updates anyway to add "forever" verbiage. They were eventually fired for this.

But what I find concerning here isn't that the "free" tier went away (it almost always must) but that there's denial and push-back in this set of threads about the verbiage. You made a mistake. Own it and apologize for the verbiage you put out there. Don't deny that it was ever there or argue over pedantic details about where/how that verbiage was placed.

Says "free forever"

SPREAD builds B2B software for mechatronics customers like cars and defense systems. We help them design, build and diagnose problems with their systems faster. We do it with a combination of a well-designed ontology we've spent years working on as well as AI-based systems. Right now, we're looking for a technical writer to join our team that's really forward thinking to own the writing, tooling, and also lead the company in ambitious technical writing.

You can reach me at shane at spread . ai with your resume

I'd be willing to take less battery life to get something like this, but nearly everything that's anywhere close either has no NFC (which means mobile payments are out the door) or doesn't have 5G or just has such an awful camera/processor as to be basically unusable for many every-day tasks.

SPREAD is a software company built to help electromechanical companies (automotive, aerospace, defense) build their products better and faster by bringing together the different data they have into a single system.

We have several of the largest automotive OEMs as customers already and are looking to expand our low-code platform.

https://spread-gmbh.jobs.personio.de/job/456964?language=en&... has job details and you're welcome to email [shane] at our domain as well

If you live directly next to the San Rafael central station, that'd be easiest/fastest. But San Rafael is much bigger than that. I'll get into that in a second. There are 2 basic options to do this trip:

Fastest option 1 was to go to San Rafael Station (I'll call it SR here on out) then bus to SF, then bike/walk to the Caltrain station, which was about a 25 minute walk. The buses from SR to SF ran often as rarely as once per hour, and occasionally they just don't show up at all. The ride took 30-60 minutes depending on traffic. There weren't always bike spaces on the bus, so sometimes you needed to lock your bike up in SR and you were going to be walking in SF to Caltrain. But because of the variability on traffic times, you have to leave incredibly early if you want to catch the fastest train to Palo Alto. And if you're going to California Avenue (which was where I was going to), the express option basically doesn't exist.

Here's how that plays out: 10 minute bike to SR station (or 30-40 minute walk, depending on your walk speed), you have hopefully timed things right to get on a bus leaving once every 30-60 minutes and that the bus is actually showing up: otherwise, you're waiting 30-60 minutes for the next one. Then a 30-60 minute ride into SF. Then a ~5 minute bike ride or 15-20 minute walk to Caltrain. Then a 45-60 minute ride to Palo Alto, but again the transfers aren't timed (they couldn't be, given the difference of where the bus dropoff is)

The second real alternative is replacing the first bus leg with a ferry leg by going to Larkspur Landing. There is the SMART train that goes there, but for some wild reason drops people off a 15 minute walk from the ferry and then has no timed transfer.

I did the journey dozens of times and never completed it in less than 2h 30m but more commonly was 4h and had more than 1 occasion where it took much longer than that.

For transparency to others here, here's what happened:

I submitted a support request and separately a GDPR request for my information and removal. I let the legal team at Backblaze know what happened as well by e-mailing legal@.

- The support request auto-responded with "We will respond to your support request () within one day." That was 21 days ago. No response.

- The legal team stated that my information has never been sold to 3rd parties. Strange unless Backblaze is operating its own AI cold calling en masse and then refused to complete my GDPR request of telling me the data it had collected on me. They refused to acknowledge that I had gotten an AI cold call

So no. This is frankly a BS path forward. Nobody at Backblaze as far as I can tell is taking this seriously

I asked it to talk to a real person: a manager, legal, or compliance employee and it hung up on me

1 year ago, I lived in San Rafael (Marin county, Bay Area). I occasionally needed to go to Palo Alto for work meetings. The fastest public transit option was to take a 40 minute bus to Larkspur Landing, then a 30 minute ferry to the SF Ferry building, walk for 20 minutes, and then take Caltrain for 45 minutes or more and then walk from there. With transfers, at minimum it was a 2.5h journey, but typically 3+h

All to cover a 60 mile / 100 km distance

Wanted to let this group know because this sort of thing is an appropriately sensitive topic in this community, which is also directly their target audience. The AI agent did not identify itself as an AI agent until I asked, which likely violates other laws as well.

Very upset by this, and will never use Backblaze (or anyone that uses this type of telesales) approach

Comments URL: https://news.ycombinator.com/item?id=44118322

Points: 5

# Comments: 2

I've been a product management lead for 2 commercial open-core companies and people drastically overestimate:

- How much code the community contributes (in both cases, >95% of all code was written by employees hired by the commercial company) - How few commercial resources are needed to support the community (running forums, answering GitHub tickets, etc) - How much financial support is actually forthcoming when there's not some "locked commercial features"

As the paper points out, many of these widely used commercial projects receive a few hundred thousand dollars at most in donations (often much less) but need to employ more developers than that financing can support to maintain a baseline capability to address basic bug fixes (including security fixes) once they become "popular enough" to be known by the masses.

- How well does it work at a specific frequency, if you're just trying to transmit/receive on one specific frequency

- How well does it work on the frequency range(s) if you're working on more than a specific frequency

- How well does it block frequencies that you don't want to send/receive

- How well directional is it to trade off using lots of radiation to blast in many directions vs a higher focus beam using less energy or getting less interference from other directions

- How much physical space do you have in each dimension?

These are just a few examples, but for example you can provide a much "better" connection in almost every sense of the word if you can make your antenna directional (point between the source and destination) only on a specific frequency, and be huge, but most of the time you have some physical space constraints, multiple frequencies to deal with, and the potential that your signal could at least come from some degrees in each the x/y/z axes, and sometimes it needs to be omnidirectional.

Again, these are just examples, but you end up with these types of design considerations that play into larger system design (can you put more transmitters up to encourage directionality, limit frequencies, etc).

There are some well known "base" antenna types like dipole, yagi-uda, circular, and log periodic dipole array if you want to look them up by name and see some of the known tradeoffs and design choices, but virtually any wire can be an antenna and there are an unlimited number of shapes, nearly all of which don't have known radiation characteristics