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

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

А можно пруфы про решения каких-то вопросов какими-то людьми?

Ну вот ссылка раз — срыв покровов от gag.

Ссылка два — собственно пакеты для Бастера с сайта Дебиана.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну и ладно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но что толку?

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

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

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

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

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

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

Вопросы к авторам Электрона.

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

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

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

Какие нафиг 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 могло так и получиться.

Что за контора такая гнилая?

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

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

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

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

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

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

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

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

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

Я не контора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

надо было бы

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

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

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

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

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

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

ЭТО ПРОВАЛ!

А разве х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% на специализированных, что аж потянуло на мажорку.

с компьютерами