dolni

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.

[flagged]

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 the previous point, it is not the job of Traefik's documentation to explain Helm to me.

No, it wasn't always nebulous. Roguelike was a well-established genre for decades before it got hijacked and now means nothing.

Like all genres, games within the roguelike genre (or what some people call "traditional roguelikes") have some variance. But if you played two games in the "traditional roguelike" genre, you'd definitely feel the similarities.

These days if you pick two random games on Steam with the "roguelike" tag, you're going to get two experiences which are not even reminiscent of the other.

The meaning degraded much earlier than just a couple years ago. People thought it was cool so they latched onto it. It seems like that process started 7-8 years ago, maybe even a bit further back.

I ran into one thing with jj that I would say is pretty bad. I love it other than the way it bit me in this one case.

I have a repo with some code that generates a credential and writes the credential to a location specified in .gitignore so it isn't picked up by version control.

I used `jj edit` to roll back to a change before the credential path was added to the ignore file to make an unrelated change.

The result? jj instantly started tracking the credential and I didn't notice it before pushing to GitHub.

Fortunately I did figure it out pretty quickly, but that could have gone very poorly.

See also https://github.com/jj-vcs/jj/issues/7237.

I would strongly recommend you _don't_ get a Framework.

I bought one. It lasted less than a year. One day I pulled it out to use it and it just stopped booting. It had been barely used up to that point. No drops or anything like that.

Support was giving me the runaround, too -- by not using info I provided them, not answering direct questions, and asking me to provide info I had already provided.

Do some research on Framework support. You'll find it is atrocious.

The idea is absolutely amazing and I hope it succeeds. The expansion cards are an AMAZING feature. The problem is that the quality bar just isn't being met, yet.