- what are you trying to say here?
- > but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs.
I don't have experience in this world, indeed.
But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? The application code is the same (same version), the configuration (which is external to the application) is different.
Your build system takes your application code and the configuration as input, and outputs artifacts for that specific combination of inputs.
- Branches are mutable and regularly point to a new commit. Branching is selecting an active line of development, a set of commits that change over time.
That's why git also offer tags. Tags are immutable.
That's an important distinction.
- > There's nothing inherently wrong with having per-env branches
There is when you stop thinking in terms of dev, staging and prod, and you realize that you might have thousands of different environments, all named differently.
Do you create a branch for each one of them?
Using the environment name as branch name is coupling your repository with the external infrastructure that's running your code. If that infrastructure changes, you need to change your repository. That in itself is a cue it's a bad idea to use branches this way.
Another issue with this pattern is that you can't know what's deployed at any given time in prod. Deploying the "production" branch might yield a different result 10 minutes from now, than it did 25 minutes ago. (add to the mix caching issues, and you have a great recipe for confusing and hard to debug issues)
If you use tags, which literally are meant for that, combined with semver (though not necessarily a requirement, but a strong recommendation), you decouple your code and the external environment.
You can now point your "dev" environment to "main", point staging to ">= v1.25.0" and "prod" to "v1.25.0", "dev-alice" to "v2.0.0", "dev-john" to "deadb33f".
When you deploy "v1.25.0" in prod, you _know_ it will deploy v1.25.0 and not commit deadb33f that so happened to have been merged to the "production" branch 30 seconds ago.
- > Tools are just there, it's people who misuse them.
Absolutely. And it doesn't help when people write guides actively encouraging mis-using tools
- Somewhat related...
At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. We have tons of repositories that follow this pattern.
For many of them, each branch has taken of its own life and could be considered its own completely different codebase. It's a nightmare to manage and it confuses developers on a regular basis.
Don't do this.
If you want to deploy different versions of your software in different environments, use SEMVER and git tags. Don't create 1 branch per environment...
I have since edited that starter guide and crossed out this recommendation.
- As a bilingual, non-native, English speaker, grug brain is particularly hard to read and understand.
I don’t understand what « grug » is supposed to mean for example.
That being said I still enjoy the blog.
- Since when? Where did you get this information from?
- People can have opinions and instincts on a subject matter without a formal education in said matter.
- The original statement is not just "we do not facilitate copyright infringement". It has a whole lot of other words.
If your original comment is solely about this revised 6 words statement, then, yes, you are correct, the claim is objectively untrue.
I'm no mind reader though, I assumed you were talking about the whole thing ¯\_(ツ)_/¯.
- TL;DR: I am nitpicking on the use of "objectively untrue" and the implication this disclaimer serves no purpose.
> The creators knew that when they wrote that disclaimer and we all know that reading the disclaimer.
This is the idea I'm pushing back against.
Yes, you are very likely correct in your assessment that the creators know that their software will be used illegally.
No, you are incorrect, in saying this is 1- "objectively untrue" and 2- implying the statement might _not_ have some protective qualities.
To take a purposefully exaggerated analogy: you can believe all day long someone committed murder, it still doesn't make it true. You can argue all day long the authors aren't being truthful, it still doesn't make it true.
> Yet the disclaimer is still placed there like it has some reason for existing beyond allowing everyone to pretend something that is happening isn’t happening
I'd agree with this, and, add that, at the same time, (assuming the USA here) it's probably placed there for legal reasons (whether it factually matters legally or not is a question for an actual lawyer, which, objectively, I am not).
> I’m just remarking on the silliness of the disclaimer.
It feels a bit silly, yes, and at the same time... needed?
- I think it's fair to say that the software itself could/does facilitate illegal uses cases. But with that line of argumentation, then all software facilitates illegal use-cases just by existing.
The statement "We do not endorse, promote, or facilitate copyright infringement, illegal streaming, or piracy in any form", might be poorly written with regards to the fact that just by existing this torrent streaming program _does_ facilitate piracy, but I don't think this was your original argument.
- Torrented material is not necessarily copyrighted material.
It's not unlawful to use bittorent.
- > "Who cares if the words are objectively untrue? We have plausible deniability now that we said them!"
But they are not "objectively untrue". You can argue all day long that you don't believe the author are being truthful, it doesn't make it true.
edit: that being said, in juxtaposition with a copyrighted Marvel image, I could see it being used in court against the author to prove they were all along catering to piracy.
edit2: clearly, I'm not a lawyer
- It's also interesting to see that the author themselves are clearly fighting against their own instinct to use uppercase: the first 2 items in the "here's what happens in that video:" list use uppercase.
- > There was a loud explosion earlier this morning, which may or may not be related, but there aren't any power outages.
Loud explosions happen all the time in SF. Particularly in the Lower Nob Hill / Tenderloin area.
I lived an Lower Nob Hill for many years and heard countless explosions, most often in the middle of the night (2am-4am) or early hours (6am). Often times these explosions M80s-M1000s being dropped and detonated.
Someone was arrested back in 2019 and the explosions reduced dramatically.
This article[0] goes into detail about it.
[0]: https://maxleanne.medium.com/tracking-san-franciscos-mythica...
- Not to mention the silliness of this statement: "This core crypto principle is more relevant than ever in the digital age"
I wonder what crypto-currency looked like before the digital age...
Edit: added -currency suffix to crypto :p
Most tutorial out there encourage you to download someone else's configuration to get going. I don't want to do that. I want to understand at its core how this thing works.
I've read the official nix language documentation, watched YouTube tutorials, read 3rd party tutorials, and still couldn't get going with a simple configuration that would install a few packages.
The nix language is also really unpalatable to me. But I could deal with that if the examples out there showed a consistent way of doing things – that's not the case. It seems one same thing can be done many different ways – but I want to know and do it the right way. I would generally turn myself to the official best practices documentation, except nix' is very short and doesn't help much.
I really want to use nix. There's no question about its advantages. But nix just won't let me (or maybe I'm too old to learn new things).
That being said, I'll probably give it another try this month...