dolni

Thousands or millions of times less energy used is a whole lot better for the environment, too.

You weren't present to speak to how she pushed back on "hey you guys" in the example I provided.

She was, without a doubt, offended.

I've watched a woman walk into a space to meet her group -- all of whom were women -- and address the group with "Hey you guys!"

I've also worked with a woman who was extremely displeased to be greeted with "you guys". I found her absolutely insufferable.

The reason it feels bad to people who use "you guys" in a gender neutral way is what it says about the offended person. The offended person has a pet peeve, and if you don't accommodate it, it will be a problem. That's pretty much the definition of an insufferable person.

A person who is well-regulated wouldn't make a stink over something so trivial. Which then tells you that the person is going to make a similar stink over other trivial things. Ad infinitum.

If a client sends its game inputs and those inputs can be analyzed for legitimacy, I think you could make some decent progress on this problem.

It doesn't solve all methods for cheating, and it doesn't prevent cheating. But it does help you remediate it.

Are game companies training AI models to detect aimbot-like crosshair movement, for example?

Human beings act in accordance with their genetics and life experiences. They do this to such a degree that people can, at a young age, internalize maladaptive behaviors which require an enormous level of self-reflection to overcome, if they even can.

I think presuming that humans don't act "as instructed" is a bit too generous an assumption.

LLMs are capable of declining to do things. They're also capable of trying to do things and getting them subtly (or very) wrong.

A lot of this hinges on defining consciousness. I think there is more to the story than what human beings experience.

Do LLMs have an experience very similar to human beings that we would describe as consciousness? No, I don't think that.

I think the bar for consciousness is something more like experiencing a dream. You have a "mind's eye". The experience of existing, rather than nothing. Does that exist somewhere under an LLM? I don't know, but I think confidently claiming that the answer is no seems a bit of a rush judgment.

I think that you are defining consciousness in such a way as to exclude everything which is not the human experience by default.

When I go to sleep, I dream sometimes. There is "a place" somewhere that I can see and hear things in my mind. It's not physical, but it's real.

If a collection of GPUs had something like that, would it be conscious?

I don't know that is true. I'm saying it seems absurd to strongly claim that it is absolutely false.

Why are you so convinced it isn't conscious?

Our brain is matter and electrical signals. So are GPUs. We're just not made of silicon.

Because some things are politically incorrect to say.

If those things are left unsaid and everyone still understands what's being referred to (even generally) there can be some alignment on the issue.

Some people with ideological axes to grind like to pick fights on particular points, even (perhaps especially) when it is not constructive.

There have been multiple points in my career where I framed a problem as simple in my head, and it mostly was.

But then, one small detail changed everything. And it wasn't something I'd have thought of until I was writing the code.

I shudder thinking about the number of these issues hiding in LLM-generated code.

As a worker, you can exercise your voice... by getting another job. That is your vote.

The power of your vote is proportional to the value you bring.

A while back I threatened to quit because I had a team dynamic that was untenable. I made a management change mandatory.

I got a new boss. The old boss was later terminated.

Agree, not expanding is dumb.

One of the major benefits of a shell-based approach is your env vars could be generated from the output of a command.

Which can be trivially used to populate secrets from whatever your secret store of choice is.

Now we've also cleanly solved secret distribution for developers with one less dependency!

Dotenv is definitely something that should not exist.

Direnv is the right way to go if you want a tool for this. Otherwise dotenv's implementation in bash is essentially `set -a; source .env`. Look ma, no custom parser!

Seems really silly to have a library do what two lines of shell can reasonably accomplish.

> If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base.

It's low priority in the sense that people in charge tend not to value it.

That's different from saying it is not impactful, or wouldn't lead to a good business outcome, if the software were built better.

Software that needs to be babysat is an ongoing opportunity cost.

> The alternative is not to invite people who have no experience to build bridges or perform surgeries.

You state this so confidently, like every person who walks through the door to interview will be 100% honest about their level of experience.

Have you ever interviewed? Nobody _wants_ a software engineer on their team who is awful.

Sometimes they slip through the cracks for a variety of reasons.

It's not science, but also a lot of stuff that purports to be science is not. "Science" is subject to many of the same forces that politics is.

Using your personal experiences and the personal experiences of people you trust as an anchor is a good thing. It keeps you from falling for propaganda. Note that this DOES NOT mean studies conflicting with your personal experience are all wrong.

The tricky part here is understanding the limit of what your own experience can tell you.

> Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.

The entire point of slowing down is so you don't do this. Understand the problem well first, so you don't waste time building something that was never viable in the first place.

The author isn't advocating for perfect. You have to understand the problem well enough to know what all of the critical assumptions are. Some assumptions will derail an entire project if you get them wrong. Others will be a minor inconvenience, at worst.

In software, having a solid handle on future architecture means you can speak to how unanticipated new features fit in. You know what parts you can skip for now, and have it not be a big deal.

I've started to wonder if many of the people obsessed with speed lack capability. If you can't build something well, you can try building something poor quickly. This certainly applies to my current employer.

I think the answer to your question is the simple and unfortunate one: groupthink.

So many businesses are pushing AI hard. People with varying levels of job (in)security want to be seen as "leading the charge" into a post-AI era.

LLMs can do some really impressive things, don't get me wrong. But I regularly find massive blunders in the code it produces.

And that actually makes sense if you understand how LLMs operate and the quality of software on GitHub.

I'm not a physicist but I've always seen physics as a bit hand-wavy myself.

Dark matter is a great example.

Our understanding of gravitation didn't cleanly apply at ultra-large scales so we had to add a massive fudge factor.

You can't "go faster" than the speed of light, but space in between things can expand faster than the speed of light.

It seems like things that are "settled" regularly get an "ope, but except for this special case..." treatment.

Squash merging PRs makes your commit log is far less useful.

The PR reviewer isn't the only person who will ever review your code, you know.

Good to know. That seems like it comes with its own set of issues.

Interesting idea but this seems woefully inadequate for password management.

The first thing that came to mind for me: how do you change a single site's password? The article doesn't say. It only mentions that changing the master password would require changing all passwords. That also seems like a complete non-starter.

There is an array of useful functionality that modern password managers provide, too: password sharing, saving select file content securely, password history, storage of security questions and answers, storing username (when you use something atypical for anonymity).

I can't help but feel like this idea is a dud. It's neat in an academic sense but it can't seriously compete with what already exists.

> but also have places where getting to a government office to get such an ID is difficult or expensive

Where in the US do you find it's difficult for people to get an ID? Where is it not? What percentage of the population has an ID in a place where it's difficult to get one vs somewhere it is easier?

What constitutes an ID being expensive?

Nearly every country in the world requires proof of citizenship to vote. How is the rest of the world dealing with this problem? Do you think that their democratic processes might be compromised because of it?

What are some scenarios where a vehicle owner knows that the vehicle is being driven by someone with a license, but not who that person is?

If it's their vehicle and the vehicle wasn't stolen, the owner should know who was driving it. Courts do compel people to testify sometimes (when it is not self-incriminating).

We are talking about two different things.

I am talking about American support for a working legal immigration process, and enforcing that process. Not everyone agrees about exactly what it should look like.

I'm not talking specifically about the actions Trump is taking or the job ICE is doing currently. The current sentiment around ICE is very negative.

The law being alluded to here is not "so unpopular".

Immigration enforcement is overwhelmingly favored by Americans, including immigrants.

The implementation has been awful, for lots of reasons everyone already knows. However, the situation has also been significantly escalated by often-violent obstructionists.

Obstructing enforcement of the law when it's something Americans voted for is not patriotism. It's undermining democracy.

Our law is explicit: immigration is the domain of the Federal government exclusively. State and local governments should "take it" as you say, because that's the law, and we should respect the law. If you don't like it, protest. But most are fine with enforcement in a reasonable way.

Trump and his cronies shoulder a lot of blame for how things have gone in Minneapolis. But so do democrats for stoking the flames.

Vote independent.

When a significant share of the taxes you pay are mishandled or lost to fraud, yes it is a punishment.

That's been happening for a long time in the US. Staggering military industrial complex. Tens of billions lost in COVID relief. Billions lost in Minnesota due to unchecked privatized social welfare fraud (which has been known about for a decade).

Some mistakes will happen. What we have is unacceptable. If the government can't handle the money responsibly, it has no business collecting the money.

The distinction is that in America, we are obligated to take care of Americans.

If people immigrate to America, the arrangement should be mutually beneficial.

We are not, and should not be, the self-appointed saviors of the world.

Thanks for building a cool piece of software!

Traefik really is awesome once you can get your head wrapped around the configuration.

Hi there. I'm a brand new Traefik user. It's bundled with k3s, so I set it up for my homelab on a single node cluster. I'm a technology professional who has worked in infrastructure and software roles for more than 15 years.

I appreciate that you revised the docs, but I still found it quite difficult just to get started. My experience was poor enough that I almost switched to Caddy. The thing that kept me from doing that is that Caddy requires a custom container build for DNS-01 ACME challenges which I didn't particularly want to deal with. I found Caddy's documentation much easier to grapple with, so that could serve as some inspiration.

I have some feedback I'd offer of my own, too:

1. I'd recommend you take a look at the Divio documentation system: https://docs.divio.com/documentation-system/. Your documentation aligns to this vaguely, but I'd recommend reading about the different doc types and applying that feedback throughout the docs.

2. Traefik's tutorial and how-to docs are very dense and feel overwhelming. [1] Related to my first point, I think you're trying to provide too much information in the wrong places. Tutorials and how-to guides should be very focused and limit explanation to only that which is absolutely necessary.

3. Reference and understanding docs are mixed together. I'd recommend using an approach more like Caddy's, where the config reference (https://caddyserver.com/docs/json/) shows prominently what the expected config schema is, and all of the fields are explained briefly. If there is very nuanced behavior for a particular option, consider moving that to a separate reference or explanation page.

4. Having a few How-To guides for the most common patterns which include complete configurations would be helpful.

[1] Here are some concrete examples:

- On https://doc.traefik.io/traefik/setup/kubernetes/, there is a whole introductory session about setting up Kubernetes and I have to scroll before reading anything related to Traefik. It's not only unnecessary -- it's noise. Nobody is going to consult Traefik's docs for setting up Kubernetes, so just omit it.

- https://doc.traefik.io/traefik/setup/kubernetes/ and https://doc.traefik.io/traefik/getting-started/kubernetes/ are different pages which seem to explain mostly the same things. They both include too much irrelevant information, like overly explaining what Helm commands do. Similar to (1), it is not the job of Traefik's documentation to explain Helm to me.