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

> If they're self-made, they earned the praise.

They aren’t and they didn’t.

> Being a self-made billionaire means they created a billion dollars of value. They didn't take it from you or anyone else.

Nobody is a “self made” billionaire. That value you’re talking about didn’t just spring into existence. It had to come from somewhere. There is always a source.

Who flew the rocket? Who built the rocket? Who built the parts for the rocket? Who mixed the fuel?

Building big ambitious things is a good thing. But consolidating an amount of money that nobody could ever reasonably spend into the hands of one person (especially when that money is just the excess value produced by the workers) is unethical and unneeded.


> That value you’re talking about didn’t just spring into existence. It had to come from somewhere.

Are you arguing that wealth is not created, but is transferred? Where was SpaceX's value transferred from? Where was the current wealth in the United States 250 years ago?


What you're referring to are called "expenses". The value created is what somebody is willing to pay for a piece of that action (i.e. an ownership share). Expenses reduce the value.

For example, if you bake a cake the value you created is what you can sell the cake for minus the cost of the ingredients and the use of an oven. For SpaceX, the money spent to buy materials and pay employees takes away value.

> that nobody could ever reasonably spend into the hands of one person (especially when that money is just the excess value produced by the workers) is unethical and unneeded.

Musk doesn't spend much of his money. He invests it in creating more businesses.

> is unethical and unneeded.

You're arguing that Tesla, SpaceX, Starlink, etc., are unethical and unneeded. None of those companies would exist without Musk investing his fortune into them.

BTW, why don't you and your friends get together and start a rocket company and make yourselves billionaires?


This is usually the part of the conversation where someone mentions slave labour in an emerald mine and immigration fraud and then comes the part where you usually say something along the lines like "hasn't been proven in court!"

Musk started with a $20,000 loan from his family. You could buy a used car for $20,000, no emerald mine and slaves required.

Musk parlayed the loan into $trillions.


It would have been so cool if you didn't derail this conversation about 'Confronting America’s gerontocratic crisis' with your Elon Musk fanboy-ism.

So cool.


I am indeed an unapologetic Musk fanboy. For good reason.

If you've grown a ton of tomatoes, you're probably doing it for the express purpose of profiting from it. To dial back the scope to something more comparable, if I have 4-5 tomato plants, I'm going to have all the tomatoes I want and then some. In that case, yes, I'm absolutely going to give away some tomatoes so that other people can enjoy them (as opposed to them ending up in the compost bin).

> I just tap on that to open the relevant app, if I care to see more.

The key difference between what you're doing and what Homebridge enables is to make the relevant app the "Home" app. If all of my IoT devices are controllable (and can be automated to some degree) through a single pane of glass that I can share with my wife, that's a big improvement over "Ok, to get access to our cameras, you need to go install these three apps and log in to all of them and accept my sharing invite, etc, etc".

Yeah, you can talk to Siri to control the devices sometimes, but that is at the very very bottom of my list of benefits. I want the app UI specifically, and Homebridge enables that. (one concrete example: Ring doorbells don't play nicely with Homekit on their own, but you can install a Homebridge extension and then your doorbell camera shows up as a Homekit-compatible camera in the Home app).


Gotcha, sounds like it makes sense for some uses cases, but perhaps not mine at this point. Seems like the killer app is automations, and I just care about notifications. I'm glad it exists, and presumably at some point I'll give it a try (especially if it resuscitates my Wemos, which it sounds like it can).

> A patient doesn't lean over the operating table and tell the surgeon where to cut.

Web design _does_ sound much easier when clients can be anesthetized. :)


Peak east coast US! You can travel three states of distance and back in a day or less on the east coast.

Three states over and back would be a day or two minimum, but potentially nearly a week on the west coast. (Depends on start and stop locations obviously, but if you start from eg Portland, three states over could be the Dakotas).


I, too, find myself wondering why this seems to be such an intractable problem. Maybe it's just misaligned incentives? That is, the phone companies really only care as much as they need to in order to prevent you leaving for another phone company.

From a technical perspective, it doesn't seem to be _that_ difficult: it seems like KYC but for anyone who wants automated access to telephone networks. I know there are some existing efforts there that are more technically comprehensive than that (SHAKEN/STIR), but I don't know where they're at in terms of adoption/rollout.


Can you please make an image that is like 10x bigger? Like 30px font and include all the alphanumeric characters? This font looks so familiar.


In other ecosystems, I could see how this could be a problem, but I don’t think I’ve ever had a problem with a Go upgrade.

What’re the actual, practical results of a package pushing you towards a higher go version that you wouldn’t otherwise have adopted right away? Why is this actually important to avoid beyond “don’t tell me what to do”?


One potential reason is that Go does drop support for older OSes sometimes. For example, Go 1.22 is the newest version that works with older Mac OSes.

https://go.dev/doc/go1.22#darwin


shrug maybe so. But then again, I can't say I'm too torn up about losing support for an EOL OS version.


Sure, but that doesn't address GP's argument, which I _think_ is "there's a time and a place for those criticisms, and _literally every time emacs is brought up in a public forum_ ain't it"


look i just made a single point about VIM OVERCOMING THE LOSS OF ITS CREATOR by pointing to emacs as a WORSE CASE.

I didn't ask for these weirdos to come demanding to litigate every detail of every sick quote he's ever given.

but i will not stand down to karma bullying to cover up sex crimes of a person just because i like his software.


I hope it's not my comment(s) that triggered your anger, still, please accept my apology.

> Stallman deserves to be criticized for his own positions.

I fully agree. I'm just asking to try to decouple that from Emacs.

> because i like his software

Can we agree that Emacs is no longer "his software" and it stopped being that long ago? Governance and ownership have separated from authorship, right? The point is - when the scandals got out, we didn't circle the wagons. If the tool and the person were tightly coupled, you'd expect the community to defend him. We didn't. The separation was/is real, not just rhetorical.

Sure, yes, GNU/Emacs is still officially an FSF project, and the FSF is still Stallman's institutional creation, even if he's been sidelined. His philosophical fingerprints - GPL, copyleft, free software ideology as distinct from open source - are baked into the project's DNA in ways that aren't cosmetic. So there's a version of "his software" that's genuinely hard to dislodge. I'm not trying to argue that or erase his authorship, no.

But can we still find a way to deal with it differently? Say:

- Wagner was viciously antisemitic; the music is still the music

- Caravaggio was violent, possibly a murderer, yet painted some of the most incredible art pieces

- Heidegger was a Nazi sympathizer yet produced genuinely influential philosophy

People are complex creatures, sometimes we need to decouple the evaluation of the contribution from the evaluation of the person. I just want to avoid circles like: "using/praising Emacs is bad because Stallman is bad, therefore his creations are tainted".

I'm not defending Stallman or any of his behavior (good or bad), I'm defending something the community itself largely built, maintained, and steered. When people outside of the loop hear these things together, it hurts me personally - the conflation feels like a category error aimed at something I personally have a long relationship with.

The annoying thing about these whole thing is that you threw the Stallman material probably without even thinking about any of that. It's rhetorical ammunition, not a serious argument. You're not really engaging with what Emacs is to its users - just reaching for the most socially radioactive association available to win a point. And I'm now having to "defend" against an argument that was never made in good faith to begin with. Which is exhausting in a particular way - not because the argument is hard, but because you have to take it seriously even when it wasn't offered seriously.


> it makes history a lie that eventually collapses under its own weight in large teams

Can you please elaborate on this? I've seen this argument from others as well, but nobody has ever been able to articulate what that actually looks like and why rebasing branches specifically is to blame.

My perspective: whatever happens to the commit history on your non-`main` branch is your business. I don't care about the specifics until your work is merged into a shared branch that we all understand to be the canonical representation of the software we're working on.


I'm not the GP, but I've seen "rebase lies" in the wild.

Suppose a file contains a list of unique strings, one by line. A commit on a feature branch adds an element to the list. Later on, the branch is rebased on the main branch and pushed.

But the main branch had added the same element at another position in the list. Since there was a wide gap between the two positions, there was no conflict in Git's rebase. So the commit in the feature branch breaks the unicity constraint of the list.

For someone that pulled the feature branch, the commit seems stupid. But initial commit was fine, and the final (rebased) commit is a lie: nobody created a duplicate item.


Thanks for that. I'm definitely familiar with that kind of situation, but what I'm not seeing is how that leads to history "collapsing under its own weight" in larger teams. That seems like a relatively straightforward rebase error that is easily corrected. (Also, if it is important for that list to only include unique items and you were able to merge it anyway, maybe that also reveals a gap in the test suite?)


> Can you please elaborate on this?

You're replying to an LLM-powered comment generator.


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

Search: