Thinking about upgrading to Debian Bullseye? Watch out for changes in Exim and anything using Python 2.x The Debian Project has set a release date of 14 August for Debian 11, also known as Bullseye. Debian is an important distribution in its own right, but also influential since it is the basis for many others including Ubuntu, Mint, Devuan, Knoppix, Tails, Raspbian, Pop!_OS, SteamOS and more. In a post to the developer …
I've been using Buster for about a year (I usually switch half way through a cycle, when the Testing distribution is getting to be reliable) and it's as solid as usual.
But my personal GIMP plugins bit the dust over the loss of Python 2.7, I'd only ported them from Perl a few years ago. My Scheme (the built-in scripting language) versions are proving a bit buggy.
Oh Dear Me, or words to that effect.
"But my personal GIMP plugins bit the dust over the loss of Python 2.7, I'd only ported them from Perl a few years ago."
Thank you for your works but are you absolutely barking? 8) You ported your stuff from Perl to Python 2.7 when the kool kids had already told us that Python 2.x is going south, quite a few years ago.
"Scheme is a minimalist dialect of the Lisp family of programming languages."
Good luck with that or as you say: "Oh Dear me" 8)
You are in my thoughts.
Bit late for me to respond, I doubt that you'll see it.
GIMP Python is restricted to Python 2.7 by GTK. The GIMP team are working on updating to GTK 3 now.
Scheme is the scripting language built into GIMP, as I said. Once I solve the issues it has the least risk of being left behind in the way those earlier versions have.
One day our descendants will look back ...
As I understand it, the logic was. Python needs good Unicode support. In order to do Unicode properly, we will need to break backward compatibility. And if we are going to break backward compatibility anyway, let's fix ALL the stuff we wish we'd done differently in one fell swoop. Then, hopefully, Python will never, ever, have to break backward compatibility again.
True? I have no idea. But it's not really crazy. (Probably.)
"[we] will never, ever, have to break backward compatibility again"
Oh, famous last words! ;-)
See also: Perl 6, and probably a whole heap of other tech…
Certainly there are far too many web frameworks that seem to delight in making radical incompatible changes on a far too regular basis. It seems to be a miracle that any website these days manages to last more than a couple of years without needing a complete ground-up rebuild (Do I need that hyphen? Possibly yes, solid bricks which have been ground-up into dust seems a reasonable analogy), or possibly even worse, is still creaking away on things which last received maintenance updates 5 years ago, and are a security nightmare waiting to happen…
@vtcodger - Yes, the main motivation behind Python 3 was getting good Unicode support, and it wasn't possible to do that without breaking backwards compatibility.
Like most languages, Python 2 didn't differentiate between strings of text and strings of arbitrary bytes. That was fine so long as you were only using ASCII. If you were using UNICODE however, then also like other languages you were in for a lot of headache in terms of figuring out Unicode handling as part of your application code.
There was also the issue of functions sometimes returning strings of bytes and other times returning strings of encoded text, depending on the phase of the moon (or at least that's what it seemed like). I even had problems with source code which was written in a different local than mine (the fix was to specify the local encoding in a declaration at the top of the source code file).
This is a problem in Python, because while Python may be dynamically typed, it is also a strongly typed language. Strings however was one area where data types were a bit fuzzy in Python 1 and 2.
Python 3 fixed that by splitting the string data type into "strings", which are purely text, and "bytes" which are simply streams of arbitrary bytes (much like C strings are). If you are doing text handling, then you use strings. If you want to work with arbitrary arrays of bytes, then you use the "bytes" type (or "bytearray"). "Bytes" are directly equivalent to C arrays of unsigned char, and if you are writing a C extension that's the data type you work with them as.
There were other less important changes that I won't bother to go into. The main issue though was the stricter type checking inherent in the new Unicode support which surfaced lots of latent Unicode application bugs in applications which then had to be fixed.
There are lists of what changed between Python 2 and 3, but nearly all of them could be handled by one of the popular bridging libraries. I had a number of applications which ran as is unchanged except for changing the shebang string at the top (e.g. #!/usr/bin whatever, used on unix-type operating systems).
FAT support has been in the kernel for years, and since FAT32 can support up to 2Tb volumes, exFAT isn't needed for generally available SD cards yet.
However, I did buy a 2TB USB drive, and plugged it in to format as ext4, but found that my system had automounted it as exFAT using FUSE. I was surprised, because it was my own homebrew automount script (in Perl!) and I hadn't even considered FUSE when writing it. I think mount with no options was smart enough to do the right thing.
"FAT support has been in the kernel for years, and since FAT32 can support up to 2Tb volumes, exFAT isn't needed for generally available SD cards yet."
If your SD card is SDXC (which it generally is for 64GB+), then it will be exFAT-formatted; it's in the spec. Samsung is well aware of this since its Galaxy S4, one of the first to accept MicroSDXC, was one reason it had to come up with an Android exFAT driver.
Following from this, many USB thumb drives of 64GB or greater will also be exFAT-formatted, as while FAT32 support is available for drives over 100GB, this support is unofficial and cannot be done with default Windows tools. This is why I intentionally limit myself to 32GB USB sticks and SDHC cards when using certain devices that I can't be sure support exFAT or NTFS.
FAT32 has a limit on the file size, which is a problem if you store things like OS install images, large video files, backups compressed into large archives, or anything else where you might need something big. I welcome exFAT support because that has already been the most efficient way of using physical storage to transfer large files between other systems (Windows and Mac OS have supported it natively for a long time). Of course it was possible to do so already through extra layers, but native support will just make things faster and easier.
I've updated a few non-critical systems from "Buster" 10 to "Bullseye" 11 and installed a few new systems directly as 11 and it's mostly a very dull (in a good sense) process and everything seems to be the same but with incremental improvements across the board. Annoyingly after no changes for several weeks the last minute fixes have been trickling ever day, but it still feels very good and solid.
Buster was very good and worked fine, so far I've not had any issues with migrating to Bullseye, but I've not touched any of my systems with fiddled exim config yet... All the desktops and laptops are vanilla when it comes to exim, so nothing happened, the actual mail server will need to be dealt with carefully. All the other config changes were minor or I rolled back to standard.
Steam OS 3.0 is now Arch based, why would you install something so infrequently maintained like Steam OS 1.0 or 2.0, not that 3.0 will get any additional love.
PS I tried Steam OS 1.0, for a while, as a dual boot on my Arch box and was alarmed at how infrequently even the most basic security updates arrived.
(plus all of the supporting packages)
I haven't used a "desktop" in years, although I try KDE every once in a while and it's not much worse than Windows 10, tbh,
I'm trying to drink the flavoraid at work and tied my Google accounts into Windows, but it's not working very well.
I will migrate to something other than awesome when X11 stops working. Maybe the Devuan guys will have gotten over themselves and worked on something important by then :)
The Debian distro names are all taken from characters in Toy Story, the animated film.
https://pixar.fandom.com/wiki/Bullseye
Sooner or later they are going to run out of characters...
PS: I've got cache problems or some people round here can type really fast! I've been beaten to it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
