LINUX.ORG.RU

LibreOffice прекращает поддержку 32bit для Linux

 ,


0

1

Одновременно с анонсом новой бета версии LibreOffice 6.3 Beta1, команда LibreOffice заявила, что больше не будет предоставлять 32-битные бинарные файлы Linux.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Как обычно, под такими новостями вылезают любители старого хлама. Сам недавно выкинул старье уровня p4, даже на авито влом это продавать. Да, на нем можно работать, но ЗАЧЕМ??

voltmod ★★ ()
Ответ на: комментарий от voltmod

Тебя забыли спросить. Прикол в том, что владельцы такого железа поумнее пишущих здесь комментаторов.

anonymous ()
Ответ на: комментарий от emmanuel

На pentium4 архитектуру archlinux32 переезжает, без SSE сейчас не жизнь.

One ★★★ ()
Ответ на: комментарий от voltmod

Как обычно, под такими новостями вылезают любители логики «я гажу, значит, все должны гадить!»

Починил, не благодари.

Сам недавно выкинул старье уровня p4, даже на авито влом это продавать.

Мог выставить за символическую цену в 1 рубль с самовывозом, могли найтись те, кому это нужно. А теперь на помойке его просто раскурочат, и так дофига хлама на планете.

hobbit ★★★★★ ()
Ответ на: комментарий от AVL2

флатпака тоже не будет?

Наверно. Вот поэтому кстати он мне не нравится — сделано как-то чужими для чужих.

В snap store зашёл и сразу видно, что там LibreOffice только 64 битный. А в flathub искал пять минут, так и не нашёл как прочекать архитектуры 🤔

Ну так люто давно пора выкидывать. Мне с год назад понадобилось пакет 📦 сделать, я озаботился с arm, а x86-32 ну не смешно уже в 2019 году.

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от question4

Nodejs спокойно самый последний (12.3.1) под i686 стоит, для электрона что-то другое нужно?

One ★★★ ()
Ответ на: комментарий от a1batross

сборку этой бестолковой поделки

Ого. Единственный вменяемый открытый офис, оказывается, бестолковая поделка. Да вы, батенька, опухли в край.

anonymous ()
Ответ на: комментарий от One

Электрон и экспишечку не поддерживает, и 32 бита депрекейтнул. Берите лучше nwjs, не пожалеете.

linuxnewbie ()
Ответ на: комментарий от mx__

steam давно уже во flatpack есть.

Ну есть и можно пользоваться — это сильно разные вещи. Судя по багтрекеру имеет место первое.

А так стим и под macOS 32 битная на что ОС матерятся «скоро дропнем поддержку».

fornlr ★★★★★ ()
Ответ на: комментарий от gremlin_the_red

Понимаю, что это шутка, но Ноль пользователей - множественное число

anonymous ()
Ответ на: комментарий от hobbit

могли найтись те, кому это нужно

Вероятность край немала, тк такое «нужно» только поехавшим.

anonymous ()
Ответ на: комментарий от anonymous

Не. Ты зря так думаешь — за бесплатно найдутся.

Я всякое выставлял — всегда находились покупатели.

Единственное, что DialUP модем никто не взял в 2018 году. Думал что хоть из-за блока питания, но не нашлось желающих.

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от fornlr

Зайди на авито, так кор2дуо мешками по 100р раздают, и никому не нужно.

anonymous ()
Ответ на: комментарий от anonymous

Чего ты мне рассказываешь. Я тоже раздаю — всегда берут 🤣

fornlr ★★★★★ ()
Ответ на: комментарий от fornlr

Значит разбирают на запчасти/цветмет.

anonymous ()
Ответ на: комментарий от anonymous

Тебя забыли спросить. Прикол в том, что владельцы такого железа поумнее пишущих здесь комментаторов

Перельман тоже умный, и что теперь всем в говне жить?

voltmod ★★ ()
Последнее исправление: voltmod (всего исправлений: 1)
Ответ на: комментарий от Tigger

есть ещё кто-то, использующий для работы железяки без поддержки 64 бит?

У меня есть старый ноут, в котором нельзя поставить больше 2Г памяти. Процессор поддерживает 64 бита, но что толку? Если поставить 64-битную версию Дебиана, то он шевелиться не будет. А на 32 бита довольно шустро работает.

sena ()
Ответ на: комментарий от sena

В таких случаях используют вместо DE менеджер окон и прочий легкий софт. 32бит тут особо не поможет.

anonymous ()
Ответ на: комментарий от sena

но что толку?

И поэтому ты пользуешься бинарной сборкой, расчитанной на древние процессоры и игнорируешь кучу новых команд и регистров новых процессоров? Ведь хрен у тебя сборка с новыми командами и регистрами, но только с 32-битными указателями.

Это очень недальновидно. Впречем, делай как знаешь.

ZweiStein ★★ ()

Только недавно устанавливал версию 5.3 в CentOS 5.10 32-bit. Кажется, 2 года назад. Это работало, оставалось только доустановить libstdc++.so.6 более новой версии. И нажатие правой кнопкой во Writer-е приводило к Segmentation failt.

И вот прошло всего 2 года, и поддержку прекратили. Зачем? На 512 Мб ОЗУ это прекрасно работало ещё 2 года назад. Причём работало достаточно быстро, явно нужно меньше памяти.

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от fornlr

А в flathub искал пять минут, так и не нашёл как прочекать архитектуры

Никак. Там даже версий порой не сыщещь. Только по факту проверять. Но flathub собирает и 32 бита то, что можно собрать. Хотя вот Hanbrake 64-битного нет, при том что даже в репозиториях есть.

emmanuel ()
Ответ на: комментарий от praseodim

Хотя строго говоря не всегда, но это на совсем слабеньких машинках, типа какой-нибудь 386sx на 16-20МГц и 1 Мб памяти.

Какие нафиг 386 и мегабайты?? 16 бит - это 65536 байт адресуемой памяти, и ни битом больше. Дальше только с костылями в виде страничной или сегментной адресации. Интел 8086 выпущенный в мохнатом 1978 уже имел эти костыли изначально вместо 32битности. И ничо, 15 лет никто не улюлюкал и не требовал закопать. Реально на 32 бита начали переползать, когда объем оперативы раз в 50 превысил тот, который прямо доступен для 16 бит. Проецируя ситуацию «16vs32» на «32vs64», переползать на 64 бита надо было бы при объемах РАМ от 200 Гб и выше.

chuzhoi ()

А? Чо? Ещё есть браузеры которые не могут то что может ОО и Lo? пфф..

anonymous ()
Ответ на: комментарий от chuzhoi

Какие нафиг 386 и мегабайты?? 16 бит - это 65536 байт адресуемой памяти, и ни битом больше. Дальше только с костылями в виде страничной или сегментной адресации.

16 бит было можно сказать даже жаргонным термином, потому что с точки зрения адресации памяти 8086 был не 16-ти битным, а честным 20-битным. Со всеми линиями.

Дальше только с костылями в виде страничной или сегментной адресации. Интел 8086 выпущенный в мохнатом 1978 уже имел эти костыли изначально вместо 32битности.

Эти костыли были на уровне команд процессора из-за того, что Intel почему-то захотел 8086(88) сделать хоят бы частично обратно совместимым с 8080. Теоретически код для 8080 мог исполняться в пределах 65k сегмента 8086.

На практике же и не все так гладко было и не очень нужно. Даже интересно, где-то реально такие трюки использовались? Впрочем, учитывая что 8086 изначально (до выбора IBM) был процессором совсем не для универсальных компьютеров, а для разных промышленных плат (много позднее даже как embedded) может что где и было.

В компьютерах на базе 8080 (и Z80) и более 65Кб памяти были действительно настоящие костыли с переключениями банков памяти, а в 8086 просто адресация кривая была.

Проецируя ситуацию «16vs32» на «32vs64», переползать на 64 бита надо было бы при объемах РАМ от 200 Гб и выше.

В принципе к этому и шло. Расширение PAE появилось еще в PentiumPro. и если бы не AMD с ее amd64 (x86_64) в рамках x86 могло так и получиться.

praseodim ★★★★ ()
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

И вот прошло всего 2 года, и поддержку прекратили. Зачем?

Ответ очевидный: чтобы не возиться с кучкой никому не интересных маргиналов и больше внимания уделять поддержке нормальных пользователей.

Partisan ★★ ()
Ответ на: комментарий от Partisan

Но ведь для этого пришлось обновлять билд-ферму, возиться, прикладывать усилия. А когда билд-ферма базировалась на предыдущей версии системы, то пользователи новых систем всё равно запускали получившиеся бинарники без проблем

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от ZenitharChampion

Но ведь для этого пришлось обновлять билд-ферму, возиться, прикладывать усилия.

Выкинуть намного проще - гораздо меньше усилий чем поддержка.

anonymous ()
Ответ на: комментарий от anonymous

Но ведь и в RHEL5 (на котором билд-ферма базировалась раньше) можно установить последний компилятор...

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от anonymous

С моей точки зрения, обновление билд-фермы с CentOS 5 на 6 ведёт только к одному изменению: меняется минимально необходимая версия GTK с 2.10 до 2.18, и Glibc с 2.4 до 2.12. Ты прав, говоря, что ошибку «ваш GTK слишком старый» получат мало пользователей. Но и преимуществ тоже никаких не будет. Преимущество есть только в том, что не надо писать под старый компилятор. Но ведь компилятор можно обновить, не обновляя остальное.

ZenitharChampion ★★★★★ ()
Последнее исправление: ZenitharChampion (всего исправлений: 2)
Ответ на: комментарий от Shaman007

Это новость?
Shaman007 ★★★★★ (06.06.19 00:01:05)

Теперь еще и проверенная Шаманом :)

slackwarrior ★★★★★ ()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Да причём тут компилятор. Просто открой их багтрекер — он завален. Вот и всё.

Воспроизводить и отслеживать всю эту ерунду сложно, ресурсов не хватает.

А так хоть можно сразу смотреть, если багрепорт с 32 битной ОС, то ну его.

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 2)
Ответ на: комментарий от burato

«Компьютерный мастер» без компьютера что ли?

Tigger ★★★★★ ()
Ответ на: комментарий от anonymous

Когда он нормально научится позиционировать картинки, то тогда поговорим.

Я студент и мне либреофис так вымотал много нервов. Я периодически возвращаюсь, но проблемы с картинками никуда не деваются.

a1batross ★★★★★ ()
Ответ на: комментарий от Tigger

для работы железяки без поддержки 64 бит?

Да, использует.

Odalist ★★★★★ ()
Ответ на: комментарий от ZweiStein

И поэтому ты пользуешься бинарной сборкой, расчитанной на древние процессоры и игнорируешь кучу новых команд и регистров новых процессоров? Ведь хрен у тебя сборка с новыми командами и регистрами, но только с 32-битными указателями.

У меня стандартный Дебиан, там сборка под пентиум какой-то старый. Едва ли новые команды сильно помогут, когда система начнёт свопиться. Память в этом случае важнее процессора. Да и кэш процессора вместит больше 32-битных указателей и команд с ними...

sena ()
Ответ на: комментарий от fornlr

Все замечательно, но будучи маргиналом я не могу радоваться тому, что они взяли и убили сборку в 32-бита.

И радуюсь, если упавшее знамя перехватывает комьюнити. На то опенсорц и нужен.

AVL2 ★★★★★ ()
Ответ на: комментарий от anonymous

Лёгкий софт - само собой. И 32 бита заметно способствуют этой лёгкости.

sena ()
Ответ на: комментарий от ZenitharChampion

Тут, похоже, обновляют ОС сборки с RHEL 5 сразу на 7, чтобы были GTK3 и Wayland

anonymous ()
Ответ на: комментарий от AVL2

И радуюсь, если упавшее знамя перехватывает комьюнити. На то опенсорц и нужен.

Ну практика показывает, что знамя и в основном использовании тяжело несётся, а ты про ...

fornlr ★★★★★ ()
Ответ на: комментарий от hobbit

я как-то его собирала. вроде ничего особого, только он тащит за собой кучи непонятного говна, включая аж библиотеки мультимедии, зачем-то. сначала надо собрать всю эту мультимедию, а уже потом LO. правда, я под 64 бита собирала. но для таких прикладных программ вряд ли есть разница, сколько там бит в системе.

Iron_Bug ★★★★ ()
Ответ на: комментарий от chuzhoi

надо было бы

If you have 8GB of RAM or more, the biggest advantage _by_far_ for the kernel is that you don't spend 25% of your system time playing with k[un]map() and the TLB flushing that goes along with it. You also have much more freedom to allocate (and thus cache) inodes, dentries and various other fundamental kernel data structures.

And for the kernel, the bigger virtual address space really is a _huge_ deal. HIGHMEM accesses really are very slow. You don't see that in user space, but I really have seen 25% performance differences between non-highmem builds and CONFIG_HIGHMEM4G enabled for things that try to put a lot of data in highmem (and the 64G one is even more expensive). And that was just with 2GB of RAM.

And when it makes the difference between doing IO or not doing IO (ie caching or not caching - when the dentry cache can't grow any more because it _needs_ to be in lowmem), you can literally see an order-of-magnitude difference.

With 8GB+ of ram, I guarantee you that the kernel spent tons of time on just mapping high pages, _and_ it couldn't grow inodes and dentry caches nearly as big as it would have wanted to. Going to x86-64 makes all those issues just go away entirely.

So it's not «you can save a few instructions by not spilling to stack as much». It's a much bigger deal than that. There's a reason I personally refuse to even care about >2GB 32-bit machines. There's just no excuse these days to do that.

https://yarchive.net/comp/linux/x86-64.html

anonymous ()
Ответ на: комментарий от ZenitharChampion

И вот прошло всего 2 года, и поддержку прекратили

Л — Логка. С чего им ориентироваться на тебя? Поддержка i386 существовала с 1996го, это 23 года. И поддержку всё ещё не прекратили, только сборки выкладывать перестали.

На 512 Мб ОЗУ это прекрасно работало ещё 2 года назад

Это ты хипсторам в барбершпе будешь рассказывать о великом прошлом времён PC DOS 1.0. А я не просто это застал, но и лет 6 назад свежесписаный с работы комп отнёс не на помойку, а в шахматный клуб отнёс, чтобы хоть что-то было. И он там до сих пор работает, и офисом там регулярно пользуются. А это P4 2.53MHz и 1GB DDR1. Работать он, конечно, работает, но слова



«быстро, шустро, хорошо, прекрасно» надо писать на почтительном отдалении, чтобы всем было понятно, что общего они с этой работой ничего не имеют.

gremlin_the_red ()

ЭТО ПРОВАЛ!

anonymous ()

А разве х86 не закопали в юзерском сегменте новыми машинами года с ~2011?

This decision is caused by the dwindling number of users downloading the 32-bit Linux distribution-neutral binaries

Поддерживаю как разраб. Сразу как-то стало легче, после удаления jenkins-задач связанных с этой платформой-рухлядью на своих проектах - жрет на билдсервере, как полноценный продукт, а выхлоп нулевой. Правда пришлось подключать кризис-манагера закрывать тикеты от пары совсем упертых баранов, работающих на древних машинах 2003-2004 года покупки, и с периодичностью в месяц-полтора ставящих тикеты "КАКОГО ЧЕРТА ВЕРСИЯ 9.х МЕДЛЕННО РАБОТАЕТ??7!11 МЫЖЗАПЛАТИЛИ АЖ 6 ЛЕТ НАЗАД ЗА ВЕРСИЮ 4.х!". Но это уже их половые проблемы - я наконец смог сделать полноценные ломающие х86 оптимизации, выиграв ~40% в обычных кейсах и ажно ~88-89% на специализированных, что аж потянуло на мажорку.

DzenPython ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.