Python gets a new governance model

TBH, I had kind of wished that one of you from the Django core would take the reigns next (preferably, you), as a BDFL, since Django was it an extremely well-run project, especially under your leadership.

I believe an open-source project is best run as some form of an oligarchy, but with democratic processes for gaining ideas and feedback.

In my opinion, this kind of shift towards complicated government structures is the end of high efficiency in open-source. The thing that makes many open-source projects so great, other than being open, is that they don’t have a burdensome corporate structure breathing down their necks; so they’re able to turn and burn on projects; they don’t fall prey to sunk cost fallacy as often (thinking back to the efforts to integrate Django Channels that were sidelined, or back further to the efforts at GSOC by some developer, 2 years in a row, to add composite key support, which were also sidelined - futile like this turn into disastrous sunk cost slow train wrecks in corporations, but instead teach us what it is that we don’t want in open-source projects); and only the carrot is in play, for the most part, no stick.

The claimed reinvention from scratch of a text editor, and the nice command, are in fact nothing of the sort. One is a means for invoking a text editor (of one's choice) against particular configuration files, no more a "reinvention from scratch" of a text editor than the vipw command is; and the other is one of the several settings specifying eventual service process state, and is no more a reinvention from scratch than the Service Access Facility's "ulimit" built-in was in 1988.

* https://docs.oracle.com/cd/E19683-01/816-0214/6m6nf1of0/inde...

This is one of the standard parts of service management, and service management toolsets all have to do it, either employing nice or their own mechanisms. Gerrit Pape's toolset does it with the -n option to chpst, for example.

* http://smarden.org/runit/chpst.8.html

Ironically given the subject of Debian, one can look to the Debian package archive (or indeed the FreeBSD or NetBSD ports tree and some others) to see lots of actual reinventions of a text editor.

* https://packages.debian.org/stable/editors/

* http://www.guckes.net/vi/clones.php3

Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.

* https://news.ycombinator.com/item?id=17808251

* https://news.ycombinator.com/item?id=17005677

I agree that preinstalled OSX and Windows offer a better end-user experience. I disagree with some of your other statements though.

> In terms of out of the box stability and support?

How many devices have you used that came with Linux "out of the box?"

> package management hell on Linux

This is actually amusing to me. Windows has had this problem for a long time, they call it DLL Hell. Their solution was to duplicate everything and also to have multiple libcs that are incompatible with each other. Developers seem to forget this exists until they actually try to ship something on Windows. Nowadays, companies will just ship all of their dependencies they need.

Reasonably, developers are reticent to do this on open-source platforms, but this is what results in package friction. Semantic versioning would also fix this, but it's unrealistic to think we could get the tens of thousands of packages in a distribution to follow this. I personally don't think Snap or Flatpack is the answer here either, but Nix is.

Sidenote, I'm curious how you got into "package hell." I generally think things from outside the distro-provided stuff should be installed into /opt. Would you install things into System32 on Windows? My guess is that you either added an additional repo, or you installed a packaged generated by some open source code outside of any repos.

Correct. Plenty of Debian Developers work full time on other software projects. Very often with synergies with Debian.

Yet there's no obvious way for people to realize to what extent Debian influences other projects and companies.

> Ironically given the subject of Debian, one can look to the Debian package archive (or indeed the FreeBSD or NetBSD ports tree and some others) to see lots of actual reinventions of a text editor.

> Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.

My response to both of these are, can you point out any of them that are part of a monolithic system that replaces the traditional PID 0?

Or are you talking about people reinventing small parts of the general system? Yes. UNIX allows people to swap out software for other software. In the original use-cases though, the editor(1), cron(1), and nice(1) were at no point conjoined with the boot menu system, or PID 0.

Indeed, there is a fundamental choice between someone building a replacement for one small part of the general system, to make their life easier, and building a replacement for the entire init system.