It can be hard enough for humans to just look at some (already consistently passing) tests and think, "is X actually the expected behavior or should it have been Y instead?"
I think you should have a look at the abstract, especially this quote:
> 75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage. During Meta's Instagram and Facebook test-a-thons, it improved 11.5% of all classes to which it was applied, with 73% of its recommendations being accepted for production deployment by Meta software engineers
This tool sounds awesome in that it generated real tests that engineers liked! "zero human checking of AI outputs" is very different though, and "this test passes" is very different from "this is a good test"
Good points regarding test quality. One takeaway for me from this paper is that you can increase code coverage with LLMs without any human checking of LLM outputs, because it’s easy to make a fully automated checker. Pure coverage may not be super-interesting but it’s still fairly interesting and nontrivial. LLM-based applications that run fully autonomously without bubbling hallucinations up to users seem elusive but this is an example.
Many iOS users use the Messages app to send and receive text messages which can be trivially backed up to iCloud but not other cloud storage solutions. Among people who text (common in the US) I'd imagine there aren't many iPhone users with less than 5GB of data stored in iMessages
That said, you can back iMessages up to a computer and back up files on your computer. You just can't restore iMessages to different Apple devices like this, but now we're talking about minor grievances to a really tiny segment of the population
> you'd be an idiot if you don't mass apply using your resume. Everyone does it, so you have to as well.
I've been on the receiving end of mass applications. If you stopped justifying your spam behind "everyone does it" (no they don't) and started tailoring your applications, leaning on your network (or building one up) you may need a lot fewer.
I have never mass applied, so I may seem idiotic to you. But even during the times I quit a job before looking for another, I've never been on the market for more than 2 weeks.
Georgia the country has about half the land of Georgia the state in the US, and Georgia the country has about half the population of Atlanta alone (even less population when compared to the entire US state of Georgia). I think that huge difference in popularity contributes largely to why "Georgia" often refers to the the US state on this site
I think a lot of really smart people end up claiming something like "this whole system wasn't designed properly, we can do it way cleaner if we redesign it from the ground up" but it's always a trap. Incremental improvements take less time, can be more easily understood, are safer to deploy. But a lot of those really smart people have perfectionistic tendencies that cloud their judgement, and nobody can imagine all the different paper cuts that will get in the way of their beautiful vision. And thus, the new technical debt (to someone else) is written
Perhaps something that could you help is adding an H1 to the readmes like "This project is finished, not being developed", with some explanation like "Unless you found a security vulnerability, your issues and PRs may be ignored or receive delayed responses. Feel free to fork this repo if needed. Please do not ask if this is dead."
This clarifies your stance so well that people acting in good faith won't bother you, and anyone who does bother you very likely isn't acting in good faith - easy to ban.
Plus, when you see someone ask questions about your project and interpret them as "a bulleted list of the reasons I suck", it implies that on some level you think "I suck because I'm not giving these projects more of my time". Giving that kind of disclaimer might help you move away from that mindset, and instead feel more at ease with yourself. Your contributions should be celebrated (as the person with those bulleted points did!), and anyone acting in good faith can appreciate them and fork if needed
Perhaps it'd be good to have a template that open source projects can use to set expectations, or a badge or something. Based on your suggestion it could be something like
I consider this project
- actively developed
- a toy
- finished
- still interesting to me
- no longer something I expect to progress
I will / will not review PRs [unless they are Security / some category].
Your best option if you would like changes is
- raise a PR
- ping me
- fork it
- use a different project
- pay me
My attitude to forks is
- The more the merrier
- A necessary evil
- I'd like to avoid them for this project if possible
- Not allowed by the license
I've seen apps break in prod where third party libraries had array accesses on indices that didn't exist, or dereferenced nil pointers, in goroutines they spawned. And those aren't the only ways to cause a panic without ever calling the panic function.
Third party libraries have bugs sometimes, and other times our usage of them can create bugs. Nothing like a SIGKILL or anything malicious. That's just the way things are and will be. And breaking down like this in dev can be fantastic!
But when a once in a blue moon issue crops up in prod and all other connections are dropped, the fact that a simple defer+recover couldn't have been preemptively placed on all goroutines is a huge nightmare. I'd even take a "you can add defer+recover for any goroutines created further in this callstack" - it's rare that libraries spawn goroutines, I'll already know which ones to trigger that behavior on
> But when a once in a blue moon issue crops up in prod and all other connections are dropped, the fact that a simple defer+recover couldn't have been preemptively placed on their goroutines is a huge nightmare
Yeah, this is one of the weird things, to say it mildly, that Go does that is hardly mentioned anywhere. Most people don't know about it until they themselves first encounter the nightmare bug similar to what you said.
Wrapping every third-party library in defensive code doesn't make a lot of sense since this isn't the most dangerous kind of bug. To make a one example of a million: a third-party database library that corrupts your database is infinitely more dangerous and that there's no form of wrapping that will save you.
Bad code is bad code. Bugs are bugs. This issue is not a major source of problems in Go code.
> This might mean you can't use TheTradeDesk and Google Adsense en-masse for example. Basically, as of today, a lot of price discovery is now automated by a majority of companies using a handful of vendors for this.
IANAL but this seems incorrect. Price discovery is one thing, being contractually obligated to keep prices at a certain level 80% of the time is another. A court can make a ruling about that 80% number in the contract without saying anything that impacts one's ability to discover the prices competitors charge
TradeDesk has algos that set bids (supply side), rather than set prices (sell side). Maybe SSPs have algos for setting floor prices that would be affected.
It could be your router giving it a new IP address, but the printer itself hopefully has a static MAC address. Check your router settings for static IP assignment, they may be under a section called DHCP. Over there you could give it a static IP address for its current MAC address
EDIT: this comment no longer makes sense after the parent comment was edited. It used to be explicitly asking for help and didn't mention any solutions like static IPs, nor did it spell out a general remark about how this complexity in consumer electronics is bad
You missed the point. I wasn't asking for help on how to assign a static IP address. My point was that ordinary people shouldn't have to know what an IP address is, let alone what a static IP address is, in this day and age.
If you want to have a network, someone needs to know a bit of networking. Or you need someone you can call who does.
Don't get mad at the printer for what your router is doing to its IP address. This day and age isn't as advanced as you'd like it to be, or you need a new router that does what you expect.
Bonjour struggles to find printers much more than Windows. My Windows users just click add printer and it just works. And let's not talk about file shares. Macs literally can't connect to any file shares except Windows ones (since AFP is out of support), and then only with Samba, and only with Apple's botched implementation of Samba which crashes, because it needs to create metafile databases on said shares, if a share has too many files.
Try opening a file share with 20k+ images in the root from your latest Mac.
Seems to me, as a mixed OS business operator, that it's Apple that's behind the times.
Even out of service Chromecast devices and decades old Linux distros are better at network discovery than Bonjour.
I can’t comment on the file share tangent, but in my experience with a Bonjour-equipped Brother laser printer over the past eight or so years, I don’t think I can recall it failing to connect once.
Granted, I’m on a Mac and I print about five times a year, so YMMV.
I don't doubt that a one computer, one printer, scenario is any problem for any OS. You'll see who the ugly one is when the kids play together.
File sharing isn't a tangent. The purpose of Bonjour is to couple printing and file sharing as a network discovery protocol.
But a one printer one computer being a problem is precisely the issue in the thread at hand. Once the router reboots the printer changes IP address (since it gets a dynamic IP by default) and then Windows can't find it, hence the need to assign it a static IP.
This specific chain is about Bonjour and, more specifically, is a response to a claim that Microsoft is behind the times.
The "Windows can't find my printer" issue is already addressed by other responses. Windows can find your printer even if the IP changes, assuming the printer wasn't installed in a way that circumvents that. (E.g. by not choosing to find it automatically and using an IP address against the on screen recommendations.)
I used to do that too because I didn’t know what it was or why I would want it. Now I intentionally have it installed without iTunes since its so handy.
Part of the commoditization process for consumer products is that they are made to be user friendly for non-experts. Most other networked devices have already done this. Nobody needs to know how to configure /var/lib/dhcpd/dhcpd.leases to use an iPad on the router that Xfinity provides.
If people start using dynamic IPs as if they are static, when they really aren't, they're just setting themselves up for failure the next time the devices reboots or resets. It's better to either use static addressing if you want static addressing, or use DNS if you don't know what the IP is going to be.
It can be hard enough for humans to just look at some (already consistently passing) tests and think, "is X actually the expected behavior or should it have been Y instead?"
I think you should have a look at the abstract, especially this quote:
> 75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage. During Meta's Instagram and Facebook test-a-thons, it improved 11.5% of all classes to which it was applied, with 73% of its recommendations being accepted for production deployment by Meta software engineers
This tool sounds awesome in that it generated real tests that engineers liked! "zero human checking of AI outputs" is very different though, and "this test passes" is very different from "this is a good test"