back to article 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 …

  1. Natalie Gritpants Jr

    trac is removed but coming back soon

    You may want to wait for 11.1 if you use trac, or upgrade from Buster.

  2. Greybearded old scrote Silver badge

    Sigh

    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.

    1. Anonymous Coward
      Anonymous Coward

      Re: Sigh

      "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.

      1. teknopaul

        Re: Sigh

        fear not my friend, python 2.7 to 3.0 is pretty much automated.

        Naturally ymmv but chin up, it is nothing like a perl to python lift.

      2. Greybearded old scrote Silver badge
        FAIL

        Re: Sigh

        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.

  3. Will Godfrey Silver badge
    Unhappy

    I'll hold on for as long as poss.

    Some of my desktop stuff requires Python 2.7 and is pretty much unmaintained but incredibly 'comfortable'. No doubt I'll have to change at some point but it will feel like disposing of a favourite coat.

    1. Anonymous Coward
      Anonymous Coward

      Re: I'll hold on for as long as poss.

      One day our descendants will look back at the Python 2 / 3 schism, and wonder what those ancients had been smoking when they thought of that one...

      1. vtcodger Silver badge

        Re: I'll hold on for as long as poss.

        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.)

        1. Dave559

          Re: I'll hold on for as long as poss.

          "[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…

          1. teknopaul

            Re: I'll hold on for as long as poss.

            I gave up on v8 when another Google api change got rid of the String class, grrr.

            I mean come on guys, some people are likely to be using String.

            Seems Google thought people were mostly just writing calculator apps.

        2. thames

          Re: I'll hold on for as long as poss.

          @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).

    2. vtcodger Silver badge

      Re: I'll hold on for as long as poss.

      Sadly, the industry motto is becoming, If it ain't broke, break it. Seems like kind of a dimwitted strategy to me. But who cares what I think?

      1. Pirate Dave Silver badge
        Pirate

        Re: I'll hold on for as long as poss.

        Break early, break often.

  4. Anonymous Coward
    Anonymous Coward

    "the value of exFAT support is mainly"

    To access external storage which rarely comes formatted in ext4, especially CF and SD cards.

    1. Steve Graham

      Re: "the value of exFAT support is mainly"

      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.

      1. Charles 9

        Re: "the value of exFAT support is mainly"

        "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.

      2. Robert Carnegie Silver badge

        Re: "the value of exFAT support is mainly"

        Of course FAT32 has a maximum file size of 4 GB, but that's an awful lot of typing for your unpublished novel to be that big.

      3. doublelayer Silver badge

        Re: "the value of exFAT support is mainly"

        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.

    2. DuncanLarge

      Re: "the value of exFAT support is mainly"

      Thats why we reformat

  5. Adair Silver badge

    Like it or not, I have fond memories of Lilo, as I learned the Linux landscape.

    1. Disgusted Of Tunbridge Wells Silver badge

      Same. I thought lilo had gone the way of the dodo years ago though.

  6. Adam Trickett
    Linux

    So far so good.

    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.

  7. TVU

    Watch out for changes in Exim...

    It would also be nice if we could look out for a change in init systems away from the all-encompassing cacodyl that is Poettering's creation.

  8. Anonymous Coward
    Anonymous Coward

    Really?

    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.

  9. Sloppy Crapmonster

    tmux firefox-esr ssh rsync rxvt awesome

    (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 :)

    1. achillesneil

      Re: tmux firefox-esr ssh rsync rxvt awesome

      Well things like tmux and ssh are originally OpenBSD applications. You could just use OpenBSD instead. To be honest, I use OpenBSD and Debian, and to be honest, I have very few issues. Unlike that toy operating system known as Windows 10.

  10. Howard Sway Silver badge

    Debian 11, also known as Bullseye

    Presumably named after the Marvel comics villain, rather than the British darts based tv gameshow where you could win a speedboat and a "canteen of cutlery".

    1. achillesneil

      Re: Debian 11, also known as Bullseye

      Or a darts tournament when all the competitors were pissed out of their gourd. 1980's. Golden age of crap TV.

    2. pakraticus

      Re: Debian 11, also known as Bullseye

      Bullseye, Woody's horse from Toy Story.

      The Debian code names are from Toy Story.

      The outdated pictures... https://people.debian.org/~miriam/toy_story/

      https://unix.stackexchange.com/questions/222394/linux-debian-codenames

    3. keithpeter Silver badge
      Windows

      Re: Debian 11, also known as Bullseye

      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.

      1. achillesneil

        Re: Debian 11, also known as Bullseye

        I wouldn't mind if the next Debian distro was called Pot Noodle. Or Velvet Pantaloons. As long as it works,

      2. Robert Carnegie Silver badge

        Re: Debian 11, also known as Bullseye

        Nemo?

        Dory?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like