radlad

I'm really confused by this interpretation. I see a single comment by the maintainer, saying:

> That mistake was made in the past (#8634), where there was still a lot of usages of a old and announced deprecated method (and even with quite some effort there is).

It was a related, but separate issue, which is perhaps best-described in this upstream issue: https://github.com/python-social-auth/social-core/issues/121...

The "plain" setting jvoison wants to remove is described here: https://security.stackexchange.com/a/218554

I do agree with the maintainer that a discussion is warranted before removing this setting. But I also wouldn't personally have closed the PR while waiting for said discussion to occur - and the maintainer could have created a discussion themselves. They are signaling they don't want this change, full stop.

... if you have 800 GB of VRAM free.

Many cloud providers offer bare-metal servers: https://en.wikipedia.org/wiki/Bare-metal_server#Bare-metal_c...

Yes, but for many users, CC is the product. Especially since I'm not allowed(?) to use my own harness with my sub.

For many shops, even Docker Compose is not necessary. It is still possible to deploy software directly on a VM/LXC container.

I agree that Kubernetes can help simplify the deployment model for large organizations with a mature DevOps team. It is also a model that many organizations share, and so you can hire for talent already familiar with it. But it's not the only viable deployment model, and it's very possible to build a deployment system that behaves similarly without bringing in Kubernetes. Yes, including automatic preview deployments. This doesn't mean I'm provided a VM and told to figure it out. There are still paved-path deployment patterns.

As a developer, I do need to understand the environment my code runs in, whether it is bare-metal, Kubernetes, Docker Swarm, or a single-node Docker host. It impacts how config is deployed and how services communicate with each other. The fact that developers wrote Dockerfiles is proof that they needed to understand the environment. This is purely a tradeoff (abstracting one system, but now you need to learn a new one.)

Running a Kubernetes deployment requires running many additional orchestration services that bare-metal deployments (whether running on-prem or in the cloud) do not.

I did, thanks for the correction.

There also seems to be confusion about what I meant by "bare-metal." I wasn't intending to refer to the server ownership model, but rather the deployment model where you deploy software directly onto an operating system.

There is a fairly straightforward feature in Forgejo to sync your repos to Github, if that's what you want to do. It's not perfect, of course, but should help to advertise your projects and keep your activity heatmap green.

I mostly use Forgejo for my private repos, which are free at Github, but with many limitations. One month I burned all my private CI tokens on the 1st due to a hung Mac runner. Love not having to worry about this now!

I recently did this as well and one of the things that has struck me is just how fast Actions are compared to Github!

That said, I've got Linux and macOS setup with a Mac Mini (using a Claude-generated Ansible task file), but configuring a Windows VM seemed a bit painful. You didn't happen to find anything to simplify the deployment process here, did you?

Cosmos Cloud looks neat! At a first glance from looking at the web page, it looks more focused on delivering a "personal cloud" or "1-click deploy apps."

Dokploy is more Heroku-styled: while you can deploy third-party apps (it's just Docker after all), it seems really geared towards and intended for you to be deploying your own apps that you developed, alongside a "managed" database (meaning, the DB is exposed in the UI, includes backup functionality, and can even be temporarily exposed publicly on the internet for debugging.)

Coolify feels a bit like a mix of the two deployment models, while Dockge is "bring your own deployment" and Komodo offers to replace Terraform/Ansible/docker-compose through its own declarative GitOps-style file-based config but lacks features like managed databases, or built-in subdomain provisioning.

Just as a quick aside, I tried Coolify, Dokploy, Dockge, and Komodo, and if you're trying to do a Heroku-style PaaS, Dokploy is really good. Hands down the best UX for delivering apps & databases. It's too bad about the licensing. (e.g. OIDC + audit logs behind a paid enterprise license.)

Coolify is full of features, but the UX suffers and they had a nasty breaking bug at one point (related to Traefik if you want to search it.) Dockge is just a simple interface into your running Docker containers and Komodo is a bit harder to understand/come up with a viable deployment model, and has no built-in support for things like databases.

There are many organizations which still ship software without Kubernetes. Perhaps even the vast majority.

The complaints I see about Kubernetes are typically more about one of two things: (a) this looks complex to learn, and I don't have a need for it - existing deployment patterns solve my use case, or (b) Kubernetes is much less inefficient than running software on bare-metal (energy or cost.)

Usually they go hand in hand.

I assumed this was meant to make the bot postings less obvious to normal users, to buy them time to "solve the problem."

But definitely, bots on reddit seem significantly more common in the past year or two.

Dishonesty, meet dishonesty. (Legally, I think libel requires intent.)

For something like YouTube, there is a small monetary cost in order to verify a phone number.

> Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limited I/O, PATA, ...).

Maybe so, but my memory of Cygwin was waiting multiple seconds just for the Cygwin CLI prompt to load. It was very slow on my machines.

More than anything this seems like a good reminder that spiders aren't human.

Bless you

Plain English automation, including control of external systems. Even better that it exhibits some forms of decision-making autonomy for edge cases.

I realized that one of my bigger issues with LLMs is actually that I worry they increase "information entropy" on average. Most tools help me reduce entropy - LLMs seem to increase it, on a global scale.

This is related to my observation that for thousands of years, written text has indicated a human author - this is no longer true, and I think this is going to be very difficult for us to wrap our human brains around fully.

I'm getting a lot more done by handing off the code writing parts of my tasks to many agents running simultaneously. But my attention still has its limits.

Yes, the LLM is able to see the entire prior chat history including tool use. This type of interaction occurs when the LLM fails to read the file, but acts as though it had.

> It has been observed, sometimes, a model will write perfectly normal looking English sentences that secretly contain hidden codes for itself in the way the words are spaced or chosen.

This sounds very interesting, do you have any references?

I had never heard of Geese until all the stories about how Geese bought their popularity. Now I feel I should give them a listen to know what all the fuss is about!

Why aren't we talking about an EC2? Because this is a thread about the Gemini inference API. Loss of service would be restored on payment, not permanent. But that's besides the point: I as the customer set a limit, and you as as the service provider did not adhere to it.

I've worked on a number of systems and while it is sometimes impossible to stop at an exact limit, I am confident that it is feasible to stop with less slippage than occurred in this scenario. And at the companies I've worked at, within a margin of error that we're able to absorb any slippage ourselves, as these losses are made up elsewhere, and are worth the customer goodwill. If we can do it, I'm sure Google can.

If I set a limit, and you cut off my service because I reached the limit, I would definitely not "complain just as much" as if I set a limit and you allowed me to spend past it.

We're not talking about an EC2 or EBS volume here, this is access to an API.

van Gogh didn't become van Gogh by prompting LLM.

Yes - this puts it perfectly. I am a very fast typist - I can type ~156wpm in QWERTY. When I was a kid and learned about Dvorak, it was tempting - but I already typed so fast that learning another keyboard just seemed like it would cause "misfires" in my brain - and virtual keyboards are all QWERTY.

Same deal with jj vs. git. I've learned git. I've used it for 15 years. I'm proficient with it. I'm sure jj is better - but I'm not sure it's better enough to be worthwhile.

Yes but I would push back a little on the idea that you simply put yourself in a "mindset of writing bug-free code."

Simpler code has fewer bugs. Embedded code tends to be simpler and more targeted in its role. Of course, putting yourself in the mindset of writing simpler code is great too - if you have the time to do so, and the problem you are solving is itself sufficiently simple.