Ubuntu 20.04 LTS Continuing To Work On Python 2 Removal

[Jaxad0127]

Working fine with Python 3 on my Arch Linux install, so I'm sorry, but *your* post is incorrect.

Don't know which package you're talking about because all packages I found (including AUR git) require python2-gobject.

[starshipeleven]

Working fine with Python 3 on my Arch Linux install, so I'm sorry, but *your* post is incorrect.

Kiddo, that's the upstream and if the developer himself says it's not finished, it's not finished and you are wrong.

If you see in the github issue, the unicode / str-split point is still to finish and the developer said that he is going to do a push for full Python3 support by January 1 https://github.com/bleachbit/bleachb...ment-552740276

I tentatively suggest to not use an application that goes and deletes stuff from your system until the developer says it fully compatible with Python3.

[Vistaus]

I'm sorry, but that's not correct. It has been ported to Gtk 3 a few weeks ago, that much is true, but it still lacks python 3 support. Thankfully, it is planned for "pretty soon": https://github.com/bleachbit/bleachbit/issues/163

Working fine with Python 3 on my Arch Linux install, so I'm sorry, but *your* post is incorrect.

[starshipeleven]

I'm sure you're the maximus prefect of layered networking, but this is simply not true. All the big names (google, aws, azure, netflix) are IPv6 ready, so are the majority of ISPs at least in Europe. My own ISP does not assign v4 addresses anymore to connected clients.

His point is that no actual services are being offered on it, or that require IPv6 to be accessed.

Are we still waiting for Apple to be the "innovator" or will this happen naturally before 2030?

[starshipeleven]

I could write at length about a subject I know very, very well.

I would very much like to read that.

The prevailing attitude was "the Internet is about to die from routing overload without IPv6, so we can stick whatever complexity we want inside it, and they will have no choice but to accept it."

Ok, we can agree IPv6 is overcomplicated bs.

If the IETF had simply made IPV6 "ipv4 with longer addresses",

Not retrocompatible without some form of NAT either, which was my main point.

You can't make it retrocompatible, you can surely make it not overcomplicated bs and that would help adoption tremendously, but that's not what you said.

No one (and with no one I mean a statistically significant number) is using IPv6 for anything serious, and will not be for a long time

Yeah I know. We are at a point in time where there are ASIC accelerator coprocessors dedicated to NATting in most serious routing equipment, and IPv6 is for most intents and purposes, dead.

And I'm still here doing %&£/& VPNs to access my stuff from outside my local LAN because my ISP is a %&£%£ and won't let me have a static IP even if I paid for it.

[royce]

No one (and with no one I mean a statistically significant number)

I'm sure you're the maximus prefect of layered networking, but this is simply not true. All the big names (google, aws, azure, netflix) are IPv6 ready, so are the majority of ISPs at least in Europe. My own ISP does not assign v4 addresses anymore to connected clients.

[JPFSanders]

How do you make a system that can give unique addresses to orders of magnitude more devices than the older one retrocompatible without active address translation system (i.e. basically a NAT) or other similar shenanigans somewhere in the stack anyway. Do you even know how networking works?

IPv4 retrocompatibility is NAT on a router that has also a IPv6 DHCP server for IPv6 devices.

I could write at length about a subject I know very, very well. Instead I will tell you how it is:

What we should take away from the IPv6 debacle is a fine lesson in hubris.

"I was hanging out in the IPv6 mailing lists at the time the various solutions were being debated.

The prevailing attitude was "the Internet is about to die from routing overload without IPv6, so we can stick whatever complexity we want inside it, and they will have no choice but to accept it."

Except that new router hardware and new incremental software improvements came out, and the enormous complexity of the "boil the ocean" redesign inherent in IPv6 was rightly regarded as completely unnecessary.

If the IETF had simply made IPV6 "ipv4 with longer addresses", (and there was a proposal to do just that), implementations and deployment would have been dramatically simpler and would have stood a real chance of succeeding.

Instead we have this baroque construction, which I _still_ have to explicitly disable in my work environment because various bits of supposedly IPV6 software don't play nice together. "

No one (and with no one I mean a statistically significant number) is using IPv6 for anything serious, and will not be for a long time, no one is going to be the first to run a popular service on IPv6 only, nobody who intends to do anything where money is involved that is, and money is pretty much required for anything other than w*nking, and even that cost money if you do not want to end with a sore D**k.

[skeevy420]

https://www.youtube.com/watch?v=k01jJNgQcf0

pacaur -Syua --devel

also works equally well

Also, adding --rebuild after --devel is damn handy when QT or libc updates and half your AUR shit quits working...

[royce]

How long do you go without rebuilding git based AUR packages? Over six months isn't good practice to get into.

https://www.youtube.com/watch?v=k01jJNgQcf0

[Isedonde]

BleachBit has already been ported to Python 3 and Gtk 3. So nice try.

I'm sorry, but that's not correct. It has been ported to Gtk 3 a few weeks ago, that much is true, but it still lacks python 3 support. Thankfully, it is planned for "pretty soon": https://github.com/bleachbit/bleachbit/issues/163

As that issue tracker clearly demonstrates, it is not as easy as one might think ("just use py2to3").