"That said, Train does include live migration extensions,"
You mean like we've been using for the last 4-5 years?
Canonical has released Ubuntu 19.10, codenamed Eoan Ermine for some reason. Ubuntu 19.10 is only supported until July 2020. The next LTS (Long Term Support) release will be 20.04 next year. Businesses using Ubuntu in production may prefer to wait for 20.04, for which 19.10 serves as a useful preview. Based on the Linux 5.3 …
True as of now. Found a release notes page, yet links from there also "Not Found - The requested URL was not found on this server."
I guess Ubuntu is published somewhere west of Hawaii?
This is not altogether a bad thing,
Yes, it is.
since it may prompt developers to work at removing 32-bit dependencies.
Lol, yeah good luck with that. 90% of game devs are not going to do a new Linux build for a game they released even 5 years ago. And even if some miracle occurred to make that happen for those games, good luck getting Epic to do a 64bit build of Unreal Tournament 99. And then there's Descent 3, Alpha Centauri, and a whole bunch of other amazing old games.
Equally, users who value compatibility more than the new features in 19.10 should probably stick to 19.04 or alternative distros.
Yep, this will be the straw that finally breaks the camel's back and forces me to another distro.
It saddens me that Ubuntu feels the need to destroy Linux gaming right at the moment when we have the best gaming ecosystem and the most releases we've ever had. And all just because they're too lazy to bother maintaining this stuff. I just hope that gamers and devs can find a new flagship distro for Linux gaming, rather than seeing our ecosystem shrink.
It's not just about gaming.
It's about old applications that no-one is developing further.
People used to go on to other things or die or whatever and the application works well enough and has no equivalent. It's niche or needs special expertise in some field other than programming. So it's NEVER EVER going to have 32 bit dependencies removed or even be a 64 bit version.
I've 20+ year old software that no-one is going to write replacements for. Some works fine on 32 bit WINE on Linux but on no 64 bit version of Windows.
Indeed. My printer only has 32 bit drivers available and already it only works with excessive amounts of farting about to get the dependencies in place. And Dell isn't ever going to do 64 bit versions - as far as they're concerned it's obsolete.
This decision may be the last straw; the death knell for my printer. It's a decision that's going to cause distribution migration or landfill.
Quite apart from games, there are plenty of essential 32 bit open source tools for niche tasks that have never been (and may never be) "upgraded" to 64 bit.
Linux was originally free of enforced churn, but now it's just effectively becoming an alternative flavour of windows. Unless your revenue stream depends on backward incompatibility there's no legitimate reason to enforce it (even supposing that's a legitimate reason). The argument that backward compatibility causes problems for developers just says a lot about the developers.
Windows 95 originally in 1995 didn't have USB at all! USB support came in a later release. There may have been three or four Win95 versions before Win98.
NT4.0 (1996) unlike Win95, Win98 and Win ME was a real OS and only had USB in a preview that might have been in the last service pack that was cancelled to help the Win2000 sales. The Preview USB driver did work with Win2K USB devices, though often you had to install on Win2K and copy because the developers were STILL checking OS version strings instead of what features might be ON the particular revision of the OS. Rumoured to be why NT 9.x was skipped. Though Win7 was really Win 6.something. Win 8.0 should have been Win NT 7.0
Since Apple has been on OS 10 since about 2002, I guess MS will stick with 10. The other extreme is applications like Firefox.
There were two (official) ways to get USB support on windows 95. Probably the easiest was to upgrade to OSR2, which included a bunch of fixes and stuff including USB drivers (and was about where Microsoft OS's peaked IMO, though an good case can be made for XP). But there was also a USB driver kit that you could install separately and get support on the vanilla version of win95. The issue was getting hold of it - these were the days when most people didn't have Internet at home. I remember downloading it at school and zipping it onto a bunch of floppies.
These were also the days when nobody had standardised anything yet, so 95% of USB devices, even mundane ones like thumb drives, came with a driver disk. I seem to recall that the Microsoft USB drivers only drove the USB port itself, they didn't include support for things like USB thumb drives. You'd have to install the USB drivers, then install the drivers that came with your thumb drive, and then you'd be able to use any thumb drive.
I hear you regarding 'df' all those loopback mounts are a mess. However in principle snap does offer the benefit of being able to package once for an architecture and then run on 'any' distro without worrying about dependencies.
I like the principle but I feel the implementation needs improvement.
I like the principle but I feel the implementation needs improvement
I find the ever-growing list of interfaces that give snaps access to system resources to be both confusing and unnecessarily restrictive. For example, I have a DLNA server running as a snap to which the "removable-media" interface is connected so that I can access media files outside the snap container: but only under /media or /mnt, not a path of my choosing. I run TVHeadend as a snap, too, but it doesn't have a "removable-media" option, so on the rare occasions I use it for recording, the file has to be moved out of the snap container for the DLNA server to be able to access it.
Given all the work that has been done on containerisation, I can't help feeling there should be a neater solution to using and sharing resources.