Hacker Newsnew | past | comments | ask | show | jobs | submit | vhiremath4's commentslogin

Might be a dumb question, but isn’t the risk of cold joints proportional to your skill in soldering in general? Important context: I am definitely a noob to soldering

It is, yes. After some practice, you will not get cold joints. Or when there is a danger of a cold joint due to massive heat sinking around, you will know and be extra careful

I will be honest. I love open source. But something that really annoys me about the open source community is that the developers take this holier-than-thou approach to backing up maintainers in circumstances like this, but obviously they are not paying with their own money. They are just complaining, and it feels a lot like virtue signaling at worst and pure naivety at best. It feels extremely disengenous at this point, and it's annoying.

What do we actually know?

1. People are inherently selfish. If you give me this shit for free, I'm gonna use it for free. Obviously everyone is doing this. Spare me the "but I go to this conference or that conference".

2. Code is cheap. Why would I ever pay for something that is not gated behind a service with API limits and costs?

3. Coding as we know it is getting commoditized. That's correct. We are all going to lose our jobs as we know it today. Clearly that's the future. Wake up!

But when making these points, open source devs (and honestly a lot of people on hacker news) whine and complain. I don't really know why I'm leaving this comment - I just feel like I'm at an annoyance breaking point. This guy is obviously struggling to pivot and all the grandstanding and virtue signaling just feels like additional noise and wanting to feel good with very little action.


Because of point 3 most SWE's are also hesistant to pay for software. The positive feedback loop of "I did well out of this so i will support others as well" is over.

When you are thinking your days are numbered any cost to develop software (even token budget) is measured. As coding becomes commoditized the ROI in code will drop of that code (capitalism rewards scarcity; not value delivered) and you suddenly become cost conscious. We are moving from a monopoly-moat like market to a competitive cost based market in SWE as AI improves.


There are agentic ways to submit to the journey even if it’s going to suck for a while and there’s no apparent end in sight. Gratitude. God. Whatever. Lots of people submit by withering away and letting their emotions take them down a path of steady erosion. That is not high agency.


I cancelled my ChatGPT subscription today in favor of using Grok. It’s literally the difference between me never using ChatGPT to using Grok all the time, and the only way I can explain it is twofold:

1. The output from Grok doesn’t feel constrained. I don’t know how much of this is the marketing pitch of it “not being woke”, but I feel it in its answers. It never tells me it’s not going to return a result or sugarcoats some analysis it found from Reddit that’s less than savory.

2. Speed. Jesus Christ ChatGPT has gotten so slow.

Can’t wait to pay for Grok. Can’t believe I’m here. I’m usually a big proponent of just sticking with the thing that’s the most popular when it comes to technology, but that’s not panning out this time around.


I found Grok's reasoning pretty wack.

I asked it - "Draft a Minnesota Motion in Limine to exclude ..."

It then starts thinking ... User wants a Missouri Motion in Limine ....


A seriously impressive piece of work, especially only in 6 months. Bravo! :)


This gave me a good laugh. Thanks for that :)


I really wish the release videos made things a ~tad~ bit less technical. I know quantum computers are still very early so the target audience is technical for this kind of release, but I can’t help wonder how many more people would be excited and pulled in if they made the main release video more approachable.


If you have programming experience, you might find this interesting: back in 2019, when Google announced achieving quantum supremacy, I worked on a personal project to study the basics of quantum computing and share my learnings with others in my blog:

- https://thomasvilhena.com/2019/11/quantum-computing-for-prog...


Excellent thank you!


> Is the solution really to replace even more workers by capital, or do we have an issue with how we measure value that we should fix first?

I have more faith in our ability to solve world peace and AGI than I do in us getting to a more objective way to measure value that everyone can agree and adhere to.


It doesn't have to be more objective, it just has to not run away.

The problem with the wealth-weighted-value that gets optimized by capitalism is that the gini coefficient tips the optimization process from being about doing what other people want to being about doing what rich people want. Rich people mostly want to get paid for being rich, of course, so they pump assets to increase their wealth. Their weight goes up, the objective function pumps assets harder, their weight goes up, the objective function pump assets harder... and gini heads to 1 and you return to a palace economy.

A note of optimism: we've been here before, shortly after the industrial revolution. We've fixed this before, even though Marx predicted that we couldn't. We should all be trying to figure out how to make sure that next time the USA gets neo-Roosevelt, not neo-Hitler or neo-Lenin.


I don’t really understand what you’re proposing. How would we fix things to “not run away”. If we’re not trying to value fix to be more objective, what guiding principle should we follow?

On the wealth weighting, I’m a fan of a 100% inheritance tax tbh. I’m in the “top 1%” and I don’t plan on giving my kids more than a great upbringing and education. I’m not giving them any additional cash injection. I think that solves a lot of the wealth weighting problem by shortening the lifecycle of capital holds, but I don’t know if I’ll ever live to see it (or some form of it like inheritance caps).


Any readings to recommend? :)


> We've fixed this before, even though Marx predicted that we couldn't.

Is it fixed if it falls apart in a couple generations? Maybe flex tape over the problem isn't going to cut it.


I'm afraid that "a more objective way to measure value that everyone can agree and adhere to" is necessary to solve AGI (as opposed to getting extincted by one), and world peace will kind of follow naturally.

In other words: we're screwed.


After going through a bunch of evolutions using Docker as co-founder/engineer #1 at a startup to > 100 engineers, hard agree on this take.

One other reason to not overbloat your images (besides physical storage cost and perf) is security considerations. If you find yourself in a place where you need to meet enterprise security standards, keeping more dependencies in your image and linked to your app code widens your risk vector for vulnerabilities.


You can inject keys into the running container by passing them as environment variables during the docker run command, ideally supplied via a secrets manager.


I understand that at a high level, but the implementation is where I get lost and where I'd love an article like this to tell me how to do it and how to deploy securely vs develop locally. Most of the guides I've seen involving a secrets manager assume you're very comfortable with Docker, but I'm still trying to figure it out and need some hand holding like this article does.


I think this is mostly because that's out of scope of responsibility of docker, and docker compose (for the most part) is only a local dev tool without prod concerns.

For deploying docker containers to production, and how to manage secrets, you'd need to look to that container orchestrator's recommendations. EG K8S secrets. It doesn't make too much sense to put an example of how to use production secrets in a docker guide, because those belong in a K8S/GKS/EKS/DO etc tutorial.

Docker's "interface" is how to accept env variables, it's other parts of the system that need to set those variables.


You can also pass an entire .env file with the --env-file option.


I wish there was some secrets manager that would give me a per-project env file in somewhere ephemeral like /run (bonus points for it disappearing when the computer is locked).

Keeping a .env file around still is still a vulnerability if a device goes missing.


And in the env_file attribute in your compose yaml


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: