linsomniac
>Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity."
that sounds similar to what I'm seeing, but in my case that restriction is limited to their "evaluation-level" services. It says in full:
>Evaluation and Additional Services. In some cases, we may permit you to evaluate our Services for a limited time or with limited functionality. Use of our Services for evaluation purposes are for your personal, non-commercial use only.
Thanks again for pointing this out. I think we're in the clear in the US.
Yes, that is something you have to be careful of. In this case, as I mentioned I believe, it was done in spare time, not full time, and it was mostly the AI that spent 2 weeks, I'd guess he probably spent a day or two, and the testers probably spent another day (however, I think this ended up coinciding with our quarterly "full site" test, so it would have happened anyway).
He had the translation use browser integration to compare the new site to the old site automatically. The result was so good that he had to change background color on the new site because he couldn't be sure that he was testing the new site; it was so close to the original he was paranoid about accidentally being on the old site and not knowing it. The whole thing was done in under 2 weeks, including coding, developer testing, tester testing, and deployment. It's been in production 4-6 weeks now and we've had no reports of problems.
Looks like it's available in The Year’s Best Science Fiction: Twenty-First Annual Collection and at the time I read _Toast_ I was also reading a bunch of these "Years Best Sci Fi" collections. I've snagged this and will give it a read, but I'm almost 100% certain that you nailed it!
In the story some University students take part in a trial that involves a brain scan and then them spending the rest of the day answering a customer support message. They can spend the whole day working on researching and writing a really good customer support reply to a user request. While doing this they notice something odd and realize through some sort of back-channel that this isn't the first time they've spent the day writing a customer support message; they are stuck in a simulation.
I'd really love to go back and re-read it, but I've not been able to find it again.
In _Toast_ is another story that's also relevant: A fairly innocuous news story pops up and our hero calls his partner at work to tell them that it's time to get their go bag and get off planet. This news story indicates the Earth is in the beginning stages of reaching an AI singularity, and this isn't the first time our hero has gone through this on a planet.
WezTerm can run on my Mac but give me a native GUI experience of a Wezterm session on my Linux workstation. It's like tmux, but with a native GUI experience including mouse click-drag selection that doesn't pick up "window" borders.
That alone is what is keeping me on Wezterm, since I get a native experience on some terminal sessions I access remotely on my macbook but then can switch to on my 30" screen when I'm at my desk.
I'm seeing a lot of comments mis-representing "balcony solar". This is a phrase that specifically means "small-scale solar panels that directly feed the grid". It is NOT about solar cells feeding a "cooler sized battery+inverter".
This is what makes it so attractive; no battery is required. But this is also why it is waiting in the US on legislation (back-feeding the grid). Germany has already passed this legislation. In particular, the equipment needs to be UL3700 certified.
I'm right there with you. I really like programming in Python, the language. Now that I'm not writing much if any code, the rough edges in building and deployment have come to the forefront. Even "uvx run" has become a sticky wicket (I have some machines that don't have Internet access).
apt-cacher-ng, the hand-written C++ version, is 16K LOC for the core. apt-cacher-ultra does a lot more. Seems like a pretty reasonable LOC count to me.
What are you basing your assertion above on?
Let's call it "Joy".
I've done hard things. Many of them have a significant amount of time that is a slog. A tapestry is going to have a lot of days of just slog work. And that's fine. Doing hard things can be very rewarding. I've reupholstered a couch by taking it down to the sticks, repairing and reinforcing the frame ("hey kids, the couch isn't designed for walking and jumping on"), enhancing the design, re-springing it, redesigning the cushions so that they didn't need readjusting every time you sat down, making new foam cushions, and then sewing a upholstery. Took 3-4 months.
But, I'm in the last half of my 50s. The project you're commenting on, apt-cacher-ultra, probably would have taken 2 full time developer years to get to where it is now, and I'm doing some pretty big changes for the next version. I literally probably have a handful of that sort of project I can do left in my life, assuming I quit my job now and work full time on it.
Let me tell you, it's pretty sobering to be faced with: "I may only be doing this once, maybe twice more in my career."
So yes, building experiments where I get to try out my ideas without 2 developer-years of coding required is going to give me an opportunity for a lot of creation that I otherwise wouldn't have had. I've spent decades hand-crafting code, I fully understand the joy of doing so.
Why even write one of those? Just set up an nginx proxy cache and call it done.
But that doesn't even scratch the surface of what this project does. We already have a few simple approaches to this problem: apt-cacher and apt-cacher-ng. Neither of which were any help when Canonical was under DDoS. Both of which have proven unreliable.
As I said elsewhere, apt-cacher-ultra is a pretty subtle piece of software, it doesn't just do a naive cache, it fully understands the apt repo structure, validates the repo, and snapshots it, understands what packages your clients frequently request and preemptively downloads updates to them as part of the snapshot promotion, etc. A DDoS of the package sources, even in the middle of an upstream releasing updates, is something a-c-u will handle no problem. I've simulated this by firewall rules blocking upstream traffic. It's also proven much more reliable than apt-cacher-ng.
I've been in the software game ~40 years, I've seen it time and time again: "How hard could it be" and then when you get into it you realize there are a lot of devils in the details.
That's pretty naive.
This isn't just a simple http proxy and checking if the requested URL exists on disc. It's a pretty subtle snapshotting system that fully understands and vets apt repos, detecting when the repo changes, proactively downloading "interesting" packages that have updated, verifying and validating all packages, and then promoting the repo to active when it is healthy. Plus a web-based admin interface.
The core of it is around 20K LOC, with another 40K in tests. The COCOMO model gives that an estimate of around 2 developer years of effort assuming full time work.
I get it, I've gotten a lot of joy over the decades from the specific act of programming. But I also get a lot of joy from making something. I'm old enough now that I don't have a lot of my time left to "hand stitch an amazing tapestry". But with AI tooling, I do have time to try out a bunch of ideas and see how they work, scratch little itches and also just run a mad scientist library of experiments, without each experiment taking tens or hundreds of hours of coding to see how that experiment pans out.
To pile on, here's mine: https://github.com/linsomniac/apt-cacher-ultra
It is a robust, reliable cache of apt packages, with the additional goal of still being able to serve packages from the cache even when the upstream is down. This was started shortly after that DDoS of Canonical this past year. We've run apt-cacher-ng and apt-cacher over the last dozen years, but (a) it requires hand-holding about once a month and (b) it did absolutely nothing for us when Canonical was under DDoS.
I've put well over 100 hours of my time into it. Still running into a lot of people knee-jerk calling it "slop", but I've had 200-ish machines pulling from it for 6 months and it has worked way better than apt-cacher-ng.
I'm not really sure what to do with people who dismiss AI-assisted projects, while dehumanizing the 100 hours of my time I've put into it. I fear we're running the very real risk of both sides losing: the people trying to thoughtfully create with AI losing because of the AI, and the people avoiding AI losing because they can't keep pace.
However (and I know connecting is on the road map), is it possible to have multiple local connections? That's core functionality for me, I run Herdr in one terminal on my workstation, and on my laptop I ssh in (actually "wezterm connect") and run a "herdr attach" so I can access it both from my Mac and my desk. I've never gotten around to trying the herdr native connect from my Mac because that works so well.
I've been fortunate enough to come across it a couple times, it's pretty cool.
So? Let it.
If people need shelter, it's a shame we are building a ballroom instead of shelter.
If by "fake" you mean ones that pass number validation on web sites, that's easy. I wrote python code to check and generate valid numbers back in the '90s; it's a simple, well known check digit algorithm appended at the end. https://en.wikipedia.org/wiki/Luhn_algorithm.
So, for me, end of the day, it's all about testing, monitoring, soaking in staging and promoting to production.
This might be why I'm fairly comfortable shipping AI generated code.