Remember that "thought process" is just a metaphor that we use to describe what's happening. Under the hood, the "thought process" is just a response from the LLM that isn't shown to the user. It's not where the LLM's "conscience" or "consciousness" lives; and it's just as much of a bullshit generator as the rest of the reply.
Strange, but I can't say that it's "damning" in any conventional sense of the word.
I've had reasonable success from doing something like this, though it is my current opinion that it's better to write the first few tests yourself to establish a clear pattern and approach. However, if you don't care that much (which is common with side projects):
Starting point: small-ish codebase, no tests at all:
> I'd like to add a test suite to this project. It should follow language best practices. It should use standard tooling as much as possible. It should focus on testing real code, not on mocking/stubbing, though mocking/stubbing is ok for things like third party services and parts of the code base that can't reasonably run in a test environment. What are some design options we could do? Don't write any code yet, present me the best of the options and let me guide you.
> Ok, I like option number two. Put the basic framework in place and write a couple of dummy tests.
> Great, let's go ahead and write some real tests for module X.
and etc. For a project with an existing and mature test suite, it's much easier:
> I'd like to add a test (or improve a test) for module X. Use the existing helpers and if you find yourself needing new helpers, ask me about the approach before implementing
I've also found it helpful to put things in AGENTS.md or CLAUDE.md about tests and my preferences, such as:
- Tests should not rely on sleep to avoid timing issues. If there is a timing issue, present me with options and let me guide you
- Tests should not follow an extreme DRY pattern, favor human readability over absolute DRYness
- Tests should focus on testing real code, not on mocking/stubbing, though mocking/stubbing is ok for things like third party services and parts of the code base that can't reasonably run in a test environment.
- Tests should not make assumptions about the current running state of the environment, nor should they do anything that isn't cleaned up before completing the test to avoid polluting future tests
I do want to stress that every project and framework is different and has different needs. As you discover the AI doing something you don't like, add it to the prompts or the AGENTS.md/CLAUDE.md. Eventually it will get pretty decent, though never blindly trust it because a butterfly flapping it's wings in Canada sometimes causes it to do unexpected things.
Not OP, but here are just a few things I do currently on my Android (phones and tablets):
* Use (true) Firefox w/ extensions or other browsers
* Sideload apps that aren't available in the store (this is increasingly common with open source projects that don't want the headache of dealing with app stores)
* Install my own apps (which I increasingly vibe-code since I'm the only user) and not have to deal with paying Apple or reinstalling every few days or week or whatever
* Write bash and ruby scripts to automate things on my device which often require interacting with system APIs (tmux is my platform for this on Android currently)
* Pin versions of apps that have enshittified or sold to gross companies that harvest data or switch to subscriptions models by copying the APK and re-installing it on new devices
* Install alternate/experimental graphical shells that are frequently innovative and interesting (though rarely useful in the long-term, but it's still fun)
* Option to use other ROMs such as Graphene OS
* Capture packets and proxy traffic to see what my device is doing (this has gotten pretty hard on Android now, but still something I want to do)
* Have an on-device fine-grained firewall to tightly control which apps are allowed network access
There are definitely other things I can't think of at the moment, but I'm not sure why you're being so hostile to GP. Saying that iOS devices are locked down and can't do a lot of stuff doesn't seem like a very controversial opinion, especially on HN.
> Use (true) Firefox w/ extensions or other browsers
No longer true as of this year.
> tmux
typo?
I agree with you about side loading. Apple does not. I wonder if regulations can eventually force their hand.
Some of your other points (scripting, packet sniffing, general shell access and command line tools) are just done differently, and you'd just need new tools of the trade if you actually wanted to do it. Also, a bunch of the things you have mentioned requires unlocking the android bootloader and obtaining root privileges. You can do that to a large extent for ios (jailbreaking), Apple is just more competent about shutting it out than other companies.
Thanks for writing it up. I agree with all your points. I stopped myself from replying further to the other commenters - they don't seem to be interested in an actual meaningful calm discussion.
This is great news. I look forward to a day when I never have to talk to a salesperson again.
> Forty-eight states have laws that limit or ban manufacturers from selling vehicles directly to consumers
Why on earth is this a law? (I mean besides the obvious lobbying efforts and likely scare-mongering from powerful auto dealers) Is there an actual reason/benefit for this though for consumers?
These laws are anachronisms back when they didn’t want manufacturers directly selling vehicles to consumers because there was a fear (or maybe, an experience?) with manufacturers selling vehicles without any reasonable ability to get parts, repairs, etc.
Nowadays with nationwide fast shipping and the internet these aren’t really problems… but in the 1950s I could see how there would be some benefits to having a dealership near you.
Yes, but that's the first layer. The second layer is "Why would we care about undercutting local dealers"? And there are good reasons to avoid undercutting, not just greed, as is often the case.
In my view if the local dealers will go to hell in a hand basket I won’t shed a tear. Michael’s Subaru of Bellevue couldn’t tighten some gasket under the car and my car was leaking oil after the oil change. When I took the car to the dealership they said it was because of my car being too old (older Subarus have indeed a problem with oil leaks). The guy behind the counter looked like he had anger management problems with my request to take another look. So yeah, if Amazon will put these dealerships out of business - good riddance.
You know, sometimes they get anger management issues after the 1000th angry customer asking them to fix what appears to be a design flaw in the car that customer bought. I'm not sure that buying from that dealership via amazon would do anything for you (amazon is just listing dealer cars), or that the situation would be better if you bought directly from the manufacturer.
I think Ford would be happy to sell a car direct and pocket at least some of the commission they otherwise pay to the dealership. But they sort of need dealers also, to do local marketing, help customers who want hand-holding, and to provide warranty/recall service.
> Tesla does not allow the use of any used, recycled, alternative, aftermarket, or third-party replacement parts. Use only new parts ordered directly from Tesla.
That's quite an interesting statement from Tesla. How much weight does it actually hold beyond just being "their opinion" considering that the Magnuson-Moss Warranty Act forbids the voiding of warranties for those reasons?
IIRC, they won't sell parts to a non-certified mechanic, and there's a lack of third-parties making the more complex parts. You're fine if you need a tire swap. You're not gonna have much fun if you have to replace the screen.
A Federal-level right to repair can't come soon enough.
You can buy (almost?) any part directly from Tesla as a plain Joe [1], but you may need a VIN for certain parts (mainly the actual computers?).
In the event you want to DIY a repair, Tesla publishes all their service manuals they use at their service centers (e.g. [2]) and you can can even use the exact same software their technicians use for the deeper repairs, albeit at a price that is expensive if you're a plain Joe, but for a repair shop it doesn't seem to be terribly expensive.
On the topic of 3rd party parts, there isn't quite as robust a marketplace.
Nothing. But they don't need to. They just tackle it at the supply side.
If you're a mechanic who wants Tesla parts, you need to go through Tesla. If you go through Telsa, you can't use third-party parts or resell the first-party ones. As a result, the market for third-party parts stays largely too small to exist.
I think Tesla has "show rooms", and then you buy the car from California and import it. So you're not actually visiting a dealership when you visit a Tesla store.
I was talking about in states that banned direct sales, not generally
No, you didn't pick them up at a dealership. Because Tesla doesn't operate dealerships. They call them stores, or galleries depending on if direct sales are legal. They hold dealer licenses, but that does not mean they are a dealership.
If you're going to be needlessly hostile, at least be correct.
> You clearly don't know what you're talking about
Please omit swipes like this from comments on HN, regardless of who or what you're replying to. The guidelines make it clear we're aiming for something better here. https://news.ycombinator.com/newsguidelines.html
They were adopted in the mid-20th Century when franchised dealers the norm but manyfacturers would use threat (backed by follow-through if the threat wasn’t successful) of opening direct competing manufacturer-owned dealerships to coerce franchise dealers practices, to take that practice off the table.
It stems from franchise law which exists to give franchisees a modicum of protection from adverse practices by the much stronger party in the relationship.
I'm sure that's a part of it, but I'm of the opinion that car dealers and other really local business owners like them are the modern equivalent of the landed gentry.
Locally powerful people can have a lot of leverage, even against a much bigger national-level entity.
> Starting today, customers can browse, finance, and purchase certified pre-owned Ford vehicles online through Amazon Autos, with in-person pickup at a local Ford dealership.
This whole thing sounds like dealership with extra steps and a middleman fee.
Would love to see how much pressure is put onto purchasing addons from the local dealers. I remember reading people running into that when picking up their Lightnings.
"We had us a deal here for nine-teen-five. You sat there and darned if you didn't tell me you'd get this car, these options, without the sealant, for nine-teen-five!"
"Yeah but that TruCoat.... Lemme talk to my boss..."
Vertical integration is, in general, bad for competition and often bad for consumers. There can be benefits, but too much control limits availability of parts, confuses incentives, etc.
> Vertical integration is, in general, bad for competition and often bad for consumers.
This is a gross misunderstanding of what vertical integration is.
YKK zippers makes an unbeatable product because of vertical integration.
A lack of vertical integration means that you're subject to the whims of larger markets (and increased interest and costs at every step).
The flip side to this is "control nothing". Buy the building your office is in and own an asset, or get a triple net lease and then pay margin on top of that. Own your own hardware or pay AWS to have 30percent profit margins...
Vertical integration has ZERO to do with any sort of market dominance.
A company could be vertically integrated, and have a small portion of the market. A company could be a full on monopoly and have little to no vertical integration.
YKK processing raw metals and plastics, building its own zipper making machines has nothing to do with how much market share it has. It has everything to do with product quality.
Faunc is another example of "vertical integration" where they make the mills, software and controllers for their devices, as well as servos and spindles. Servos and spindles are commodity items (you can buy them cheaply from china) yet Faunc makes their own for quality and reliability reasons.
You are correct that a high degree of vertical integration does not necessitate market dominance.
I would like to add some nuance though: As the supply chain becomes longer, the value of vertical integration rises. Now if we acknowledge that bigger players can profit more from vertical integration as well, and assume that players play equally well, we have a "devil poops on the big pile" situation, pulling the market towards a monopoly as the bigger player gets to profit more.
So it's not got exactly ZERO to do with market dominance ;)
It's true of beer, too. In a lot of states (decreasingly so), breweries cannot sell beer directly to consumers, or even retailers. I once paid for a tour of a brewery, where the price of admission also covered a souvenir glass. The brewery would then give you a few pours of "free beer". They emphasized that they were definitely not selling me any beer.
When did you last use their support? 15 years ago, I needed to click 1 button to chat with support instantly about a faulty iPod I bought. They issued a refund and return mail label instantly.
3 months ago, I had to navigate multiple froms and dropdowns to even reach a chat representative. And when I did, they had none of the information I spent several minutes filling out. The rep then grilled me about my order, seemingly incredulous that Amazon had sent me a "new" product that was clearly used and repackaged when I opened it (this has been common for years as Amazon commingles its own stock with that of 3rd party sellers).
FWIW I find Amazon's phone support to be faster than the chat stuff. It's usually just a couple mins, most of which time you're on hold while they're fixing it. My wife hates dealing with returns, but I find that it's usually no big deal, and often they'll give you $5 or $10 for your trouble, if things don't get sorted out the first time (which seems to be about 10% of the time).
? I've returned two items from Amazon in the last year and in both cases, all I had to do was click on the "Return" button and drop it off at my local UPS Store.
Because the Return button didn't give me an option to print a mail label. I had to click through multiple screens and finally located the support chat link.
I can't tell if this is sarcasm or not. I remember when their customer service was truly great, about 20 years ago. Now it is not great, but still much better than car dealers, IMO.
There's no doubt that mixing these two could be a nightmare. But if you're replacing the pre-purchase haggling of a car dealership with the no-haggle process of buying on Amazon, then it might not be awful.
The real question is: who's on the hook if things aren't as described/pictured? It sounds like these all come with extended warranties, so that would mean it would be the dealer. They're no picnic to deal with, but that's going to be the case no matter whether you buy the car from them or from Amazon. If you can have a more pleasant buying experience by starting with Amazon, that's a win in my book.
As a knock-on effect, it could help bring down prices on used cars sold by other dealers, since buyers could point to these car listings as comparables.
Generously, protecting local labor is important in an environment that demands labor for survival and where considering alternative systems of providing for people is verboten. This is a confederation-level version of protections against offshoring jobs. Whether the jobs add value or not is its own dilemma.
Wonder if there an opportunity there to set up distribution in the few states that don't have that law and make everything easy online - out of state registration, delivery (for a fee). The dealerships in the 48 states will probably sue the manufacturers, they are not just going to let it slide, I suspect.
I'm also a software guy but started in military grade hardware.
You're correct. Stress testing alone on components and integrated modules will typically wreck consumer grade devices in a hurry. Engineering hardware to operate in extreme conditions takes significant effort and iteration. Even little things like manufacturing solder joints with no weak spots is a big task. Plus there's a lot of cost for certification, which you need at all levels.
The actual circuit design is usually the easy part
I would love to see Google contribute here, but I think that's a different issue.
Are the bug reports accurate? If so, then they are contributing just as if I found them and sent a bug report, I'd be contributing. Of course a PR that fixes the bug is much better than just a report, but reports have value, too.
The alternative is to leave it unfound, which is not a better alternative in my opinion. It's still there and potentially exploitable even when unreported.
But FFmpeg does not have the resources to fix these at the speed Google is finding them.
It's just not possible.
So Google is dedicating resources to finding these bugs
and feeding them to bad actors.
Bad actors who might, hypothetically have had the information before, but definitely do once Google publicizes them.
You are talking about an ideal situation; we are talking about a real situation that is happening in the real world right now, wherein the option of Google reports bug > FFmpeg fixes bug simply does not exist at the scale Google is doing it at.
A solution definitely ought to be found. Google putting up a few millionths of a percent of their revenue or so towards fixing the bugs they find in ffmpeg would be the ideal solution here, certainly. Yet it seems unlikely to actually occur.
I think the far more likely result of all the complaints is that Google simply completely disengages from ffmpeg and stops doing any security work on it. I think that would be quite bad for the security of the project - if Google can trivially find bugs at a high speed such that it overwhelms the ffmpeg developers, I would imagine bad actors can also search for them and find those same vulnerabilities Google is constantly finding, and if they know that those vulnerabilities very much exist, but that Google has simply stopped searching for them upon demand of the ffmpeg project, this would likely give them extremely high motivation to go looking in a place they can be almost certain they'll find unreported/unknown vulnerabilities in. The result would likely be a lot more 0-day attacks involving ffmpeg, which I do not think anyone regards as a good outcome (I would consider "Google publishes a bunch of vulnerabilities ffmpeg hasn't fixed so that everyone knows about them" to be a much preferable outcome, personally)
Now, you might consider that possibility fine - after all, the ffmpeg developers have no obligation to work on the project, and thus to e.g. fix any vulnerabilities in it. But if that's fine, then simply ignoring the reports Google currently makes is presumably also fine, no ?
I really don’t understand whole discourse us vs them? Why it is should be only Google fixing the bugs. Isn’t if volunteers not enough, so maybe more volunteers can step up and help FFMpeg. Via direct patches, or via directly lobbying companies to fund project.
In my opinion if the problem is money, and they cannot raise enough, then somebody should help them with that. Isn’t it?
If widely deployed infrastructure software is so full of vulnerabilities that its maintainers can't fix them as fast as they're found, maybe it shouldn't be widely deployed, or they shouldn't be its maintainers. Disabling codecs in the default build that haven't been used in 30 years might be a good move, for example.
Either way, users need to know about the vulnerabilities. That way, they can make an informed tradeoff between, for example, disabling the LucasArts Smush codec in their copy of ffmpeg, and being vulnerable to this hole (and probably many others like it).
I mean, yes, the ffmpeg maintainers are very likely to decide this on their own, abandoning the project entirely. This is already happening for quite a few core open source projects that are used by multiple billion-dollar companies and deployed to billions of users.
A lot of the projects probably should be retired and rewritten in safer system languages. But rewriting all of the widely-used projects suffering from these issues would likely cost hundreds of millions of dollars.
The alternative is that maybe some of the billion-dollar companies start making lists of all the software they ship to billions of users, and hire some paid maintainers through the Linux or Apache Foundations.
> But FFmpeg does not have the resources to fix these at the speed Google is finding them.
Google submitting a patch does not address this issue. The main work for maintainers here is making the decision whether or not they want to disable this codec, whether or not Google submits a patch to do that is completely immaterial.
What makes you think the bad actors aren't already finding these bugs? From the looks of it, there isn't really any rocket science going on here. There are equally well-funded bad actors who will and do find these issues.
With Google finding these bugs, at least the user can be informed. For this instance for example, the core problem here is the codec is in *active use*. Ffmpeg utilizes a disingenuous argument that it's old and obscure, but omits the fact that it's still compiled in meaning that an attacker can craft a file and send it to you and still works.
A user (it could be a distro who packages ffmpeg) can use this information to turn off the codec that virtually no one uses today and make their distribution of ffmpeg more secure. Not having this information means they can't do that.
If ffmpeg doesn't have the resources to fix these bugs, at least let the public know so we can deal with it.
Also, just maybe, they wouldn't have that many vulnerabilities filed against them if the project took security more seriously to begin with? It's not a good sign for the software when you get so many valid security reports and just ask them to withhold them.
The actual real alternative is that the ffmpeg maintainers quit, just like the libxml2 maintainer did.
A lot of these core pieces of infrastructure are maintained by one to three middle-aged engineers in their free time, for nothing. Meanwhile, billion dollar companies use the software everywhere, and often give nothing back except bug reports and occasional license violations.
I mean, I love "responsible disclosure." But the only result of billion dollar corporations drowning a couple of unpaid engineers in bug reports is that the engineers will walk away and leave the code 100% unmaintained.
And yeah, part of the problem here is that C-based data parsers and codecs are almost always horrendously insecure. We could rewrite it all in Rust (and I have in fact rewritten one obscure codec in Rust) or WUFFS. But again, who's going to pay for that?
The other alternative if the ffmpeg developers change the text on their "about" screen from "Security is a high priority and code review is always done with security in mind. Though due to the very large amounts of code touching untrusted data security issues are unavoidable and thus we provide as quick as possible updates to our last stable releases when new security issues are found." to something like "Security is a best-effort priority. Code review is always done with security in mind. Due to the very large amounts of code touching untrusted data security issues are unavoidable. We attempt to provide updates to our last stable releases when new security issues are found, but make no guarantees as to how long this may take. Priority will be given to reports including a proof-of-concept exploit and a patch that fixes the security bug."
Then point to the "PoC + Patch or GTFO" sign when reports come in. If you use a library with a "NO WARRANTY" license clause in an application where you're responsible for failures, it's on you to fix or mitigate the issues, not on the library authors.
Yeah for sure, this is what I buy on Amazon (https://www.amazon.com/dp/B00FAB10ZI) and the dosage depends on what you are experiencing. I was doubling my dosage, but have lowered it back to the recommended dosage on the package (10 pills, they are tiny). I have also taken the powered version but the umami taste is really strong, so I went back to the pill version.
I like to take it with Psyllium Husk Fiber / Metamucil to help increase the fiber in my diet since the higher dosage is like eating a lot of kale at one time, it can move through you super quickly.
Here are some studies that I commented before that I have read that has helped with learning more about the supplements and the dosages depending on what you are experiencing:
- High-dose supplementation of Chlorella and Spirulina increases beneficial gut Bacteria in healthy ICR mice: A 90-day feeding study (https://doi.org/10.1016/j.jff.2025.106796)
- Beneficial Effects of Spirulina Consumption on Brain Health ( https://doi.org/10.3390/nu14030676) This is a new study that I found, that I'm going to read, but it shows the impact on neuroinflammation, and from experience the supplement has helped me with inflammation, and why I think it has helped with my ADHD/Anxiety.
On a meta note, I have a deep love and appreciation for people like yourself who share this kind of info. It's been quite helpful for me on my own health journey.
No problem! Thanks! It's something I have been researching for a while, and has really benefited me. It's different for everyone, but has had a impact on me, and then leads to other dietary changes that can lead to more change.
Thanks for commenting on this supplement. What reactions or symptoms should we look for in order to suggest that we're ramping up too quickly on it? Are we talking gastrointestinal effects or something else?
Indeed, though it would take some coordination to actually narrow it down precisely. You'd need a few different planes/satellites to detect the signal and share their reading to allow triangulation. With only a single plane or a single satellite that is not in geosynchronous orbit, you could take multiple readings and get a rough idea of location, but the inability to turn from a straight line (not impossible for a plane of course, but it would require intentionality and willingness for the crew/commanders and typically not cheap as it disrupts whatever flight plan they previously had) would be a hindrance. That said, with how many satellites are up there I doubt it would take much extra effort to do that coordination if the satellite operators have motivation to do so.
reply