> Excellent technical history, but it misses what made Olivetti incomparable: Adriano's human-centric philosophy that business and human culture were inseparable.
>
> The article mentions worker housing and urban planning in passing, then moves on. But that was the strategy. Ivrea wasn't welfare—it was integrated design. Factory, housing, schools, public spaces all operating under one coherent philosophy: machines and lives should both be beautiful and functional.
>
> [...]
>
> That's why Olivetti succeeded where technically equivalent competitors didn't. They engineered for humans, not just machines.
Two decades ago I randomly found myself in a tiny lecture room with a Very Important Manager from a Very Big European Bank. She started her talk stating "In the '80s, the Italian politics had to choose between the economic model of the Olivetti's family and that of the Agnelli's family. They choose Agnelli's. That was a mistake." Followed by a long string of expletives.
For context and for contrast, the Agnelli family was the owner of FIAT, then the biggest private employers in Italy. They were strongly anti-unions. They even bought the most important newspaper in Turin (the headquartiers of FIAT) to suppress reports of workers initiatives and strikes.
true, '80s were the years that signed the switch from an economy based on products and services (Olivetti) to an economy based on financial papers (Agnelli). If the 1st one was more human sized, the second one forgot about people.
The fall of Berlin wall was signalling that politicians were all with "us".
> The whole patch quilting thing is awful. Just keep the patches as commits.
I'd say that `quilt` the utility is pretty much abandoned at this point. The name `quilt` remains in the format name, but otherwise is not relevant.
Nowadays people that maintain patches do it via `gbp-pq` (the "patch queue" subcommand of the badly named `git-buildpackage` software). `gbp-pq switch` reads the patches stored in `debian/patches/`, creates an ephemeral branch on top of the HEAD, and replays them there. Any change done to this branch (new commits, removed comments, amended commits) are transformed by `gbp-pq export` into a valid set of patches that replaces `debian/patches/`.
This mechanism introduces two extra commands (one to "enter" and one to "exit" the patch-applied view) but it allows Debian to easily maintain a mergeable Git repo with floating patches on top of the upstream sources. That's impossible to do with plain Git and needs extra tools or special workflows even outside of Debian.
Also rebasing has less information available to it, so it's less likely to update cleanly than merging. Don't do it!! Just consider the diff between the new head and upstream as "the diff" and describe the reasons for it.
What, no. In a merge you have two parents and their histories. In a rebase you have... the same thing as-if you had merged a fast-forward-ready branch. It's the same thing.
If you insist you can add Merge commits to bracket fast-forward pushes, but arguably there is no need, and especially so for something like Debian packages where the convention would be that Debian's patches are "always on top", so you can see them by doing `git log ${base}..${debian_release_branch}` for any release. (And what's the base? Whatever upstream branch/tag the Debian release is based on, but you can add more tags with a Debian naming convention to denote the bases.)
In practical, large-scale usage, the default merging algorithm works better than the default rebase algorithm. But I did switch teams from using a rebase workflow to a merge workflow and manual conflict resolution needs went way, way down. Obviously there are confounding issues, but that's my experience.
If your patches never touch the same files as others, I think it doesn't matter. But, IIRC, if patch A and patch B both touch file F, and the changes in patch A are in context for diffs of patch B, it always fails if patch A changes patch B's context, but since merging incorporates all changes at once, these separate context changes don't apply.
It's been a while, but it might be only when you need to manually resolve patch A, then you also have to manually resolve patch B even if you wouldn't have had to touch it in a merge scenario.
> In practical, large-scale usage, the default merging algorithm works better than the default rebase algorithm.
You're referring to having to do conflict resolution for each commit in the rebase series, as opposed to all at once for a merge. Either way if the upstream has added thousands of commits since the last time, you're in for no fun.
This is a case where Git could be better, but as I responded to u/gioele there exist tools that greatly help with the conflict resolution issue, such as this one that I wrote myself:
which basically bisects to find the upstream commit that introduces a conflict with each commit in the rebase series.
This has one major advantage over merge workflow conflict resolution: you get the most post possible context for each manual conflict resolution you have to do! And you still get to have clean, linear history when you're done.
What siblings say. What you want is `git rebase`, especially with the `--onto` and `--interactive` options. You might also want something like bisect-rebase.sh[0], though there are several other things like it now.
Rebasing would mean there's no continuous versioning of the "patches on top", which might be undesirable. Also, the history rewriting might make cooperation difficult.
Merges would avoid those problems, but are harder to do if there are lots of conflicts, as you can't fix conflicts patch by patch.
Perhaps a workflow based on merges-of-rebases or rebase-and-overwrite-merge would work, but I don't think it's fair to say "oh just rebase".
> Rebasing would mean there's no continuous versioning of the "patches on top", which might be undesirable. Also, the history rewriting might make cooperation difficult.
Let's say you have these version tags upstream: foo-1.0.1, foo-1.1.0, foo-1.3.0, and corresponding Debian releases 1.0.1-0, 1.1.0-0, 1.1.0-1, 1.3.0-0, 1.3.0-1, and 1.3.0-2, and the same 3 patches in all cases, except slightly different in each case. Then to see the several different versions of these patches you'd just `git log --oneline foo-${version}..debian-${version}-${deb_version}`.
Gerrit introduces the concept of Commit-Id; essentially a uuid ties to the first review which merged a proposed commit into the trunk.
Cherry picks preserve that Commit-Id. And so do rebases; because they're just text in a commit message.
So you can track history of patches that way, if you needed to. Which you won't.
(PS some team at google didn't understand git or their true requirements, so they wasted SWE-decades at that point on some rebasing bullshit; I was at least able to help them make it slightly less bad and prevent other teams from copying it)
But that Commit-Id footer has no functional effect. I don't see how it would help me if I have a clone of the repo, and my upstream (in this case, the debian maintainer) rebases.
> Which you won't.
Why not? Doesn't it make sense to be able to track the history of what patches have been applied for a debian package?
You need additional tooling to make use of Commit-Id. With Gerrit, it does link them all together.
> Doesn't it make sense to be able to track the history of what patches have been applied for a debian package?
... no. Each patch has a purpose, which will be described in the commit message. Hopefully it does what it says it does, which you can compare with its current diff.
If it was upstreamed with minimal changes, then the diff is near-empty. Drop it.
If it was upstreamed with significant changes, then the diff will be highly redundant. Drop it.
If the diff appears to do what the commit message says it does, then it probably does what it says.
If the diff is empty, either it was upstreamed or you fucked up rebasing. Don't be negligent when rebasing.
We need to drive down the cost of dealing with nuclear waste. Possibly to zero, because that is a cost that will have to be paid basically forever.
Between 1961 and 2023 «5,600 TWh of electricity were generated from nuclear energy in Germany». [1]
Every year Germany spends (and will have to spend until the end of time) at least 2 billion Euros just to keep the existing nuclear waste safe [2] (more than half of the yearly budget of the ministry of the environment and about 0.5% of the yearly government budget). That's a drag. Think about it: it's all unproductive money, that does not produce any new energy, and stopping these payments will cause irreparable damage to the environment. Forever.
They provide plain good ol' GNU Mailman lists. You can bring your own domain or subdomain. They also have a good handle on privacy issues (GDPR requests and so on).
Related to this topic (spouse with Alzheimer), there is a touching story by Alice Munro: "The Bear Came Over the Mountain", the closing story of the book "Hateship, Friendship, Courtship, Loveship, Marriage".
Just a remark: the person whose fingerprints have been reconstructed and that was the defense minister of Germany at time of the stunt (Ursula von der Leyen), is now the president of the European Commission (~= head of the EU government).
Two decades ago I randomly found myself in a tiny lecture room with a Very Important Manager from a Very Big European Bank. She started her talk stating "In the '80s, the Italian politics had to choose between the economic model of the Olivetti's family and that of the Agnelli's family. They choose Agnelli's. That was a mistake." Followed by a long string of expletives.
For context and for contrast, the Agnelli family was the owner of FIAT, then the biggest private employers in Italy. They were strongly anti-unions. They even bought the most important newspaper in Turin (the headquartiers of FIAT) to suppress reports of workers initiatives and strikes.