Steve Langasek mula sa Canonical
Pangunahing kasama sa listahan ang mga aklatan na ginagamit sa mga 32-bit na application na ginagamit pa rin, pati na rin ang mga dependency na nauugnay sa mga aklatang ito. Bilang karagdagan, para sa mga aklatan mula sa listahan, pinlano na panatilihin ang mga dependency na ginagamit para sa mga pagsubok, ngunit gamitin ang mga ito para sa cross-testing i386 library assemblies sa 64-bit x86_64 system environment, kaya ginagaya ang kapaligiran na gagamitin sa totoong buhay. kundisyon.
Kung ikukumpara sa hanay ng mga 32-bit na aklatan na kasama ng Ubuntu 19.10, kasama rin sa Ubuntu 20.04 ang
- freeglut3
- gstreamer1.0-plugins-base
- libd3dadapter9-mesa
- libgpm2
- libosmesa6
- libtbb2
- libv4l-0
- libva-glx2
- va-driver-lahat
- vdpau-driver-lahat
Ngunit sa parehong oras, ang mga hindi napapanahong mga pakete ay ibubukod mula sa set, na sa Ubuntu 20.04 ay hindi na itatayo para sa mga kasalukuyang arkitektura (ang mga pakete na partikular sa bersyon, tulad ng libperl5.28 at libssl1.0.0, ay papalitan ng mga mas bago) :
- gcc-8-base
- libhogweed4
- libnettle6
- libperl5.28
- libsensors4
- libssl1.0.0
- libhogweed4
- libigdgmm5
- libllvm8
- libmysqlclient20
- libnettle6
- libtxc-dxtn-s2tc0
- libvpx5
- libx265-165
- wine-devel-i386
- wine-stable-i386
Alalahanin natin na noong una ay Canonical
Ang dahilan ng paghinto ng suporta para sa arkitektura ng i386 ay ang kawalan ng kakayahan na mapanatili ang mga pakete sa antas ng iba pang mga arkitektura na suportado sa Ubuntu, halimbawa, dahil sa hindi pagkakaroon ng mga pinakabagong pag-unlad sa larangan ng pagpapabuti ng seguridad at proteksyon laban sa mga pangunahing kahinaan tulad ng Spectre para sa 32-bit system. Ang pagpapanatili ng package base para sa i386 ay nangangailangan ng malaking development at quality control resources, na hindi nabibigyang katwiran dahil sa maliit na user base (ang bilang ng mga i386 system ay tinatantya sa 1% ng kabuuang bilang ng mga naka-install na system).
Pinagmulan: opennet.ru