Show Navigation
Notices by Verius (verius@community.highlandarrow.com), page 44
-
@maiyannah What song is that?
-
@purplehippo Thanks, now I have the German theme song of that stuck in my head again. :P
"Und diese Biene die ich meine nennt sich Maja. Kleine, freche, schlaue Biene Maja."
-
I can't prove it but I strongly suspect a monetization strategy like Caddy has is going to kill a large percentage of significant contributions to the code base. The monetization changes "I contribute to make better software for everybody" to "I contribute to make better software for everybody AND make other people money of which I will not see a single cent". It's purely psychological but people tend to be sensitive to such uneven benefits from a project.
-
@bob On small servers it's indeed a very practical option, except if you're using PHP (php-fpm is still somewhat more work to set up than mod_php). For more complex tasks I still prefer Apache since that's when you run into the open core model of Nginx.
-
Also if I were still running Caddy I'd be looking very hard at a migration to something else. The monetization drive _will_ create pressure on the authors to add features to the proprietary binaries that aren't in the Apache licensed source code. And eventually you end up with Nginx. Except that Nginx is actually a pretty solid piece of software despite the annoying open core model and Caddy is essentially a webserver for really lazy people who can't be bothered to figure out how to configure Apache or Nginx.
-
Lol. Caddy webserver goes proprietary for provided binaries and adds promotions for sponsors in HTTP client headers. Fork happens (named Wedge). First issue in the fork (by fork author): remove references to Caddy. Second issue (by someone working on Caddy): accusation of trademark violation.
Caddy author later writes a post saying people are mean to him over the changes. In that post he says the trademark thing was well handled and amicable between the Caddy and Wedge authors whereas people accused Caddy folks of being mean over it.
Uhm, if you don't search the literally one element issue list and immediately create a lawyeresqe issue about trademark violation that's perceived by most hackers as aggressive. Getting flak over that isn't weird.
-
And of course it turns out things are much easier than I thought since I just need to add ModelAdmin classes for foreign keys to make the edit link show up.
-
Halleluja, at least one package understand the issue with subclassing: http://django-admin-sortable2.readthedocs.io/en/latest/
-
The joys of subclassing as a way to overcome limitations of an original interface: you can define a Django admin inline with ordering buttons by subclassing OrderedTabularInline, you can define a Django admin inline with the ability to create foreign objects by inheriting ReverseModelAdmin, but you can't do both since you'd create a diamond with all the problems that entails.
-
The joy of using a framework where 90% of what ypu want is easy but the remaining 10% is difficult enough that it's _almost_ easiesr to do everything yourself.
-
@gameragodzilla No, no, he'd never just make something suck. It would have to be at least very big and fancy implosions.
-
Frankly I'm less excited about Mastodon adding ActivityPub support as I would be about it removing OStatus support.
-
Ah, MySQL: The CHECK clause is parsed but ignored by all storage engines.
-
Classic code-central FOSS projects don't fork that much. Successful forks are rare and usually involve very clear benefits in the fork, possibly at the cost of the original project's vision.
A few prominent forks:
OpenBSD - Split from FreeBSD because Theo de Raadt couldn't get along with the project leaders and developed into a _very_ security focused BSD.
EGCS - Split from GCC over technical differences, project leaders didn't want to merge in certain patches. EGCS turned out to be technically superior and eventually EGCS was merged back into GCC (which is why many young ones haven't heard of EGCS).
In most cases however the natural inertia of developers on the original project makes a fork die an early and silent death. No fork control tactics are needed or applied.
-
Project-central thinking is most associated with people or companies "owning" a project and deriving significant value from owning it, such as a company monetizing support for "their" project or (and this is a more recent development) an individual monetizing being the face of a project through Patreon. Ironically successful forks most often seem to happen against projects with heavy project-central thinking, when e.g. a company overreaches against the will of the community or is bought and replaced by a not very FOSS friendly company (*cough* Oracle *cough*). In such clear cut cases you'll often see a fork started by a very significant portion of volunteers who don't gain any value from who "owns" the project.
-
All this talk about fork control really highlights two different ways of thinking about FOSS: the project-central and the code-central.
The project-central way says the project is most important and forks are to be severely discouraged as they weaken the project.
The code-central way says the code is most important and who develops it in which project is less important than the four freedoms to use, study, distribute and modify / distribute modifications. Forks may not always be encouraged but they are accepted as an exercise of the four freedoms.
-
@elizafox GS doesn't so much have a failure of fork control as negative fork control. At least with pA the effective project lead (i.e. the only one still working on the project) encouraged Maiya to fork.
Pleroma and Qvitter (Quitter is a family of instances) are not true forks though. They're alternative frontends.
-
@katiekats I would argue it's rather the opposite really. If you can spend all your time bickering about politics it means you don't have any more pressing concerns. I'm not sure where politics belongs on the https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs but I would put it at least at belonging (group signaling) and possibly even higher.
-
@elizafox I agree with your analysis of fork control, but I don't think all major projects have it. Control tactics pretty much require leadership or significant contributors that are bothered by forks. People with a classic FOSS "live and let live" mentality won't be bothered by forking, the occasional flame war aside.
Control tactics really stem from an authoritarian mindset and that goes VERY much against the old hacker culture.
-
@maiyannah From a security POV this makes sense. However Verified Boot / TPM stuff should always be under the control of the device _owner_, not the device _maker_.
Verius
All Jonkman Microblog content and data are available under the