LegibleCrimson

I feel different about fully open source projects. You are working for free for the benefit of the company, all other companies who want to use it, and the rest of the world. I'm happy to work for free when it benefits everybody equally. I don't care that for profits benefit, because they all benefit potentially the same amount. It's a boon for the world.

With open core, you're working for free for the benefit of the leverage of a company to better position their secret sauce. It asymmetrically benefits the company more than everybody else. I only do that when I'm getting paid to do it.

Those are better, but still don't give a ton of calories or protein all said. You have to eat a lot of oats to live off them.

I don't think of that as covering "most canned foods", though. Most canned foods are pretty ordinary canned foods, and aren't highly processed.

It's a stupid suggestion anyway. Most breakfast cereals are basically pure carbs, with nothing in the way of protein and very little fiber. You can get some protein in the milk, but that's not the cereal itself anyway, and also has a surprising amount of sugar. Two meals a day of breakfast cereal is not a nutritious diet.

Once in a while as a treat, sure, given that they're basically crappy candies anyway, but you shouldn't be living on mostly breakfast cereals. The affordability argument dissolves when you're trying to actually get a reasonable nutritious balance from them, given that the average bowl of cereal gives you about a tenth your needed daily calories.

I'm honestly confused why anybody would waste their time working for free to improve an Open Core project. You're donating your labor to a private company to improve their product.

The definition is whatever the majority of people use it to mean. Just like what happened with REST. It might not be palatable, but you either choose to understand what people mean, or you struggle and shout into the void about people with a common understanding that doesn't match what you think a term should mean.

It's pretty rude to ignore a PR for months only to give it a rejection that you could have levied earlier, especially for a feature that wasn't even in the Enterprise Edition when the PR was created.

You're significantly more likely to injure your head on a bike than in a car without a helmet.

In a world where bikes had crumple space, seat belts, and didn't fall over, it might be different.

That article doesn't at all contradict my point.

> You should definitely try things that might fail. > > However, failure within those projects should be actively avoided.

I agree with that. I agree with all of what you're saying. I don't think the pithy sayings are telling people to actively fail, though. The point is to not become overly avoidant of taking on ventures because of a fear of failure. And I think the avoidance of failure is a bigger thing than you're making it out to be. Most people who I know who don't achieve their goals and dreams fail to do so because they simply never start, or they start and see how hard it is going to be and then give up. I know very few people who jump headlong into things and fail often, and they are also the people I know with the most successes in their lives. Anecdotal, but the fear of failure preventing people from attempting anything that they want to achieve is a real and very common thing.

Or they were more naturally inclined than you, or that they had more existing analogous experience than you.

Either way, if your 49 failures were unacceptable, then so we their 24 failures. This conversation was never about comparing ourselves to those who are better or worse, but about the meaning and acceptability of "failure".

Failing to perform a piece is not a mistake, it's a failure. The word simply means "an attempt that did not succeed". Failed attempts are a natural part of progress and learning.

A musician fails to perform a piece hundreds or thousands of times while learning it. A programmer fails to apply a concept many times until they fully understand it. To imply that failure is not normal and not alright is to imply that everybody should be able to perfectly do anything in their life without any prior practice.

Clearly, the word "failure" in this context is insufficient, because we all would agree that some failures are unreasonable and some are an absolutely normal and necessary part of personal growth.

90% of my projects are failures, and the 10% which are successes would have never happened if I was too afraid to start them. The successes looked just as likely to be failures as the actual failures from the outset.

I disagree that "failure is bad and should be avoided". The degree to which failure is bad and should be avoided depends entirely on the gravity of the consequences. When taking on an ambitious programming project, "failure" is just an unfinished project and a loss of time. It's clearly a different world than something like quitting your job to try to become a professional actor.

Judgement shouldn't be based on whether somebody is failing at something or how many mistakes they are making, but the comparison of the positive vs the negative consequences. When learning something new, you will always make many more mistakes.

The problem with both the pithy quotes and your response (which is, I think, largely reasonable) is that neither one actually defines any criteria for success or failure, or what is an "unreasonable" number of mistakes. It just ends up being a semantic disagreement over what they meant by "failure" and what you understand by "failure", and I think you'd probably end up largely agreeing in the end if you broke down and actually explicitly defined the meanings of the words used.

> apparently dealing with borrow checker ... is appealing.

Yes it is. I love the borrow checker.

Court costs can be much more expensive than the defendant can reasonably afford, even if they're likely to win. The copyright trolls take advantage of this by demanding less money than the court costs would actually sum up to, making it financially pointless to defend yourself rather than immediately pay up.

I agree that the grace period is also not a perfect solution, but I fail to see how anybody could consider the copyright trolls referenced in the article as anything more than predatory drains taking advantage of a legal technicality to drain money from innocent people. An honest typo regarding license text should not cost a person thousands of dollars, and copyright is one of the few places where it can do so, thanks to repeated lobbying and legal abuse.

Likewise. There's something about MacOS's touchpad handling that makes it impossible to get it to feel good for me. The default Gnome settings on a Mac touchpad feel perfect.

The cleanup and uninstall concern is one of the reasons I run as many things in containers as I can. It's so easy to blow away a container and its volumes compared to traditional software uninstallation.

I find them useful, as do many others. They can do many things that commit messages obviously can't.

You can technically coordinate many of the other things through external tools like email, but email sucks, and there is real value to having them all in one place.

Obviously, I'd rather have all these things part of the repo itself, like with Fossil. What's what Radicle is trying to do, it looks like.

THANKS SHITMAN!

It is if you don't care about any of the other things that Git brings to the table.

I fail to see what `git rebase` has to do with issue trackers, project boards, wikis, repository notifications, or any of the other things that GitHub does. I use git forges as well as `git rebase`. Neither of these things precludes the other.

The problems with curl-bash are overblown. You are pretty much exactly as vulnerable running pip install, npm install, or cargo install.

Not that curl bash is great, but it's not uniquely horrible when the goal is to run some unvetted code on your machine.

If you care about security, you have to either vet the code or trust the source. When you install through your package manager, you're trusting the maintainers. When you install from curl bash, a random website, or any unvetted software source, you are electing to trust the developers or site directly.

Not hard with RST/Sphinx, but that comes with other usability nits.

Because mentioning it works. As somebody who uses many different languages professionally, I immediately assume projects written in Rust are more reliable, more robust, and more efficient. My own projects are higher quality when I can use Rust to implement them, despite having much more experience with most of my other languages.

As a user experimenting with tools, ones written in Rust have justified these prejudices. They simply tend to be better.

It's an effective advertisement. I'm a little confused why there's always someone who brings it up. It's not like programming language makes absolutely no difference. If it's written in C or C++ and it's relatively young, I'll expect it to be unstable and to have a clunky and unpleasant interface. If it's in Go, I'll expect much better in stability, but with a funky CLI. If it's Python, I know it uses argparse, so at least the CLI will be consistent. If it's Rust, I expect it to be fast, to have very few or no panics, to have no memory issues, to have zero null pointer problems, and to use clap for a very consistent, predictable, and good looking CLI.

The language has built a good reputation; I'm shocked that commenters on HN have somehow avoided picking up on that and are perpetually surprised that it has a real audience.

I found k3s pretty easy to spin up.

Microservices (or really services in general) solve some of these packaging issues. If I have my application that depends on package A that pulls in dependency C version 1.x, and also on package B that pulls in dependency C version 2.x, this just doesn't work in Python, and many other languages. The only way to make it work is either rectify my dependencies so all my versions match (by running one of your dependencies out of date) or to split them up so my application is composed of one service that pulls in package A and another that pulls in package B, and have them talk over some IPC.

Anecdotally, my young children both love brussels sprouts. They're actually one of the very few greens I can get them to consistently eat, other than green beans.

I'm covering the problem statement. I'm ignoring the cases where Monty revealed a car because it didn't happen. You can't chalk it up as a win or a loss, because it didn't happen.

It's always "You choose a door, the host reveals a goat behind another door. Do you switch?" The scenario does not include him revealing the car.

If he intentionally chooses a goat, switching gets the car 2 times out of 3.

If he chose randomly and just happened to choose a goat, switching doesn't matter. It's 50/50.

Of course, these aren't the only scenarios. As others have mentioned, if Monty can decide whether to reveal what's behind a door, he can act maliciously and only reveal a goat if you've already selected a car, and switching will always make you lose. Without knowing these constraints, a single answer isn't knowable, as you mentioned before.

It's actually counter-intuitive. I was going to argue on your side, and then I wrote up a quick program that proved me wrong[0]. Let's go through the scenarios, with Goat A, Goat B, and Car C. In the scenario where Monty picks a door purposefully, always selecting a goat, the scenarios are:

    You picked A, Monty showed you B, and you switch to get C.
    You picked B, Monty showed you A, and you switch to get C.
    You picked C, Monty showed you either A or B, and you switch to get the other goat.

So a 2 / 3 chance of getting the car if you always switch.

If Monty is choosing randomly, we have the following scenarios:

    Initial Choice | Monty's choice | Remaining Door
    A | B | C
    A | C | B
    B | A | C
    B | C | A
    C | A | B
    C | B | A

But we know in the problem statement that Monty hall showed us a goat, so we can eliminate possibilities 2 and 4 to get:

    Initial Choice | Monty's choice | Remaining Door
    A | B | C
    B | A | C
    C | A | B
    C | B | A

Whether you switch or not, you have a 50/50 chance.

I'm not great with probabilities, but the major difference I can see is that in the first scenario, if you pick the car, Monty will either show you the goat A or B with equal probability as a part of the same 1/3 scenario. So you have really:

    1/3: You picked A, Monty showed you B, and you switch to get C.
    1/3: You picked B, Monty showed you A, and you switch to get C.
    1/6: You picked C, Monty showed you A, and you switch to get B.
    1/6: You picked C, Monty showed you B, and you switch to get A.

But in the second scenario, each of those options is actually 1/4, because he was choosing randomly. Most importantly, each option was a 1/6, but two options where you selected a goat were eliminated because those were ones where Monty selected the car.

[0]: https://gist.github.com/Taywee/2ba202b1bf7af40293ecffb01c2ab...

Significantly better than some historical standards and significantly worse than others. We aren't doing the best that has ever been done across all cultures and history in this regard, not by far.