I remember this blog! It was posting diary entries 70 years after they were written. This was a good time in the history of Internet and the diary/blog ended at the dawn of the golden era of the "blogosphere".
George/Eric paid a lot of attention to how many eggs his hens laid. It almost became somewhat of a joke in the comments. But good content!
I really understand your frustration. Everyone developing in Python for a long time has felt it a bit too often when breaking changes (even between minor version updates) once again ruins the day.
But I also understand that the world is not perfect. We all need to prioritize all the time. As they write in the rationale: "The team has limited resources, reduced maintenance cost frees development time for other improvements". And the cgi module is apparently even unmaintained.
I guess a "batteries included" philosophy sooner or later is caught up by reality.
What do you mean by "character assassination" carried out against Tim Peters? Not anything in the linked article I presume?
Alright. Another case when "code of conducts" trumps manners or actually being a grownup. It really is a shame. Happened to a friend of mine on a rather big technical mailing list just for arguing for something that some people disagreed to. It would be nice to get back to a system based on manners and respect. That system worked for years.
Maintenance costs... that only exists because other parts of Python do not keep a stable and backwards compatible API? Same problem as everywhere else, but particularly silly when there are different parts of the same organization that is ruining it for each other internally. Not that I think it is ever defensible. A small cost-saving in one place that is causing more extra work in many other places.
They have limited resources because the inner circle chased away most active people in order to secure their own corporate positions (which hilariously failed since companies caught on and fired some of them anyway).
So the remaining people periodically launch some deprecation PEPs or other bureaucratic things in order to give the appearance of active development.
Python is for everyone, not just the PSF Cabal. Like the Democratic party, there is a huge need for new leadership. We have all seen what a little brigading can do.
> Everyone developing in Python for a long time has felt it a bit too often when breaking changes (even between minor version updates) once again ruins the day
No, not everyone. I've been using Python as my primary language since 2000 (that's 1.5.2 days). It has been the least troublesome language that I work with, and I work with (or have worked with) a bunch (shell, perl, python, ruby, lua, tcl, c, objective-c, swift, java, javascript, groovy, go and probably others I'm forgetting).
Even all the complaints about the Python packaging ecosystem over the years... I just don't get it. Like, have you ever tried working with CPAN or Maven or Gradle or even, FFS, Ruby Gems/bundler? The Python virtual environment concept is easy to understand and pip mostly does its job just fine, and these days, uv makes all that even faster and easier.
Anywho, just dropping a contrarian comment here because maybe I'm part of the generally silent majority that is just able to use Python day in and day out to get their job done.
> There are only two kinds of languages: the ones people complain about and the ones nobody uses. --Bjarne Stroustrup
I've used CPAN, Maven, gem, and bundler, so I'm also always a little puzzled when people complain about Python's packaging system. However, I've also used npm, so I can kind of understand it.
Python was great in 02000, but some of the things that made it great then are gone now. Stability was one of those; simplicity another; reasonable performance a third; but the biggest issue is really social rather than technical. And I feel like we have alternatives now that we didn't have then.
A long time ago I was working in a big project where the PLs came up with the most horrible metric I've ever seen. They made a big handwritten list, visible for the whole team, where they marked for each individual developer how many bugs they had fixed and how many bugs they had caused.
I couldn't believe my eyes. I was working in my own project beside this team with the list, so thankfully I was left out of the whole disaster.
A guy I knew wasn't that lucky. I saw how he suffered from this harmful list. Then I told him a story about the Danish film director Lars von Trier I recently had heard. von Trier was going to be chosen to appear in a "canon" list of important Danish artists that the goverment was responsible for. He then made a short film where he took the Danish flag (red with a white cross) and cut out the white lines and stitched it together again, forming a red communist flag. von Trier was immediately made persona non grata and removed from the "canon".
Later that day my friend approached the bugs caused/fixed list, cut out his own line, taped it together and put it on the wall again. I never forget how a PL came in the room later, stood and gazed at the list for a long time before he realized what had happened. "Did you do this?" he asked my friend. "Yes", he answered. "Why?", said the PL. "I don't want to be part of that list", he answered. The next day the list was gone.
The danish flag is a white cross on a red background. If you cut out the white cross, you will be left with four rectangles of red, which can be pushed together and sewn up again, forming a solid red flag
This is true, but only if you try to achieve the exact workflow that Office 365 offers. Maybe it is time to try to be a bit more subversive. Do we really need everything that Office can do? Is Microsoft's abstraction of office work really the holy grail of modern office work or is it causing "empty work"?
This is an important point but often it's existing docs and files that cause the most grief, with subtle issues like differences in font rendering or line spacing.
For example, I wanted to make a simple change to a Word doc in Libre Office that included a side bar/column of text in a fixed size table on multiple pages. In Word the layout looked great.
Unfortunately due to font subtleties, in Libre Office the side texts overflowed the tables and the last sentences were cropped. It took some fiddling to make things fit and look as good as the original, but in the process I had to make the font smaller which lost some clarity. I did play with line spacing but that got fiddly.
In summary, a 5 second edit of an existing document laid out 'just so' perhaps 5 yr ago ended up becoming 20 minutes of hassle.
New docs could be laid out better and differently to make future edits easy, but that ignores the large legacy of existing stuff that many will have.
They were hooked until the end. It was quite late for them, but school vacation so I didn't push them to bed.
I didn't know the story going in.
At least if I was their age, I wouldn't have reacted to the end. I didn't become sensitive to tragedy until I was in my 20s, except that I cried when I read Bridge to Terabithia when I was 10 or 11.
A bit off-topic maybe: I really think the earlier film made by the same production team (Crazy Pictures), "The Unthinkable" [1], is a much better film than "Watch the Skies".
But apparently IMDb does not agree:
"The Unthinkable", IMDb rating 6.0
"Watch the Skies", IMDb rating 6.4
"Rather poor" is putting it mildly. This sent me down a sort rabbit hole. From a Stack Exchange discussion[0] it was a short trip to exceedingly technical discussion about using QAM encoding[1] to really beef-up the storage capability.
With the wacky QAM encoding tt looks like maybe 20MB per C90 cassette (and 90 minutes to "read" it back).
It's interesting. I wouldn't dare to go beyond a 1500 baud signaling rate, but, then, audio tape is amenable to QAM, and that could multiply the transmission to 16 bits per token or more depending on the quality of the tape and recorder.
I would be careful with that, however. If you are archiving your data, it's because you like it and, if you like your data, you want it to be readable a long time from now. I'd suggest vinyl records rather than tapes, as they are very robust, and can be read without physical contact.
I have a hundred or so such tapes that contain Commodore PET programs from the early 1980s. Last time I tried to read them (about 10 years ago, when they were about 35 years old), I had...mixed results.
Part of that may be the tape drive (about 40 years old) but the reality is that consumer level cassette tapes aren't built to last: magnetic fields weaken, coating flakes off, tape stretches, and other factors prevent these from being storage solutions beyond 10-20 years (my guess), if that.
They might be a fun nostalgic diversion for listening to old music, where the audio degradation is part of the experience, but for data, they're a non-starter in my book.
Somewhat related, I think there were some projects to use VHS video cassettes for data storage too. It was much better than C cassettes, but still a very far cry from what one would consider worthwhile these days. IIRC a couple of GB per cassette?
LTO tape tech has gotten into pretty nutty territory - in order to achieve its density and speed. It wasn't "easy". So, so far away from C90 technology.
George/Eric paid a lot of attention to how many eggs his hens laid. It almost became somewhat of a joke in the comments. But good content!
https://orwelldiaries.wordpress.com/2008/12/01/11238/
Lots of great quotes (quite a few hen related):
> This morning a disaster. One hen dead, another evidently dying.
I am pretty sure he wrote more about hens and other birds than the ongoing world war.