Ubuntu 19.10 To Drop 32-bit x86 Packages

[zyxxel]

I couldn't have spent so many working years, and not have been around to see what we were trying to correct. Here is what I can say, very simply.... The architecture and design of *NIX is not suited for the conditions we deal with today. I do not believe that there is anything special about licensing or code in of itself, at least not any longer. Some projects can deliver high quality and value being open source or free software., or must be open source or free-software to deliver the highest value. Some projects can only ever hope to deliver quality or value as a proprietary product. ... and many others deliver low quality and minimal value either way. What does this mean? It means that to deliver the maximum productivity and empowerment to the user, and society, an OS must be versatile not only in itself... but within our social order.

The complexity of software is so much greater than it was when Unix was designed, and so is the complexity of our economic, social and cultural relations. If you want to change the world, empower the users of your software, don't use software to change the world the way you personally would most prefer. The criteria to judge is the voices of the users, and developers. Do they feel oppressed or chained? Do they feel stuck in a box, that they cannot escape from? Do they feel helplessly chained to a power structure, that they can't ever build something different without an army of maintainers?

Windows does chain us to MS, and that isn't great... but ironically, it frees us from more than the alternatives, and that isn't saying much at all. Linux freed multi-national corporations from having to pay huge amounts of money to UNIX venders, it did some other positive stuff to, in development culture and collaborative advances. Having open code is not a goal in of itself, exuding its benefit as instructional material and examples, and is not sufficient to result in a more free world.

At this point, we are all the mercy of Google, in more ways than one. Not regarding the mobile platform, in which they are more oppressive than MS ever was, but in having any hope for the next OS that frees developers from being chained to each other in one distributed central code base. Software development is not scalable enough, to be the main point in which we collaborate with each other, it is slow... extremely error prone, and innovation must come out of consensus. Git did great things, and when you can all operate under the same process, it can include tons of people from all over. What it can't do, is be our "social" API for building something as a society or civilization, that has to operate in a world with countless different processes, economic relations, and industries. It is not a sufficient replacement for thoughtful OS design, which frees hardware developers, volunteers, hobbyists, and students, from each other and a centralized bureaucracy. It's gone as far as we could go, and now it's time to move onward.

But the open source projects aren't created by people who hates the users. And users have never been more empowered than now.

Huge number of things I do at home, I would never have been able to do 20 years ago because I would either have had to pay large amounts of license fees or have to invest huge numbers of years of own time to implement the functionality. That not all tools are easy to use doesn't mean we aren't able to do way more now than before.

The world needs both open source projects and commercial projects. But for a very large number of tasks, the users are now free to select multiple - free - alternatives that will solve the problem good enough. And that is empowerment.

[techzilla]

This make me wonder - were you born and old enough to be using a computer before we got open source?

I couldn't have spent so many working years, and not have been around to see what we were trying to correct. Here is what I can say, very simply.... The architecture and design of *NIX is not suited for the conditions we deal with today. I do not believe that there is anything special about licensing or code in of itself, at least not any longer. Some projects can deliver high quality and value being open source or free software., or must be open source or free-software to deliver the highest value. Some projects can only ever hope to deliver quality or value as a proprietary product. ... and many others deliver low quality and minimal value either way. What does this mean? It means that to deliver the maximum productivity and empowerment to the user, and society, an OS must be versatile not only in itself... but within our social order.

The complexity of software is so much greater than it was when Unix was designed, and so is the complexity of our economic, social and cultural relations. If you want to change the world, empower the users of your software, don't use software to change the world the way you personally would most prefer. The criteria to judge is the voices of the users, and developers. Do they feel oppressed or chained? Do they feel stuck in a box, that they cannot escape from? Do they feel helplessly chained to a power structure, that they can't ever build something different without an army of maintainers?

Windows does chain us to MS, and that isn't great... but ironically, it frees us from more than the alternatives, and that isn't saying much at all. Linux freed multi-national corporations from having to pay huge amounts of money to UNIX venders, it did some other positive stuff to, in development culture and collaborative advances. Having open code is not a goal in of itself, exuding its benefit as instructional material and examples, and is not sufficient to result in a more free world.

At this point, we are all the mercy of Google, in more ways than one. Not regarding the mobile platform, in which they are more oppressive than MS ever was, but in having any hope for the next OS that frees developers from being chained to each other in one distributed central code base. Software development is not scalable enough, to be the main point in which we collaborate with each other, it is slow... extremely error prone, and innovation must come out of consensus. Git did great things, and when you can all operate under the same process, it can include tons of people from all over. What it can't do, is be our "social" API for building something as a society or civilization, that has to operate in a world with countless different processes, economic relations, and industries. It is not a sufficient replacement for thoughtful OS design, which frees hardware developers, volunteers, hobbyists, and students, from each other and a centralized bureaucracy. It's gone as far as we could go, and now it's time to move onward.

[Volta]

This is hilarious, and the smug responces are even better!

1. Seriously stop using Ubuntu like yesterday, they are a bunch of woke elitists who have contributed nearly nothing intentionally.

2. This is the real open source community, a bunch of toxic self-hating totalitarians, I regret spending so many working years in this cesspool.

I don't much care for the world open source built, where users are more dis-empowered than ever, and their software is written by people who hate them.

Go back to your cave m$ moron, but beware of winblows BSODs and viruses waiting for you. A true security hell. This is birdie's avatar for sure!

[zyxxel]

I don't much care for the world open source built, where users are more dis-empowered than ever, and their software is written by people who hate them.

This make me wonder - were you born and old enough to be using a computer before we got open source?

[techzilla]

This is hilarious, and the smug responces are even better!

1. Seriously stop using Ubuntu like yesterday, they are a bunch of woke elitists who have contributed nearly nothing intentionally.

2. This is the real open source community, a bunch of toxic self-hating totalitarians, I regret spending so many working years in this cesspool.

I don't much care for the world open source built, where users are more dis-empowered than ever, and their software is written by people who hate them.

[starshipeleven]

Y'all are still going at it?

At least me and starshipeleven shut up about it after a day.

Arguing is fine, but, damn, y'all's gettin' a bit ridiculous at this point.

[skeevy420]

Y'all are still going at it?

At least me and starshipeleven shut up about it after a day.

Arguing is fine, but, damn, y'all's gettin' a bit ridiculous at this point.

[L_A_G]

You can always improve the performance by using new CPU features/instructions, or have better quality encodings (not talking just about decoding). Everything you listed "bugs discovered, optimizations and general improvements to be made" apply to the library as a whole, which applies to it anyway because you build it for 64-bit.

As I said, this long in there's just not going to be anything of important left to do with a quarter century old specification. Even if you start putting in improvements for new CPU features, building for i386 will necessitate a whole bunch of extra work with alternative code paths and ensuring that those code paths are always followed correctly.

ENCODER broski. And even for decoder you can do performance/energy improvements using new CPU features or simply better algorithms.

It doesn't really matter if we're talking about encoders or decoders. Both implement the same specification that's been unchanged for a quarter century and even if you just try to add support for new instructions additional builds for ISAs like i386 which lack those instructions will still cause additional headaches.

So what's worse: unable to run the software at all due to idiotic decision, or having it "break" because untested?

As I said, you're still going to be able to run your obsolete software using methods like containerization or VMs. If you can't containerize it or get a VM going then you issue is one of PEBKAC and not something Canonical is guilty of.

I go with the former. At least there's a (high) chance that it will work with the latter.

Software relying on i386 builds of libs and utilities still works because of a significant effort to do so. Once this effort ceases said software needs to be removed as bug will obviously be uncaught and end up lingering, which is obviously not acceptable in software that's sold commercially.

Generic buzzwords, here have a cookie, superb argument, could say the same thing to you.

If basic QA and "production" software are just buzzwords for you it's fairly obvious you've never done software development professionally. As such you really shouldn't go around acting like you know anything about producing commercial software used for use by professionals.

I don't want a container, because these apps could also benefit from improvements to the libraries (like Wine does). I also want full desktop integration, not a single hurdle, meaning when I open a file, I don't want a single trace of the "container" or "portal" or whatever bullshit. Period.

The fact that the i386 binaries won't be provided by the OS doesn't mean that builds of newer versions aren't going to become available elsewhere. With Wine the developers have said that they'll be providing their own i386 binaries and those will obviously be updated as never versions are released. It'll probably even help them with making a better experience as they can then count on everyone having the exact same version of the libraries rather than the absolute cacophony of versions provided by different distros.

I mean, it does run that way today... why would I want a degraded user experience?

Maybe you're not the only person in the world? Maybe those resources are actually better spent on other things? Maybe you're just entitled?

[Weasel]

We're not talking about abandonware libraries here, we're talking about libraries that are obviously in both active development and active use by software that's also in active development. Meaning that there's going to be bugs discovered, optimizations and general improvements to be made. MP3 decoding on the other hand is such old hat and performing a completely standardized task that there's really no reason to re-implement it or even touch existing implementations as those have reached a point where there's really no point in trying to improve them anymore.

You can always improve the performance by using new CPU features/instructions, or have better quality encodings (not talking just about decoding). Everything you listed "bugs discovered, optimizations and general improvements to be made" apply to the library as a whole, which applies to it anyway because you build it for 64-bit.

Missing the point again? When you have a spec set in stone there is zero reason to change a working and well made implementation. The fact that there are many different implementations neither escapes me nor counters my argument in any way as any decently put together implementation will have gotten to the point of no longer needing to be touched.

When you have a spec that's been unchanged for over a quarter of a century you're obviously going to have any eagerness to experiment out of your system and arrived at a good working implementation that just doesn't need to be touched anymore. Hence any halfway decent MP3 decoder will have long since arrived at the point where there's just not going to be any maintenance cost to it.

ENCODER broski. And even for decoder you can do performance/energy improvements using new CPU features or simply better algorithms.

If you think a build is never going to break or that the attitude of "If it builds, it's fine" is an acceptable outside of personal hobby projects and academic settings then you've obviously never worked on complicated software or software that's meant to be used in production environments. In an environment like that you simply cannot trust that nothing is going to go wrong like you're doing.

So what's worse: unable to run the software at all due to idiotic decision, or having it "break" because untested?

I go with the former. At least there's a (high) chance that it will work with the latter.

Rendering it unusable? Maybe if you're computer illiterate and don't know how to containerize it or run it in a VM. Seeing how you've demonstrated that you've got no idea of how production quality software development actually works I probably shouldn't put it past you to not know how to do either of these things.

Generic buzzwords, here have a cookie, superb argument, could say the same thing to you.

I don't want a container, because these apps could also benefit from improvements to the libraries (like Wine does). I also want full desktop integration, not a single hurdle, meaning when I open a file, I don't want a single trace of the "container" or "portal" or whatever bullshit. Period.

I mean, it does run that way today... why would I want a degraded user experience?

[L_A_G]

If the mp3 library is not changing then why are the other libraries changing? There's nothing to maintain if they don't change.

We're not talking about abandonware libraries here, we're talking about libraries that are obviously in both active development and active use by software that's also in active development. Meaning that there's going to be bugs discovered, optimizations and general improvements to be made. MP3 decoding on the other hand is such old hat and performing a completely standardized task that there's really no reason to re-implement it or even touch existing implementations as those have reached a point where there's really no point in trying to improve them anymore.

A lot. Maybe half. Because it just works. Half of it isn't even open source to begin with (though it's likely free).

Well then you're obviously an outlier and even at that you only need to containerize it or set up an i386 VM once as it's obviously not going to change.

You obviously have no idea what you're talking about and how many different mp3 implementations there are, so I won't bother. And I'm not even talking about superficial differences but for encoders especially. The spec has nothing to do with implementation.

Missing the point again? When you have a spec set in stone there is zero reason to change a working and well made implementation. The fact that there are many different implementations neither escapes me nor counters my argument in any way as any decently put together implementation will have gotten to the point of no longer needing to be touched.

When you have a spec that's been unchanged for over a quarter of a century you're obviously going to have any eagerness to experiment out of your system and arrived at a good working implementation that just doesn't need to be touched anymore. Hence any halfway decent MP3 decoder will have long since arrived at the point where there's just not going to be any maintenance cost to it.

WTF is wrong with you? You think a physical piece doesn't need testing? Maintenance costs? But an automated build of a library has more costs? Are you trolling now?

A physical piece with no moving parts needs to be tested once and if it's as bomb proof as a modern CO2 laser that one test is really all you're ever going to need. By the time that laser will need to be replaced it will be long past the end of the usable life of the player itself due to wear and tear on the moving parts, none of which will be solely used by functionality related to the red CO2 laser.

Yeah very much maintenance especially with automated builds compared to a physical hardware like a laser.

If you think a build is never going to break or that the attitude of "If it builds, it's fine" is an acceptable outside of personal hobby projects and academic settings then you've obviously never worked on complicated software or software that's meant to be used in production environments. In an environment like that you simply cannot trust that nothing is going to go wrong like you're doing.

This is really pointless. No matter how sane analogies are presented, all you bring up is your superficial "maintenance cost". In fact, you can just use that phrase to counter anything at this point, it doesn't even matter how idiotic it is.

The fact that you trust that a build is never going to break and that if it builds, it's fine, just proves you have no idea of what maintenance for production quality software actually entails.

Because totally rendering stuff unable to run is better than have it crash due to lack of QA. Right. 10 IQ Logic.

Rendering it unusable? Maybe if you're computer illiterate and don't know how to containerize it or run it in a VM. Seeing how you've demonstrated that you've got no idea of how production quality software development actually works I probably shouldn't put it past you to not know how to do either of these things.