Since 32 bit software is slowly being faded out and multilib

>>61122799
Are you retarded?

>>61122799
>32 bit only programs?
wtf did pajeet mean by this?

>>61122829
Seems like it.

>>61122829
Arch linux already dropped 32 bit, try compiling a 32 bit application with default install and watch the errors fly back because the libraries it wanted weren't found. Debian and ubuntu are considering dropping it also soon.

>>61122799
They will be ported to 64-bit. If they are proper free software, the source code will be available for anyone to port.

Multilib is running a 32bit libraries on a 64bit OS so you can run 32bit applications. So basically you answered your own question. The solution to old 32bit applications is multilib. If you don't run old 32bit applications you can just leave multilib out. Most *nix systems do not ship with multilib by default because the 32bit libraries are redundant and a pose a slight security risk.

>>61122973
This basically. Also multilib isn't dying out yet. And if multilib vanishes, >>61122914 will happen.

>>61122860
>hurrdurr he doesn't use the exact correct terminology so my autism can't fucking deal with it
meme-spouting shitter.

>>61122891
Debian will probably be the last mainstream distro to support 32bit and I expect them to be among the last distros in general to support it. They're community developed and support like a dozen obscure platforms aside from x86 compatibles, they even support SuperH which was only used in the sega saturn/dreamcast and a few set top boxes. They're not going to drop 32bit anytime soon but they might stop supporting the 32bit kernel officially at some point. The 32bit libraries can run on a 64bit kernel just as well so while support for very old hardware will be dropped officially 32bit software can continue to run on modern 64bit hardware with no problem. 32bit kernel might even stick around in a unofficially supported form like Debian GNU/kFreeBSD.

>>61123126
>meme-spouting shitter.
It was just a prank bro. Calm down

>>61122799
32bit support will remain for a long long time.
A lot of current software still is 32, almost all legacy software running is 32bit. Some legacy software is even 16bit, I have one customer running legacy database on w10 32bit to support 16bit app.

Running 32bit is not the end of the world support is done thru internal emulation on os and the hit is pretty low if not none.

x86 is backwards compatible.

Static linking is the future

>>61123561
>Static linking is the future
If only that were true

>>61122799
You are aware that Linux is used in much more than x86 right? There is no need to drop it for the foreseeable future. Probably x86 32bit compatibility will not come installed by default soon, but then it will be a matter of installing it when needed.

I remember the fuzz when dropping 386 and Linus suggested to also drop the old FPU emulation, which seemingly would have dropped some 486 as well, but it turned out they still worked.

Recently GCC dropped compatibility below 686, which led most distributions to drop support for the older CPUs since they would be unable to with the new compiler versions, but still there are specific purpose distributions that support them.

>>61123898
http://sta.li/

>>61124016
>404 not found

That only proves my point.

File: 1498401240115.gif (104KB, 250x201px) Image search: [Google]

104KB, 250x201px

>>61122799
Multilib will just be kept around as a secondary legacy option. It's that easy. Use it if you need it, don't worry about it if you don't.

>>61122891
It's honestly not an issue anyways since all of my machines I use daily are 5-10 years old and all but one are 64-bit, and that's from 2006. So treating 64-bit software as a priority makes a lot of sense. Some people will just have to spend $45 on used 64-bit hardware I guess.

>there's a problem with keeping ~100mb of libraries necessary to run certain software on a 10GB OS installation

autism

>>61124202
From a security standpoint, removing them will narrow the attack surface. For those that do not need them there is no reason not to remove them.

Not having them by default might also give a little push to those who can migrate to 64bit to do so without actually forcing them to.

>>61122799
just use chroot

>>61124088
Worked for me, try again

>>61123376
>obscure platforms aside from x86 compatibles, they even support SuperH which was only used in the sega saturn/dreamcast and a few set top boxes
?
SH found its way into cars and medical devices and other various parts of the embedded space. I guess you're from the USA?

And SH2 has been cloned and made available under a free license (check out "j-core"), with SH4 coming some day. that alone makes it a relevant arch in my opinion.

>>61122799
That will probably have to be the day I buy a new computer...

You install the original 32bit OS for your 32bit programs. A problem wasn't.

>>61122799
Hopefully, no one will ever use them.

Only jews trying to make even money want to see this phased out.

>>61122799
>32 bit being faded out
Only on Mac.
Microsoft still suggests using 32bit when possible, and Windows ARM can emulate only x86 32bit, not 64bit.
Linux doesn't care since everything is open source anyway.

>>61122799
>32 bit software is slowly being faded out

Except it's not. Some dumb cunt might be trying to dictate that that should happen, perhaps you OP, but it's not actually happening in reality at all

>>61122799
This is one of the times where
>install gentoo
is actually the correct answer.

>>61122799
All x86-64 cpus support 32 bit software in their hardware. If these cpu aren't going anywhere, then 32 bit isn't going anywhere.

>>61122799
>slowly
bitch it already has

>>61129896
Is Apple really dropping x86 32bit compatibility from MacOS?

Not that it would matter much in their case since they have pulled two more complex migrations already, from Motorola 68K to IBM Power to Intel x86. Actually, it would not even surprise me if they were to migrate again to an in house variant of ARM.

>>61124202
On *nix systems stuff can usually just be compiled and run native, on x86-64 compiling native can even bring significant performance improvements because of newer instruction set extensions and more general purpose registers. Multilib also creates more vulnerabilities in the system so from a security standpoint it's just not a good idea on servers or workstations.

>>61129983
>This is one of the times where
>>install gentoo
>is actually the correct answer.
Then there's something very wrong with the question.

>>61130945
Besides, servers and workstations are where more addressing space is needed.

>>61122799
Install Gentoo