Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от opennews (?), 12-Дек-18, 22:49
В списке рассылки ядра Linux обсуждается (https://lkml.org/lkml/2018/12/10/1145) вопрос удаления кода с реализацией субархитектуры x32 (https://sites.google.com/site/x32abi/), позволяющей использовать на 64-разрядных системах 32-разрядную модель адресации памяти. По мнению инициатора удаления технология x32 не оправдала себя и не нашла практического применения в современных промышленных дистрибутивах. Кроме того, в коде x32 используется достаточно спорный метод работы с системными вызовами, создающий риск нарушения нормального функционирования после переработки реализаций системных вызовов. Линус Торвальдс сообщил (https://lkml.org/lkml/2018/12/10/1151), что он не против удаления x32, если не будут представлены аргументированные возражения или не будут заявлены системы, в которых x32 нашла своё применение.  Линус также отметил, что, судя по всему, применение x32 ограничилось экстремальными тестами производительности, так как поддержка данной субархитектуры сопряжена с большим усложнением сопровождения дистрибутивов и окружения для разработки. В своё время при тестировании x32, один из разработчиков Gentoo пришёл (https://www.opennet.ru/opennews/art.shtml?num=34188) к выводу, что выигрыш в производительности  при переходе на x32 ABI не столь велик, как показывают синтетические тесты от создателей x32 ABI - заметный прогресс отмечается только при сравнении с устаревшей архитектурой x86, но при сравнении с актуальной архитектурой x86-64 выигрыш несущественный (тесты от создателей x32 показывали ускорение до 30% в сравнении с классическим x86_64 ABI, в ситуациях, связанных с интенсивной работой с указателями). Напомним, что субархитектура x32 (https://sites.google.com/site/x32abi/) представляет собой гибридный x86_64 ABI, позволяющий использовать на 64-разрядных системах 32-разрядную модель адресации памяти (процессор работает в 64-разрядном режиме, но использует 32-разрядные указатели и арифметические операции). ABI X32 позволяет приложениям использовать все преимущества архитектуры x86_64, такие как дополнительные регистры и более быстрые инструкции, PIC ABI. В то же время ABI X32 даёт возможность работать с 32-разрядными указателями памяти, что позволяет экономить память, способствует более эффективному наполнению процессорного кэша и положительно сказывается на общей скорости исполнения кода.  Ограничением ABI X32 является невозможность адресации из приложения более 4 Гб памяти. Поддержка X32 входит в состав ядра Linux  начиная с выпуска 3.4 (https://www.opennet.ru/opennews/art.shtml?num=33888), сформированного в мае 2012 года. URL: https://lwn.net/Articles/774734/rss Новость: https://www.opennet.ru/opennews/art.shtml?num=49772
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
Сообщение от ыфвыфв (?), 12-Дек-18, 22:49
О, неужто прозрели?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	145. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Акакжев (?), 13-Дек-18, 08:44
	Intel обхаживают целенаправленно и давно. https://wiki.yoctoproject.org/wiki/X32_abi
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	241. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (-), 13-Дек-18, 14:51
	> Intel обхаживают целенаправленно и давно. Ставить интел в (около)эмбедовку можно только от большой глупости. Все как бы в курсе и поэтому для начала сам интел в таких применениях мало кому сдался. Вместе со своими проприетарными BIOS/UEFI, глюкавыми ACPI и потреблением электричества за троих, так что без вентилятора систему хрен сделаешь, питальник дорогой и сложный, как и ups, если это вдруг надо. Ну а экзотичное ABI достигает лишь 1 цели: умеющих с ним работать 0 целых, хрен десятых. Поэтому с глюками, дебагинном, софтом и проч можно будет выкусить, а спросить будет некого.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	251. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от Аноним (251), 13-Дек-18, 15:21
	Да не, за x86(-64, естессно) в эмбедовке будущее. Стоимость процов и тепловыделение наконец-то стали приемлемыми для таковой.
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	262. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+6 +/–
	Сообщение от Аноним (262), 13-Дек-18, 15:56
	> Да не, за x86(-64, естессно) в эмбедовке будущее. Стоимость процов и тепловыделение > наконец-то стали приемлемыми для таковой. Там проблемы далеко не только в тепловыделении. Но чтобы об этом знать - этим надо заниматься, а не только пытаться блестнуть своей экспертизой. Основная проблема там в общей сложности системы и куче дурных проблем. Начиная от того что проприетарный uefi/bios может безальтернативно встрять на press any key to continue, а поскольку он проприетарный - это не отломаешь при всем желании, и заканчивая тем что питальник там надо весьма большой и капитальный, с кучей напряжений и все такое. Если это что-то с минимальным намеком на реалтайм - SMI# может прилететь в любой момент, ОС не имеет над этим контролем, ее просто вышибут в неизвестный SMM handler в проприетарном биосе, на неопределенное время. Все это время железка будет беспомощной тряпочкой и не сможет реагировать на внешние события. При том критерии дерга SMI# в конкретной системе - одному Ктулху известны. В половине систем вачдога нормального и то нет - так что виснет насовсем, и технарь поедет жать ресет. Что как бы денег стоит эксплуатанту.
	Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

	252. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Акакжев (?), 13-Дек-18, 15:26
	>> Intel обхаживают целенаправленно и давно. > Ставить интел в (около)эмбедовку можно только от большой глупости. Все как бы > в курсе и поэтому для начала сам интел в таких применениях > мало кому сдался. В том то и фишка, что все. Включая Интел. При этом у Интеля много фантиков, которые они тратят на продвижение. Теперь появился повод немножко поделиться, что бы пролоббировать вариант "если представлены аргументированные возражения".
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	264. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (262), 13-Дек-18, 15:59
	Интел даже с своими tablet PC грезил со времен чуть не Win2000. Сейчас конец 2018, но воз и ныне там - гуано типа атомов оказалось никому не надо. Даже с приплачиванием OEMам. Просто потому что работает отвратительно. Особенно - управление питанием. Когда такой из себя приемлимый сажает батарею быстрее чем заряжается. Особенно если захотеть питалово от usb, а не ноутбучный 19-вольтовый кирпич весом и размером с полпланшета, который потом везде таскать с собой в обязаловку придется - потому что он нестандартный, однако.
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	266. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (262), 13-Дек-18, 16:00
	А, да, туда же и скончавшийся эдисон и его нескольких родственников. Те кто сдуру в это вляпался заодно узнали чем хорошо когда альтернативы доступны с нескольких поставщиков :)
	Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

	365. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Акакжев (?), 14-Дек-18, 07:50
	> Интел даже с своими tablet PC грезил со времен чуть не Win2000. > Сейчас конец 2018, но воз и ныне там Ой, Вы таки слишком увлеклись технической стороной дела. Если Интел подкреплял свои "угрозы" финансированием, но воз и ныне там, что из этого следует? Очевидно, кое-кто на этом безрезультатном (для Интел и потребителя) поприще немножко таки подзаработал.
	Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

	393. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (-), 14-Дек-18, 15:01
	> что из этого следует? То что интел уже цатый год подряд страдает хней с околонулевым результатом. Недавний шатдаун эдисонов и кого там еще тому лишний пример. Дорогие, переусложненные железки с глючной проприетарной фирмварью, единственным и абсолютно незаменимым поставщиком и прочими характерными прелестями - это очень хорошая заявка на залет.
	Ответить | Правка | ^ к родителю #365 | Наверх | Cообщить модератору

	412. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 16:50
	> То что интел уже цатый год подряд страдает хней с околонулевым результатом. > Недавний шатдаун эдисонов и кого там еще тому лишний пример. > Дорогие, переусложненные железки с глючной проприетарной фирмварью, единственным и абсолютно > незаменимым поставщиком и прочими характерными прелестями - это очень хорошая заявка > на залет. У Интела под контролем почти весь рынок серверов «начального и среднего уровня». При тех жирных прибылях, что поступают с этого рынка, Интелу решительно без разницы, довольны ли его продукцией частные покупатели.
	Ответить | Правка | ^ к родителю #393 | Наверх | Cообщить модератору

	417. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Акакжев (?), 14-Дек-18, 19:10
	> У Интела под контролем почти весь рынок серверов «начального и среднего уровня». > При тех жирных прибылях, что поступают с этого рынка, Интелу решительно > без разницы, довольны ли его продукцией частные покупатели. Компания Intel раскрыла финансовую отчетность за 2017 год. Выручка компании составила $62,8 млрд Выручка основного сегмента компании - «Устройства и системы для ПК» - выросла до $34,0 млрд. Выручка второго по величине сегмента компании «Серверная продукция» составила $19,1 млрд., увеличившись на 10,6%. Внушительную динамику по выручке (+20,1%) и по операционной прибыли (11,1%) показал сегмент «Интернет вещей» вследствие роста цен на платформы, спроектированные для рыночных сегментов Интернета вещей, в том числе, в сфере розничной торговли, транспорта, промышленности. Почему же таки Анонимы, бесплатно работая на компанию Фригийский Колпак, считают, что Интел не занесёт долю малую?
	Ответить | Правка | ^ к родителю #412 | Наверх | Cообщить модератору

	418. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 19:41
	Выручка и прибыль (и норма прибыли, маржа) — это не одно и то же. Там, где Интел делает большие деньги, приходится, говорят, иногда и неустойки выплачивать, и за свой счёт компенсировать потери. Зато старшие и средние в линейке изделия на этом рынке стоят до нескольких тысяч долларов за штуку, и это вполне серийная продукция, а не единичные экземпляры для фанатов. Статистика лукава. Частным покупателям Интел ничего не компенсирует, ни копейки, можете хоть в десять судов подать иски. Так что думайте, какие выводы делать из этих цифр. Желательно, после того, как посмотрите на интеловские ценники. Причём реальных цен (как и обязательств) по контрактам с Настоящими Ынтерпрайзами вы всё равно из этих цифр не узнаете. ;-)
	Ответить | Правка | ^ к родителю #417 | Наверх | Cообщить модератору

	421. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Акакжев (?), 14-Дек-18, 20:22
	> Выручка и прибыль (и норма прибыли, маржа) — это не одно и то > же. > Причём реальных цен (как и обязательств) по > контрактам с Настоящими Ынтерпрайзами вы всё равно из этих цифр не > узнаете. ;-) Ага, скрывается, стало быть, прибыль. ;-) Потому спонсировать сохранность x32 придётся с выручки.
	Ответить | Правка | ^ к родителю #418 | Наверх | Cообщить модератору

	431. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 23:34
	Думается, что скрывать прямо и нагло — нет, вряд ли. Такое в США не спустили бы даже Интелу. А вот, кхм, диверсифицировать и оптимизировать затраты и налоговое бремя — отчего бы нет? В Ирландии, например, налоговый рай, как известно, половина индустриальной Америки там пасётся. И при этом всё законно.
	Ответить | Правка | ^ к родителю #421 | Наверх | Cообщить модератору

	578. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Andrey Mitrofanov (?), 18-Дек-18, 11:29
	>прямо и нагло — нет >в США не > спустили бы даже Интелу >диверсифицировать и оптимизировать >В Ирландии, например, налоговый рай, как Толстячок.
	Ответить | Правка | ^ к родителю #431 | Наверх | Cообщить модератору

	419. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 19:44
	Добавлю, кстати, нюанс, широко известный только в узких кругах. Многие крупные компании, и Интел не исключение, имеют «филиалы» и аффелированные фирмы, занимающиеся «финансами» и «инвестициями», всё отчасти в кавычках, зачастую на оффшорных юрисдикциях. Ну это так — к сведению и пища для размышлений.
	Ответить | Правка | ^ к родителю #417 | Наверх | Cообщить модератору

	420. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 19:46
	Начитался анонимов опеннета, в глазах уже рябит… Разумеется, ошибка: аффелированные^W аффилированные.
	Ответить | Правка | ^ к родителю #419 | Наверх | Cообщить модератору

	445. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 12:39
	> У Интела под контролем почти весь рынок серверов «начального и среднего уровня». Ну так речь то была про эмбедовку и тому подобные применения. Там у интеля радикально иная доля, близкая к 0%. И что характерно - за вполне характерное сочетание свойств. > без разницы, довольны ли его продукцией частные покупатели. Генри Форд тоже что-то такое про цвет автомобилей говорил.
	Ответить | Правка | ^ к родителю #412 | Наверх | Cообщить модератору

	595. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ванёк (?), 19-Дек-18, 16:56
	Intel давно официально забили болт на эмбеддовку.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	173. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Иван (??), 13-Дек-18, 10:37
	Отнюдь. Хейтеры были с самого начала. В данном случае просто опять вспомнили.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	227. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от pavlinux (ok), 13-Дек-18, 13:28
	C тем же успехом я докажу, что x16 ещё эффективнее.   Например целочисленное вычисление числа П или e, делается за 120000-150000 тактов. При этом в 16 бит влазит такая точность, что хватит для расчётов движения астероида, лет на 100 вперед. Кол-во итераций на х64 и х16, до равной точности, зависит от входных данных. Если у тя на первой итерации, после запятой болтается 3.0000000000001, то до 3.14159265... один хрен прим. 60 циклов нужно будет. Но, внезапно, при этом сожрётся в 4 РАЗА меньше памяти :)   А можна на x64 в 2 SSE регистра загрузить 4 огромных числа и за 4х4 цикла + 4 сложения вывалить огромной длины Пи. (FLDPI пока пропустим)
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	239. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (-), 13-Дек-18, 14:44
	Хейтеры или не хейтеры, но затраты на майнтенанс этой штуки есть, а реально этим пользоваться никто так и не стал, потому что выигрыш маргинальный, а поддержка новой архитектуры - это поддержка новой архитектуры. Потому что по ABI это не совместимо ни с IA32, ни с x64. Т.е. совершенно отдельные программы под отдельное ABI.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

2. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
Сообщение от Аноним (2), 12-Дек-18, 22:51
делайте lts и после неё выкидывайте
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+10 +/–
	Сообщение от linus (?), 12-Дек-18, 22:56
	аргументируйте
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–3 +/–
Сообщение от КГБ СССР (?), 12-Дек-18, 22:55
> Ограничением ABI X32 является невозможность адресации из приложения более 4 Гб памяти. Ведь всем известно, что типичному приложению жизненно необходимо адресовать более 4 гигов памяти. Что? Экономия? Пусть мясные докупят ещё оперативной памяти и новый процессор! Да и более важные дела есть — например, борьба за равенство и против харазмента и гендерного шовинизма. Не верите? Прочтите интервью с доченькой Линуса: https://opensource.com/life/15/8/patricia-torvalds-interview . Юное дарование выросло во всех смыслах Товальдс 2.0, таки да. Всё, что вам интересно знать про уровень умственного и нравственного развития современных кодописов, наглядно предстаёт из таких новостей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Анонимчжан (?), 12-Дек-18, 22:59
	как правило дети не наследуют таланты оотцов)) как правило у них они совершенно другие. таки да америка губит таланты))))
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	36. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+4 +/–
	Сообщение от КГБ СССР (?), 12-Дек-18, 23:51
	> как правило дети не наследуют таланты оотцов)) как правило у них они > совершенно другие. таки да америка губит таланты)))) С тем, что Америка губит таланты, я согласиться не могу. Но, действительно, некоторые детишки явно не те таланты унаследовали от родителей. :)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	240. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (-), 13-Дек-18, 14:46
	Так папаше никто не запрещает же пойти и использовать x32, собирая под него проги и майнтайня пакеты. Но за столько лет папаш желающих всерьез применять И МАЙНТАЙНИТЬ все это чего-то не нашлось. А указывать другим что делать и куда идти - чревато тем что вам ответят той же монетой.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	7. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–6 +/–
	Сообщение от mikhailnov (ok), 12-Дек-18, 23:03
	Почитал. Вы преувеличили и высосали из пальца.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	98. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 13-Дек-18, 03:47
	Если то, что я прочитал в интервью не идиотизм, то что тогда идиотизм?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	154. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 09:09
	> Если то, что я прочитал в интервью не идиотизм, то что тогда > идиотизм? Даже как-то по-человечески жаль стало Линуса.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	243. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (243), 13-Дек-18, 15:01
	Это скорее тебя несколько жаль. В таком возрасте можно было бы и начать догадываться чем прожектменеджер отличается от ломового кодера. Но увы - как известно, "иногда старость приходит одна".
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	257. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 15:43
	> Это скорее тебя несколько жаль. В таком возрасте можно было бы и > начать догадываться чем прожектменеджер отличается от ломового кодера. Но увы - > как известно, "иногда старость приходит одна". http://lurkmore.to/Мне_вас_жаль Возвращайся к пакованию эмбедовки с Али, 294-й, а то купить доширак будет не на что.
	Ответить | Правка | ^ к родителю #243 | Наверх | Cообщить модератору

	267. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (262), 13-Дек-18, 16:04
	Ну, блин, понимаешь, моя эмбедовка будет работать и даже ее поддержку в обозримом будущем таки не грохнут. А вот x32 - таки сам понимаешь. Вот конкретно лично ты этим ABI из своей NT-что-то-там даже и пользоваться то не сможешь, для начала. Так что группа поддержки из тебя получается никакущая.
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	270. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 16:15
	Судя по тому, что ты пишешь, к промышленной эмбедовке ты никакого отношения не имеешь, а просто в розницу торгуешь ардуинками с Али. Нет? Я ошибаюсь? :-)
	Ответить | Правка | ^ к родителю #267 | Наверх | Cообщить модератору

	280. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (-), 13-Дек-18, 16:56
	> Судя по тому, что ты пишешь, к промышленной эмбедовке ты никакого отношения не > имеешь, а просто в розницу торгуешь ардуинками с Али. Нет? Я ошибаюсь? :-) Ошибаешься. Я торгую услугами по разработке и интеграции. В гробу я видел пытаться конкурировать алиэкспресс и прочие чипидипы тупой торговлей. Смысл такой что я могу сделать согласование моих железок с энной инсталляцией, начиная от электрического и логического уровня до убеждения софта делать со всем этим то что клиент на самом деле хотел. Я не буду настаивать что это специализированное промоборудование. Но все же в основном какая-то автоматика и т.п. - с уклоном в какую-то такую сторону. И потому потугами делать все это довольно надежным, стабильным, с авторекавери на режим если фэйл все же вышел и т.п.. Как пример: штука прикидывается с одной стороны античной железкой. Хватает по 232 данные, отвечает как будто это железка, так что то к чему оно прицеплено не замечает никакого лабеана. С другой стороны оно пробрасывает награбленое по сети, к черту на рога. Оригинал так ессно не умел и в проекте, его радиус действия был жестко ограничен 232-м. Level shifter 3.3V UART проца <-> обычный 232 ессно я организовал. И таки привет ветеранюниксадминам, если прога окучивавшая UART умрет - меня с гуано таки замесят. А это таки не сетевой сервис, так что monit таки пролетает. В этом месте я и вспоминаю SD'шный вачдог апи добрым словом. Потому что техническая необходимость.
	Ответить | Правка | ^ к родителю #270 | Наверх | Cообщить модератору

	292. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:37
	А здесь на опеннете кому ты это пытаешься продать? :-)
	Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

	395. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 14-Дек-18, 15:03
	> А здесь на опеннете кому ты это пытаешься продать? :-) А здесь на опеннете я ничего не пытаюсь продать. Такому клиенту как ты что-то продавать - себе дороже, скажем прямо. Заплатишь рубль, а мозг склюешь на миллиард. Поэтому народ уже давно усвоил что с некоторыми клиентами дел лучше не иметь вообще совсем. И вот опеннет - это очень плохое место для поиска клиентов :)
	Ответить | Правка | ^ к родителю #292 | Наверх | Cообщить модератору

	399. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 15:28
	>> А здесь на опеннете кому ты это пытаешься продать? :-) > А здесь на опеннете я ничего не пытаюсь продать. Такому клиенту как > ты что-то продавать - себе дороже, скажем прямо. Заплатишь рубль, а > мозг склюешь на миллиард. Поэтому народ уже давно усвоил что с > некоторыми клиентами дел лучше не иметь вообще совсем. И вот опеннет > - это очень плохое место для поиска клиентов :) Смотря каких клиентов и для чего ты ищешь. Парочке местных персонажей не мешало бы переломать ноги и пальцы на руках при тёплой дружеской встрече.
	Ответить | Правка | ^ к родителю #395 | Наверх | Cообщить модератору

	450. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (-), 15-Дек-18, 15:12
	> Смотря каких клиентов и для чего ты ищешь. В идеале денежных и с интересными задачами, на которых можно прокачаться как специалисту и глядя на результат сказать "черт возьми, я сделал это". Без первого я помру с голода, без второго - стухну как специалист, потом по первому сценарию. > Парочке местных персонажей не мешало бы переломать ноги и пальцы на руках при тёплой > дружеской встрече. Такой виш куда-нибудь к гопникам уместнее.
	Ответить | Правка | ^ к родителю #399 | Наверх | Cообщить модератору

	591. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ванёк (?), 19-Дек-18, 15:10
	А если их при встрече окажется сильно не двое :)
	Ответить | Правка | ^ к родителю #399 | Наверх | Cообщить модератору

	592. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 19-Дек-18, 15:15
	Если таких, как местный борцуха с врагами из-за океана, то хоть десяток — разбегутся от ужаса. :)
	Ответить | Правка | ^ к родителю #591 | Наверх | Cообщить модератору

	471. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 21:11
	>> А здесь на опеннете кому ты это пытаешься продать? :-) > А здесь на опеннете я ничего не пытаюсь продать. Такому клиенту как > ты что-то продавать - себе дороже, скажем прямо. Заплатишь рубль, а > мозг склюешь на миллиард. Поэтому народ уже давно усвоил что с > некоторыми клиентами дел лучше не иметь вообще совсем. И вот опеннет > - это очень плохое место для поиска клиентов :) Как обычно у непризнанных гениев то народ неправильный, то коллектив или сообщество не то... Признаться себе в том, что ты просто мелкий барыга у тебя духу не хватит.
	Ответить | Правка | ^ к родителю #395 | Наверх | Cообщить модератору

	508. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 18:58
	> Как обычно у непризнанных гениев то народ неправильный, то коллектив или сообщество не то... Ну как бы сообщество на опеннете весьма специфичное. И как таковое - технари. Проблема которых в том что они лучше всех знают как надо. Ну а раз так - тогда и работу они работают сами. Во избежание поимения моего мозга в неприемлимых объемах, для начала. Если кто ловит такси - он наверное не учит водителя педали правильно жать. > Признаться себе в том, что ты просто мелкий барыга у тебя духу не хватит. А тут как бы все зависит от стыковки целей, интересов, мотивации и нужности мне самому результата. Некоторые работы таки выполняются совершенно бесплатно, на альтруистичных началах. Покуда у меня есть на это ресурсы, проект интересен, результат нужен и сообщество оного вызвает симпатии. Но это явно не про обслуживание причуд КГБобразных нахаляву. Хотя-бы потому что когда он там с 6-й нти рассказывает как правильно в линуксе - вот пусть в ЕГО линуксах так и будет. А я не хочу умничать из 6-й нти как этот гражданин :)
	Ответить | Правка | ^ к родителю #471 | Наверх | Cообщить модератору

	509. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Ю.Т. (?), 16-Дек-18, 19:11
	> Если кто ловит такси - он наверное не учит водителя педали > правильно жать. Например, если таксист повёз окольной дорогой или вовсе не туда.
	Ответить | Правка | ^ к родителю #508 | Наверх | Cообщить модератору

	510. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 20:23
	> Например, если таксист повёз окольной дорогой или вовсе не туда. Ну как бы куда едем, сколько стоит и за сколько времени ожидается выполнение - согласуется изначально. А вот если видны намеки на именно попытки указывать как педалить - лучше другого пассажира взять. Тем более что таксисту мозг будут делать несколько часов, а айтишнику - дольше. И рисков больше, соответственно. Так что если клиент все сам знает до последнего винтика - я со своей стороны считаю что мои услуги не требуются. Специалистов зовут когда нужны их знания и опыт, а локально доступные варианты - хуже. При этом странно учить специалиста тому как надо.
	Ответить | Правка | ^ к родителю #509 | Наверх | Cообщить модератору

	524. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 06:25
	>Проблема которых в том что они лучше всех знают как надо К себе не пробовал присмотреться?
	Ответить | Правка | ^ к родителю #508 | Наверх | Cообщить модератору

	525. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 06:28
	>А тут как бы все зависит от стыковки целей, интересов, мотивации и нужности мне самому результата. Продолжай утешать себя, раз обмануть не получается.
	Ответить | Правка | ^ к родителю #508 | Наверх | Cообщить модератору

	533. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 08:41
	>>А тут как бы все зависит от стыковки целей, интересов, мотивации и нужности мне самому результата. > Продолжай утешать себя, раз обмануть не получается. Возможно даже, все эти "результаты" позади, как и собственно эпоха кустарей-одиночек и заказчиков "трюков".
	Ответить | Правка | ^ к родителю #525 | Наверх | Cообщить модератору

	540. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 09:13
	>>>А тут как бы все зависит от стыковки целей, интересов, мотивации и нужности мне самому результата. >> Продолжай утешать себя, раз обмануть не получается. > Возможно даже, все эти "результаты" позади, как и собственно эпоха кустарей-одиночек и > заказчиков "трюков". Писатели вредоносного по могут с тобой не согласиться. Хотя и они в основном давно уже работают в командах.
	Ответить | Правка | ^ к родителю #533 | Наверх | Cообщить модератору

	541. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 09:28
	>>>>А тут как бы все зависит от стыковки целей, интересов, мотивации и нужности мне самому результата. >>> Продолжай утешать себя, раз обмануть не получается. >> Возможно даже, все эти "результаты" позади, как и собственно эпоха кустарей-одиночек и >> заказчиков "трюков". > Писатели вредоносного по могут с тобой не согласиться. Хотя и они в > основном давно уже работают в командах. В любом виде деятельности всегда остаются ниши. Но общее направление в любом же виде -- от ремесленника к фабрике. Видимо, и решения на одноплатках через стадию новизны и приемлемости "трюков" пришли к тому же.
	Ответить | Правка | ^ к родителю #540 | Наверх | Cообщить модератору

	546. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 10:12
	>решения на одноплатках Я считаю что одноплатки вообще не нужны, для мелочи есть микроконтроллеры, а для большого мейнфреймы или спарки с обвязкой( с осями, написанными под них) УГ вроде ардуины в технике применять нельзя, за попытку применения удалять тестикулы отрывным методом.
	Ответить | Правка | ^ к родителю #541 | Наверх | Cообщить модератору

	547. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 10:26
	>>решения на одноплатках > Я считаю что одноплатки вообще не нужны, для мелочи есть микроконтроллеры, а > для большого мейнфреймы или спарки с обвязкой( с осями, написанными под > них) УГ вроде ардуины в технике применять нельзя, за попытку применения > удалять тестикулы отрывным методом. Ну это общая тенденция, чтобы без компьютера и в носу не поковырять. Так уж лучше одноплатки, чем наборы для творчества. И так ли лучше всего этого *сегодняшние массовые* МК? По-моему, налиты из той же бочки. Что ж до мэйнфреймов -- ))
	Ответить | Правка | ^ к родителю #546 | Наверх | Cообщить модератору

	555. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 12:38
	>чтобы без компьютера и в носу не поковырять. Я думаю это попытка создать искусственный спрос. У меня батхёрт от безумных домов и "умных" лампочек. Лопнет этот проклятый пузырь, ведь за ним пустота, ни концепции, ни "вэя".
	Ответить | Правка | ^ к родителю #547 | Наверх | Cообщить модератору

	558. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 13:40
	>>чтобы без компьютера и в носу не поковырять. > Я думаю это попытка создать искусственный спрос. У меня батхёрт от безумных > домов и "умных" лампочек. Лопнет этот проклятый пузырь, ведь за ним > пустота, ни концепции, ни "вэя". Мне кажется, у нас на руках мало данных, чтобы делать такие прогнозы. По крайней мере, все эти умные лампочки это вполне конкретные прибыли.
	Ответить | Правка | ^ к родителю #555 | Наверх | Cообщить модератору

	568. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 16:28
	Прибыли жидковаты по сравнению с "абибас" и резиновыми шлёпанцами. ИМХО, не взлетят умные лампы.
	Ответить | Правка | ^ к родителю #558 | Наверх | Cообщить модератору

	569. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 16:45
	> Прибыли жидковаты по сравнению с "абибас" и резиновыми шлёпанцами. ИМХО, не взлетят > умные лампы. Данные?.. Также всё это прекрасные зонды (тут много за браузеры с зондами переживают). А ведь уже известны попытки измерения настроения и управления поведением через соцсети: www.theguardian.com/technology/2014/jun/30/facebook-emotion-study-breached-ethical-guidelines-researchers-say www.theguardian.com/technology/2017/may/01/facebook-advertising-data-insecure-teens www.theguardian.com/technology/2017/oct/05/smartphone-addiction-silicon-valley-dystopia?lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_content%3B0KfcRCfIS3uvgy0L272OPg%3D%3D
	Ответить | Правка | ^ к родителю #568 | Наверх | Cообщить модератору

	570. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 16:56
	Я бы не переоценивал эти недотехнологии. Управлять поведением умели видимо даже доисторические шаманы. Ну а то,что все эти "умные" безделушки зонды думаю очевидно.
	Ответить | Правка | ^ к родителю #569 | Наверх | Cообщить модератору

	559. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 17-Дек-18, 13:45
	>>чтобы без компьютера и в носу не поковырять. > Я думаю это попытка создать искусственный спрос. У меня батхёрт от безумных > домов и "умных" лампочек. Лопнет этот проклятый пузырь, ведь за ним > пустота, ни концепции, ни "вэя". Умные колонки продаются не так хорошо, как ожидалось. Умное-всё-остальное, в общем, тоже. Но это всё фигня, в целом, а вот автопром не фигня: риск для здоровья и жизни людей.
	Ответить | Правка | ^ к родителю #555 | Наверх | Cообщить модератору

	562. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 14:42
	>Умные колонки продаются не так хорошо, как ожидалось. Помнишь, то же было и с "планшетами, заменами ПК". Люди не настолько глупы, как кажутся маркетоидам, не фортануло планшетотолкателям. >а вот автопром не фигня: риск для здоровья и жизни людей. А вот это действительно не фигня. Безопасными гробомобили могут стать, если на дороге останутся только роботы(хотя какой из теслы робот? просто экскримент на гугловерёвочке).
	Ответить | Правка | ^ к родителю #559 | Наверх | Cообщить модератору

	563. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 14:51
	>>Умные колонки продаются не так хорошо, как ожидалось. > Помнишь, то же было и с "планшетами, заменами ПК". Люди не настолько > глупы, как кажутся маркетоидам, не фортануло планшетотолкателям. Людей (и потребителей в них) перманентно воспитывают.
	Ответить | Правка | ^ к родителю #562 | Наверх | Cообщить модератору

	566. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 15:49
	Как бы воспитателей самих не воспитали. Как Марию-Антуанетту или кольку-кровавого.
	Ответить | Правка | ^ к родителю #563 | Наверх | Cообщить модератору

	466. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 20:38
	>> Если то, что я прочитал в интервью не идиотизм, то что тогда >> идиотизм? > Даже как-то по-человечески жаль стало Линуса. Поразило полное отсутствие цели. "борюсь за разнообразие" - А зачем? "А чтобы было". Её легко можно затравить, обвинив в шовинизме, ведь она воспринимает человеческий коллектив как аквариумных рыбок или морских свинок.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	511. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 20:48
	> "борюсь за разнообразие" > - А зачем? Могу сказать я. Когда окружение разнообразное, в нем представлено больше разных точек зрения и интересных идей. Это соответственно помогает избавиться от негативных эффектов сидения в башне из слоновой кости, когда какие-то академики что-то там себе навоображали, а реально они вообще не представляют как и для чего люди компьютерами пользуются. И потом оказывается что *bsd и прочие hurd даром никому не, компаниям проще дать денег финскому студню или амеровскому пройдохе, и что так что сяк для них работает намного лучше. Кстати в Майкрософт политика отсутствия дискриминации по всему чему угодно работала хрен знает сколько. Это их стандартная внутренняя политика со времен царя гороха. В общем то это обычная практика для западного корпоратив. И между нами, это создает хорошую, комфортную деловую атмосферу. Когда люди работают над решением задачи, а не набивают себе цену путем обсирака других. За вот такое поведение - из западной компании можно вылететь с присвистом. И, честно, это делает работу комфортнее.
	Ответить | Правка | ^ к родителю #466 | Наверх | Cообщить модератору

	514. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (514), 16-Дек-18, 21:55
	> Кстати в Майкрософт политика отсутствия дискриминации по всему чему угодно работала хрен знает сколько Это делается не ради толерантности, а ради создания естественного отбора. В чём конкурирует СПО? В упрямости авторов? Или в том, кому более щедрый спонсор попадётся? Хуже всего, когда выживает самый демократичный.
	Ответить | Правка | ^ к родителю #511 | Наверх | Cообщить модератору

	527. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 06:50
	>Когда окружение разнообразное, в нем представлено больше разных точек зрения и интересных идей Это зависит от черномазости, белозадости или половых перверсий? Да вы расист, батенька. > когда какие-то академики что-то там себе навоображали Хорошо показывают твою позицию "свиньи под дубом". Благодаря каким-то там акадэмикам ты можешь ковыряться в своих "кампутерах с кредитку" и даже впаривать их людям за деньги. >Кстати в Майкрософт политика отсутствия дискриминации по всему чему угодно работала хрен знает сколько Вот и результат -вин10, жрущая память, насилующая диск и барабанящая на братву, попутно радующая ломающими обновлениями. > В общем то это обычная практика для западного корпоратив. И между нами, это создает хорошую, комфортную деловую атмосфер Копротивная "культура" не может создавать здоровую атмосферу. Это косвенно подтверждает количество самоубийств в Японии, её родине. Ну и по существу ты не ответил, чем линусова дочурка занимается, к чему стремится? Из интервью это не ясно.
	Ответить | Правка | ^ к родителю #511 | Наверх | Cообщить модератору

	535. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 08:47
	> Ну и по существу ты не ответил, чем линусова дочурка занимается, к > чему стремится? Из интервью это не ясно. "Если не ясно, в чём дело, то дело в деньгах". Народная польская пословица. Ну чем может заниматься человек без чётко выраженной квалификации? Диверсити защищает, гранты пилит. Тяжёлого не поднимает, работа в тепле.
	Ответить | Правка | ^ к родителю #527 | Наверх | Cообщить модератору

	536. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 08:49
	>Диверсити защищает, гранты пилит. Тяжёлого не поднимает, работа в тепле. Но это же скучно, разве нет?
	Ответить | Правка | ^ к родителю #535 | Наверх | Cообщить модератору

	539. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 09:03
	>>Диверсити защищает, гранты пилит. Тяжёлого не поднимает, работа в тепле. > Но это же скучно, разве нет? Думаю, им (тяжело) работать скучно. ))
	Ответить | Правка | ^ к родителю #536 | Наверх | Cообщить модератору

	542. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 09:34
	>>>Диверсити защищает, гранты пилит. Тяжёлого не поднимает, работа в тепле. >> Но это же скучно, разве нет? > Думаю, им (тяжело) работать скучно. )) Похоже им вообще работать скучно. Неохипаны. Сметёт  жизнь людей, называющих себя хипстерами, "Экологами", "феменистками" вместе с их показными добротой и отзывчивостью, которыми они прикрывают свой крайний гедонизм. "Мне удобна!.." и губки сложить в куриную гузку. Лет через 50 и следа не останется.
	Ответить | Правка | ^ к родителю #539 | Наверх | Cообщить модератору

	544. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 09:48
	>>>>Диверсити защищает, гранты пилит. Тяжёлого не поднимает, работа в тепле. >>> Но это же скучно, разве нет? >> Думаю, им (тяжело) работать скучно. )) > Похоже им вообще работать скучно. Неохипаны. Сметёт  жизнь людей, ... > Лет через 50 и следа не останется. Новые появятся. ))
	Ответить | Правка | ^ к родителю #542 | Наверх | Cообщить модератору

	554. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 12:17
	Как появятся, так и уйдут. Кто сейчас помнит т.н. стиляг? А почему не помнят? Потому, что они не оставили ничего после себя, творить им было некогда, нужно было заниматься самолюбованием в своей тусовочке.
	Ответить | Правка | ^ к родителю #544 | Наверх | Cообщить модератору

	557. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 13:37
	> Как появятся, так и уйдут. Кто сейчас помнит т.н. стиляг? А почему > не помнят? Потому, что они не оставили ничего после себя, творить > им было некогда, нужно было заниматься самолюбованием в своей тусовочке. Прежних дармоедов помнят современные. Иногда даже снимают о них лестное кино. ))
	Ответить | Правка | ^ к родителю #554 | Наверх | Cообщить модератору

	567. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 16:02
	>> Как появятся, так и уйдут. Кто сейчас помнит т.н. стиляг? А почему >> не помнят? Потому, что они не оставили ничего после себя, творить >> им было некогда, нужно было заниматься самолюбованием в своей тусовочке. > Прежних дармоедов помнят современные. Иногда даже снимают о них лестное кино. )) Ты про (сейчас уже давнее) УГ "Стиляги"? Так снимали они сами или их дети, причём в гротескной форме, получилось УГ. Даже заманавшую одно время всех "Карнавальную  ночь" можно пересматривать. А "стиляг" будут пересматривать 1.5 анонимуса. Людей конечно можно накормить этим самым...но они довольно быстро понимают, что это не пчёлы, а то, чем их кормят не мёд.
	Ответить | Правка | ^ к родителю #557 | Наверх | Cообщить модератору

	242. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 15:00
	> Если то, что я прочитал в интервью не идиотизм, то что тогда идиотизм? Ты ничего не понимаешь в жизни, чувак. У Project Manager'а несколько иное видение мира чем у рядового кодераса. Project Manager - не о том чтобы сделать максимально эффективно любой ценой. Он о разумной балансировке разных свойств проекта.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	333. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от псевдонимус (?), 13-Дек-18, 20:29
	>Project Manager' Зачем сразу матом?
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	396. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 14-Дек-18, 15:06
	> Зачем сразу матом? Ну вот поскольку для тебя это мат - твое айти и находится в состоянии "насколько лет отстала", если кто не понял ;). Без вот таких вот чувачков - ничего не получается. Если на такой роли окажется головотяп, проект будет слит даже с толпой лучших программистов и отличным финансированием.
	Ответить | Правка | ^ к родителю #333 | Наверх | Cообщить модератору

	400. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 15:33
	>> Зачем сразу матом? > Ну вот поскольку для тебя это мат - твое айти и находится > в состоянии "насколько лет отстала", если кто не понял ;). Без > вот таких вот чувачков - ничего не получается. Если на такой > роли окажется головотяп, проект будет слит даже с толпой лучших программистов > и отличным финансированием. Зато, с другой стороны, усилиями таких прогрессоров, как ты, скоро останется 1 (прописью: одна) операционная система, не испорченная прогрессом в интересах одноклеточных девляпсов. Тебе интересно узнать её имя? Называю: OpenBSD. Нет, ты не сможешь её исправить и улучшить, к счастью.
	Ответить | Правка | ^ к родителю #396 | Наверх | Cообщить модератору

	451. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 15:19
	> Зато, с другой стороны, усилиями таких прогрессоров, как ты, скоро останется 1 > (прописью: одна) операционная система, не испорченная прогрессом в интересах одноклеточных Я себя одноклеточным не считаю, однако некоторые мои цели, интересы и задачи, внезапно, могут быть и не ортогональны задачам хомяков. Ну вот например, FullHD видео без тиринга я с удовольствием посмотрю, имхо. И мелкие компьютеры с полкредитки - мне нравятся. Но все это не про Тео и его операционку. А умничать о правильных концепциях из NT6 - мне обломно, да. > девляпсов. Тебе интересно узнать её имя? Называю: OpenBSD. Нет, ты не > сможешь её исправить и улучшить, к счастью. Да я и не рвусь особо. Чего я там забыл? Но понимаешь в чем отличие? Я то еще и жру свое г@вно сам. А вот ты - расхваливаешь опенбсд, сидючи под NT6-что-то-там. Таки уже основательно испорченной под одноклеточных. И вот в этом месте я в моем праве посчитать сэра позером и лицемером, как мне кажется. Вместе с его концепциями и вэями, которые на практике не работают даже для самого сэра. Так что сэр пытается работать работы чужими руками и указывать другим как им должно быть удобно. А вот на такое у нас есть чудный -EPERM в кармане.
	Ответить | Правка | ^ к родителю #400 | Наверх | Cообщить модератору

	461. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 19:25
	>> > -EPERM в кармане. Это не карман, снова ты карман со своим задом перепутал. > Я то еще и жру свое г@вно сам. То, что ты его ешь было заметно и раньше, 294-й. Теперь и других накормить пытаешься >Вместе с его концепциями и вэями Естественно у людей вроде тебя ни концепции, ни "вэя". Нет пути в общем.
	Ответить | Правка | ^ к родителю #451 | Наверх | Cообщить модератору

	464. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (464), 15-Дек-18, 20:24
	> Это не карман, снова ты карман со своим задом перепутал. Какой-то непредусмотрительный тип попался. С запахом адресату будет доходчивее, спору нет ;) > других накормить пытаешься Только тех кто сам того желает. Если кто готов делать быстрее, лучше, дешевле и все такое - так я ж разве против? Но ветеран-юникс-балаболы умеют только рассказывать как надо. А решать фактические проблемы тех или иных человеков, здесь и сейчас - это не к ним, они там в свои вэйности играются, поэтому как максимум умеют орать про RTFM и руки. Собственно псинодевы по этой причине и вылупились - надоело тем кто платит за банкет подобное шоу. И теперь будет вот так. В моем случае будет несколько иначе, но кой-какие подходы псинодевов зарекомендовали себя рациональными и эффективными, хорошо экономя время и силы. > Естественно у людей вроде тебя ни концепции, ни "вэя". Нет пути в общем. У меня есть путь. И это не путь камлания на архаичные подходы, когда они перестали для меня и клиентов нормально работать. Со времен древнего юникса мир немного изменился. И теперь появилось много других применений компьютеров. Да и в существующих приоритеты, цели и методы здорово подвинулись. И лично я не собираюсь игнорить очевидные факты. Даже если какие-то погонщики майнфреймообразных мамонтов так и привыкли.
	Ответить | Правка | ^ к родителю #461 | Наверх | Cообщить модератору

	470. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 21:01
	>А решать фактические проблем Ты их решаешь на минутку, а создаёшь на час. >Собственно псинодевы по этой причине и вылупились - надоело тем кто платит за банкет подобное шоу. И теперь будет вот так. В моем случае будет несколько иначе, но кой-какие подходы псинодевов зарекомендовали себя рациональными и эффективными, хорошо экономя время и силы. Они появились, как и знаменитый агила-подход, чтобы оправдать продажу не нужного и починку не сломанного. >И теперь появилось много других применений компьютеров. Не появилось. >майнфрейм Вот это было правильно. Но дорого.
	Ответить | Правка | ^ к родителю #464 | Наверх | Cообщить модератору

	512. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (512), 16-Дек-18, 20:55
	> Ты их решаешь на минутку, а создаёшь на час. А вот тут уже клиент решает. Если по его мнению это так - мы не находим общий язык и он идет платить денег другому. А я занимаюсь задачами другого клиента. Но вообще-то в моих интересах - чтобы клиенту было сухо и комфортно и чтобы он меня потом отрекламил сарафанным радио. Поэтому на самом деле клиент может расчитвать на best effort по избежанию таких ситуаций. > Они появились, как и знаменитый агила-подход, чтобы оправдать продажу не нужного и > починку не сломанного. Agile - это проприетарщикам стало завидно как у опенсорсников все работает и они пытаются косить под это. Получается погано, потому что заинтересованность корпоративных винтиков в результате работинга и близко не стояла с опенсорсной командой, так что имитации бурной деятельности больше чем фактического результата. > Не появилось. Я с этим не согласен - майнфреймообразные применения компьютеров меня так например вообще совсем не интересуют. > Вот это было правильно. Но дорого. Ну так кому правильно - тому и карты в руки. А мне вот нравятся штуки с половину кредитки. С ними у меня получается прикольная системная магия, которая нравится моим клиентам.
	Ответить | Правка | ^ к родителю #470 | Наверх | Cообщить модератору

	528. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 07:14
	>А вот тут уже клиент решает. Если по его мнению это так - мы не находим общий язык и он идет платить денег другому. Психология не творца, но мелкого барыги проявилась ещё ярче. Клиент может быть не компетентен( ну я понимаю, что тебе ...) >Agile - это проприетарщикам стало завидно как у опенсорсников все работает и они пытаются косить под это. Получается погано, потому что заинтересованность корпоративных винтиков в результате работинга и близко не стояла с опенсорсной командой, так что имитации бурной деятельности больше чем фактического результата. Опенсорс именно корпоративно-коммерческая (в отличие от фрисофтвар) идея. Важно, чтобы винтик не знал, что он винтик. И ножки тимбыдлинга оттуда же растут. >Я с этим не согласен - майнфреймообразные применения компьютеров меня так например вообще совсем не интересуют. Ты лучше не мейнфреймы критикуй, а примеры "новых задач для компьютеров" приведи. >прикольная системная магия, >магия Прошу обратить внимание потенциальных клиентов на это слово. Держитесь подальше от таких деятелей, что применяют слово "магия" к техническим решениям в положительном ключе. Они вам наколдуют.
	Ответить | Правка | ^ к родителю #512 | Наверх | Cообщить модератору

	472. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 15-Дек-18, 21:11
	То есть кроме пустого балабольства тебе сказать совершенно нечего. ОК, благодарим за невероятно плодотворное участие в дискуссии. Как всегда, ничего нового.
	Ответить | Правка | ^ к родителю #451 | Наверх | Cообщить модератору

	513. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (512), 16-Дек-18, 20:59
	КГБшник, это ж и про тебя можно сказать. Думаешь чего твои мессаги так грохают модеры? С точки зрения окружающих - окружающие мало что теряют от отсутствия твоего самолюбования. Это и моего самолюбования касается. Другое дело что я пытаюсь аргументировать свою точку зрения, почему это для меня хорошо работает. Так что все желающие могут оценить аргументацию, да и сами попробовать - а лучше ли для них. А ты просто нахрапом прешь "так привыкли". Этим мы и отличаемся. Надеюсь что я не стану выглядеть вот так к моей старости - очень уж не хочется таким отработанным материальцем стать.
	Ответить | Правка | ^ к родителю #472 | Наверх | Cообщить модератору

	545. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 09:55
	>почему это для меня хорошо работает Для тебя. Не приходило в голову, что "для меня" и "для всех" несколько разные понятия? Хотя о чём я спрашиваю,для тебя есть только Великий 294-й и покупатели. А, ещё есть ненавистные старпёры, мешающие "прогрессу".
	Ответить | Правка | ^ к родителю #513 | Наверх | Cообщить модератору

	543. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 09:46
	> То есть кроме пустого балабольства тебе сказать совершенно нечего. ОК, благодарим за > невероятно плодотворное участие в дискуссии. Как всегда, ничего нового. Стабильность признак мастерства (не помню кто). Парень мастер по демагогии.
	Ответить | Правка | ^ к родителю #472 | Наверх | Cообщить модератору

	549. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 17-Дек-18, 11:01
	Ага. Я его уже за комсорга признал. :)
	Ответить | Правка | ^ к родителю #543 | Наверх | Cообщить модератору

	425. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 14-Дек-18, 22:30
	Продолжай утешать себя. Обосновывай важность проституции и жульничества. Но ведь в глубине души ты понимаешь, что проституция и жульничество остаются таковыми, в какую обёртку их не заверни.
	Ответить | Правка | ^ к родителю #396 | Наверх | Cообщить модератору

	427. "(offtopic) проекты, манагеры, обёртки -- и опять же п.10"	–1 +/–
	Сообщение от Michael Shigorin (ok), 14-Дек-18, 22:42
	> Обосновывай важность проституции и жульничества. Дорогой Ильич (по большей части про первого сейчас, конечно) был проституткой, жуликом или всё-таки и тем и другим?  А внедрявшая метод проектов мадам Крупская кем была?..
	Ответить | Правка | ^ к родителю #425 | Наверх | Cообщить модератору

	430. "(offtopic) проекты, манагеры, обёртки -- и опять же п.10"	+/–
	Сообщение от псевдонимус (?), 14-Дек-18, 22:57
	>> Обосновывай важность проституции и жульничества. > Дорогой Ильич (по большей части про первого сейчас, конечно) был проституткой, жуликом > или всё-таки и тем и другим?  А внедрявшая метод проектов > мадам Крупская кем была?.. Я понимаю, то ты ненавидишь камуняков не меньше, чем ненавидимые тобою бандеровцы. Но всё же не плохо подкреплять такие сильные утверждения в отношении исторических личностей фактами.
	Ответить | Правка | ^ к родителю #427 | Наверх | Cообщить модератору

	550. "(offtopic) проекты, манагеры, обёртки -- и опять же п.10"	+/–
	Сообщение от пох (?), 17-Дек-18, 11:10
	> Дорогой Ильич (по большей части про первого сейчас, конечно) был проституткой, жуликом > или всё-таки и тем и другим?  А внедрявшая метод проектов > мадам Крупская кем была?.. мадам, похоже, по всплывшим недавно данным, подделала пресловутое "письмо к съезду", и не только его. Что сразу же объясняет некоторые кажущиеся несуразности их семейного бытия и ставит мадам на совсем другой уровень и претензий, и возможностей. Недооценили в свое время Наденьку, видимо.
	Ответить | Правка | ^ к родителю #427 | Наверх | Cообщить модератору

	560. "(offtopic) проекты, манагеры, обёртки -- и опять же п.10"	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 13:57
	>> Дорогой Ильич (по большей части про первого сейчас, конечно) был проституткой, жуликом >> или всё-таки и тем и другим?  А внедрявшая метод проектов >> мадам Крупская кем была?.. > мадам, похоже, по всплывшим недавно данным, подделала пресловутое "письмо к съезду", и > не только его. > Что сразу же объясняет некоторые кажущиеся несуразности их семейного бытия и ставит > мадам на совсем другой уровень и претензий, и возможностей. Недооценили в > свое время Наденьку, видимо. Неплохо бы ссылку или ключевую фразу для гуглежа. А так Ленин гений. Добрый гений. Чем они там с Крупской занимались не представляет научного интереса.
	Ответить | Правка | ^ к родителю #550 | Наверх | Cообщить модератору

	452. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 15:26
	> Продолжай утешать себя. Обосновывай важность проституции и жульничества. А что не проституция и не жульничество? Подметание ломом плаца, когда все уже даже забыли зачем они тут и для чего это надо? Очень сомнительно что это - лучше. >  Но ведь в глубине души ты понимаешь, что проституция и жульничество остаются таковыми, > в какую обёртку их не заверни. PM-ы как таковые - привносят в проект сбалансированное видение, позволяя решить практически значимые задачи с ограниченными ресурсами в разумные сроки. В виде когда это решение потом еще кому-нибудь и надо. Кроме всего прочего - я вот вижу что господа титиретики умеют совершенно волшебно страдать фигней буквально годами, убивая прорву человекочасов на какую-то непртребную активность с нулевым или минимальным результатом. И когда так 1 человек только свое время грохает - да это его право ломом плац подметать. При условии что он не требует за это денег с других и как-то добывает ресурсы на свое существование при этом. А когда этим начинает заниматься какая-то крупная структура, вот это уже довольно хреново. Потому что пачка дармоедов, страдающих фигней за чужой счет, не приносящих пользы окружающим, если назвать вещи своими именами.
	Ответить | Правка | ^ к родителю #425 | Наверх | Cообщить модератору

	460. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 19:00
	>PM-ы как таковые - привносят в проект сбалансированное видение, позволяя решить практически значимые задачи с ограниченными ресурсами в разумные сроки. Это в технике называется генеральный конструктор или ведущий инженер. И он должен шарить. Не надо гражданских министров обороны, до назначения даже плац видевших только по телику, зато имеющих "экономическое образование". >умеют совершенно волшебно страдать фигней буквально годами, убивая прорву человекочасов на какую-то непртребную активность с нулевым или минимальным результатом. Ты прямо целую плеяду руками водителей описал, PM только малая их часть. Как же надоели чудаки на другую букву, "знающие теорию управления". Они правда считают, что могут управлять чем угодно.
	Ответить | Правка | ^ к родителю #452 | Наверх | Cообщить модератору

	465. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 20:34
	> Это в технике называется генеральный конструктор или ведущий инженер. Вот ВЫ и пользуйтесь техникой от "ведущих инженеров" и "генеральных конструкторов" как по мне. Особенно - компьютерами. А я как-нибудь пешком постою и буду учиться у PMов. Это для меня лучше работает. > И он должен шарить. Не надо гражданских министров обороны, до назначения даже плац видевших > только по телику, зато имеющих "экономическое образование". А я тут каким боком? Я не министр обороны, да и вообще, не фанат Урфина Джюса и его деревянных. Так что если у них будут разработки сделанные Генеральными Конструкторами - да и хрен с ними, они привычные. Им скажут таскать этот хлам - пойдут таскать этот хлам. > Ты прямо целую плеяду руками водителей описал, PM только малая их часть. PMы это характерный подвид, встречающийся в софтварной и теперь слегка в хардварной отрасли. Но это вообще другой уровень инженерии. > Как же надоели чудаки на другую букву, "знающие теорию управления". Они > правда считают, что могут управлять чем угодно. Ну я для начала учусь более или менее управлять самим собой. Поскольку с голода не помер - значит более или менее получается.
	Ответить | Правка | ^ к родителю #460 | Наверх | Cообщить модератору

	473. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от псевдонимус (?), 15-Дек-18, 21:29
	>> Это в технике называется генеральный конструктор или ведущий инженер. >  А я как-нибудь пешком постою и > буду учиться у PMов. Это для меня лучше работает. Тебе не нужно, ты уже научился в уши дуть и делать презентации. >> И он должен шарить. Не надо гражданских министров обороны, до назначения даже плац видевших >> только по телику, зато имеющих "экономическое образование". > А я тут каким боком? Я не министр обороны, да и вообще, > не фанат Урфина Джюса и его деревянных. Так что если у > них будут разработки сделанные Генеральными Конструкторами - да и хрен с > ними, они привычные. Им скажут таскать этот хлам - пойдут таскать > этот хлам. Поражает глубина твоих познаний. >> Ты прямо целую плеяду руками водителей описал, PM только малая их часть. > теперь слегка в хардварной Вот это действительно грозит катастрофой. >> Как же надоели чудаки на другую букву, "знающие теорию управления". Они >> правда считают, что могут управлять чем угодно. > Ну я для начала учусь более или менее управлять самим собой. Поскольку > с голода не помер - значит более или менее получается. Это тебе к буддистам.
	Ответить | Правка | ^ к родителю #465 | Наверх | Cообщить модератору

	516. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 22:15
	> Тебе не нужно, Я не маркетолог, так что нужно. > ты уже научился в уши дуть и делать презентации. "Когда человек не может объяснить чем он занимается домохозяйке - он и сам не знает чем он занимается". Резерфорд, чтоли. Так что совсем уж без этого не катит. Иначе получается толпа страдальцев фигней, забывших за что им деньги платят. > Поражает глубина твоих познаний. Так это, я электроникой и схемотехникой интересуюсь довольно давно, у меня в детстве любимые книжки специфичные были. Так что оценить уровень разработок я могу. > Вот это действительно грозит катастрофой. О да, это катастрофа. Для ископаемых, которые станут столь же "нужны" как СССРовские токари цатого разряда, вместе с глупыми станками. Мир изменится. Уже изменяется. Этот процесс не остановится, он начался еще в 80х прошлого века, его путь лежит в бесконечность возможностей. > Это тебе к буддистам. У каждого свой путь. У меня чуть иной путь чем у буддистов.
	Ответить | Правка | ^ к родителю #473 | Наверх | Cообщить модератору

	529. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 17-Дек-18, 07:24
	>у меня в детстве любимые книжки специфичные были Ну так можно уже было перерасти их. >"Когда человек не может объяснить чем он занимается домохозяйке - он и сам не знает чем он занимается". Почему же ты не хочешь объяснить, чем занимаешься? >токари цатого разряда, Открой газету с вакансиями. > Мир изменится. Уже изменяется. Видимо поэтому уровень автоматизации практически не растёт, а ведь заводами-автоматами грезили ещё в 50-х...
	Ответить | Правка | ^ к родителю #516 | Наверх | Cообщить модератору

	13. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–13 +/–
	Сообщение от Аноним (-), 12-Дек-18, 23:10
	Ваши слова только ваш уровень нравственного развития демонстрируют.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	17. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+7 +/–
	Сообщение от Аноним (17), 12-Дек-18, 23:21
	> Ваши слова только ваш уровень нравственного развития демонстрируют. И он кстати достаточно высок. Плюсанул ему.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	69. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–9 +/–
	Сообщение от fske (?), 13-Дек-18, 01:25
	Такой же, как и твой - чуть выше плинтуса.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	43. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+7 +/–
	Сообщение от Anonim (??), 13-Дек-18, 00:25
	Давай не офтопить. Вот конкретно ты используешь x32? Ты пересобрал под него, не знаю, хромиум? Или firefox? И как, работает? Намного ли стал меньше жрать памяти? Бесноватые были во все времена. И в основном им нужно внимание. И вставляя про них упоминания, ты лишь им помогаешь.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	51. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 00:40
	Я использую 32-разрядные (они давно все с поддержкой PAE) или 64-разрядные операционные системы на соответствующем железе и, по возможности, 32-разрядные программы в этих 32- или 64-разрядных операционных системах. Никакому прикладному софту обычного юзера ни для чего не нужно уметь адресовать много памяти. При прочих равных 32-разрядный софт почти всегда лучше, быстрее и экономнее для ресурсов. Я никак не могу представить себе, для чего, например, браузеру, мультимедийному проигрывателю, табличному процессору или текстовому редактору быть 64-битными. Если ты можешь назвать конкретные выгоды — назови.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	72. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от fske (?), 13-Дек-18, 01:29
	>При прочих равных 32-разрядный софт почти всегда лучше, быстрее и экономнее для ресурсов. Результаты проведенного тестирования товарища аналитика как всегда искать в гугле или он соизволить свой пук в лужу аргументировать?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	78. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от Аноним (78), 13-Дек-18, 02:01
	Не, не соизволитъ. Он просто немного рассказал о том, что он там использует. Думая, что это кому-то интересно.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	244. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (243), 13-Дек-18, 15:05
	> Не, не соизволитъ. Он просто немного рассказал о том, что он там > использует. Думая, что это кому-то интересно. Так и пусть себе использует. И майнтайнит свой зоопарк сам, если других желающих это делать не найдется. У меня вот последних лет 10 - насквозь 64-битная система на основных комапх. Зато программы могут mmap()-ать любые файлы, а графический редактор не упадет по глупой причине если я открою там даже огроменную картинку. И это все же хорошо.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	123. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Анонимный прохожий (?), 13-Дек-18, 07:15
	> При прочих равных 32-разрядный софт почти всегда лучше, быстрее и экономнее для ресурсов А что не 16-разрядный?  Будет ещё экономичнее и быстрее.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	134. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–6 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 07:57
	Не будет. 32-битный софт при прочих равных быстрее 16-битного. И быстрее 64-битного.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	150. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+4 +/–
	Сообщение от Аноним (150), 13-Дек-18, 08:55
	Вернёмся к этому вопросу в 38-ом году.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	155. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 09:15
	> Вернёмся к этому вопросу в 38-ом году. Что должно произойти в 38 году? «Часы сломаются»? Это не страшно. И это на самом деле не зависит от адресации памяти. Можно «новую эпоху» открывать хоть каждые десять лет. Просто для удобства выбирают какие-то отправные даты и затем «ради обратной совместимости» морочат себе и людям головы. Это на самом деле не проблема. Открою, кстати, маленькую большую тайну: 64-битная архитектура x86 на самом деле не использует 64-разрядную адресацию. Вот и стоило затевать всю эту канитель? Польза ведь только для Большого Железа.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	246. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (243), 13-Дек-18, 15:07
	Поскольку вгрузить в оперативу более 4 гигз одним чихом и работсть с этим можно - стоило. А то что 640 кило хватит всем - вот кому хватит, тот пусть и пользуется 640 кило.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	263. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 15:56
	> Поскольку вгрузить в оперативу более 4 гигз одним чихом и работсть с > этим можно - стоило. А то что 640 кило хватит всем > - вот кому хватит, тот пусть и пользуется 640 кило. Вгрузить в оперативку более 4 гигов одним чихом можно было и раньше — при помощи PAE. Открою тебе страшную тайну: и больше можно было, если ещё увеличить разрядность адресации. Сколько угодно много можно, если на то пошло. Ограничение в 4 гига — это ограничение для _одной программы_. Его обойти в 32-битной архитектуре не получится, да. А надо? А точно-точно надо? Ты не сумеешь обосновать необходимость этого, поскольку в реальности не существует рациональной аргументации за это. Нет, жирные регистры можно и без всеобъемлющего перехода на 64 бита (более того, можно удвоить и учетверить жирность их, если очень надо). Да, адресовать много памяти можно и без всеобъемлющего перехода на 64 бита. Смысл 64 битов только в общем адресном пространстве для архитектуры, и более ни в чём. Ну и в типа согласовании. Внутри себя это смесь «разноразрядных» устройств и технологий. И даже та AMD64, которую ты здесь нахваливаешь, не понимая, что она есть такое, имеет на самом деле меньшую (внезапно!) разрядность адресации памяти. Просто потому, что не надо никому так много памяти в настоящее время. Чтоб ты лучше понял суть сказанного, AMD64 — это такая PAE наоборот, когда отсчитывают от большего, а не от меньшего. Ну и плюс несколько новых 64-битных плюшек. Маркетинг и разводилово в лучшем виде.
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	271. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (-), 13-Дек-18, 16:22
	> Вгрузить в оперативку более 4 гигов одним чихом можно было и раньше — при > помощи PAE. Вот знаешь что, давай ты такой умный этим и пользуйся. А я таки буду использовать линейные моделди адресных пространств в стиле фон-неймана. Потому что это удобно, и ниипет. И поэтому вон тот редактор графики (любой!) спокойно сожрет даже какой-нибудь скан A0 в диком разрешении не поперхнувшись. Если в системе в принципе есть достаточно оперативы. И наверное это - хорошо и правильно. А у тебя с твоими разглагольствованиями редактор тупо грохнется когда ему адресного пространства не хватит. И таки вгрузить картинку в память и что-то сделать с ее пикселями - это таки самый простой и логичный способ. Все остальное намного сложнее, медленнее и требует нефиговый объем нетривиального кода, который по сути попытается изобрести нечто типа свопфайлов, только через задний проход и без явной поддержки железом. Потому что в железо программы ща вообще не пускают и именно в настоящий HW-assisted paging подпертый MMU они еще и не вклинятся. Во избежание поимения всей системы. > Открою тебе страшную тайну: и больше можно было, если ещё увеличить разрядность адресации. Это напоминает мне ту городскую легенду, где чувак посмотрел что можно выжать из его древнего драндулета, если стырить пороховой ускоритель... > Ограничение в 4 гига — это ограничение для _одной программы_. Его обойти > в 32-битной архитектуре не получится, да. А надо? Да, надо. А почему, собственно, я не должен иметь возможность открыть БОЛЬШУЮ картинку в редакторе, например? Или еще что-то большое в память загнать целиком и поработать с этим со скоростью RAM, а не винча? Это как бы на несколько порядков разница по производительности. И мне видится очень тупым что я не могу адресовать всю оперативку одним линейным куском. Доступным одним куском а не лоскутным одеялом в куче процессов, если так удобнее и результативнее. > Ты не сумеешь обосновать необходимость этого, поскольку в реальности не существует > рациональной аргументации за это. Уже обосновал. А все эти PAE как по мне должны сдохнуть жестокой смертью, как самые извращенские костыли которые я когда либо видел. Это просто е...й стыд системной архитектуры. Впрочем у интеля в IA32 такого вообще есть. > имеет на самом деле меньшую (внезапно!) разрядность адресации памяти. Она имеет достаточную адресацию памяти для того чтобы отдать мне ВСЮ установленную в компе оперативу одним куском в моей программе, если мне что-то такое вдруг надо.
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

	282. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:02
	> Вот знаешь что, давай ты такой умный этим и пользуйся. А я таки буду использовать линейные моделди адресных пространств в стиле фон-неймана. Потому что это удобно, и ниипет. И поэтому вон тот редактор графики (любой!) спокойно сожрет даже какой-нибудь скан A0 в диком разрешении не поперхнувшись. Если в системе в принципе есть достаточно оперативы. И наверное это - хорошо и правильно. Я с год назад, кажется, приводил на этом форуме в пример сравнительно успешную работу старинного Фотошопа версии 5.5 с громадной картинкой размером 20000 х 20000 точек. Полноценной работой это, конечно, не назовешь, но тут дело принципа. 32-битный графический редактор способен схарчить и переварить такое файло. На большее в него захардкодили ограничения, ЕМНИП. Да, и я бы предпочел в качестве ПК компьютер Гарвардской архитектуры. Не делают-с, увы. > А у тебя с твоими разглагольствованиями редактор тупо грохнется когда ему адресного пространства не хватит. И таки вгрузить картинку в память и что-то сделать с ее пикселями - это таки самый простой и логичный способ. Все остальное намного сложнее, медленнее и требует нефиговый объем нетривиального кода, который по сути попытается изобрести нечто типа свопфайлов, только через задний проход и без явной поддержки железом. Потому что в железо программы ща вообще не пускают и именно в настоящий HW-assisted paging подпертый MMU они еще и не вклинятся. Во избежание поимения всей системы. Обходить ограничения научились ещё в допотопные времена работой с памятью через окошко (потому-то людям с прямыми руками и не требуются на самом деле колоссальные объёмы памяти и большая разрядность адресации). Ты что, до сих пор не в курсе? Чувак, я потрясён! :) > Это напоминает мне ту городскую легенду, где чувак посмотрел что можно выжать из его древнего драндулета, если стырить пороховой ускоритель... Загугли же наконец про то, что такое виртуальная память. > Да, надо. А почему, собственно, я не должен иметь возможность открыть БОЛЬШУЮ картинку в редакторе, например? Или еще что-то большое в память загнать целиком и поработать с этим со скоростью RAM, а не винча? Это как бы на несколько порядков разница по производительности. И мне видится очень тупым что я не могу адресовать всю оперативку одним линейным куском. Доступным одним куском а не лоскутным одеялом в куче процессов, если так удобнее и результативнее. Если руки не из нижней части спины, то это всё не обязательно. Как быстро вы все забыли, что ещё каких-то двадцать лет назад суперкомпьютеры имели сопоставимые с нынешними ПК вычислительные мощности, но при этом на них успешно выполнялись задачи для суперкомпьютеров, а на нынешних супер-ПК Ворд тормозит так же, как и тогда тормозил. > Уже обосновал. А все эти PAE как по мне должны сдохнуть жестокой смертью, как самые извращенские костыли которые я когда либо видел. Это просто е...й стыд системной архитектуры. Впрочем у интеля в IA32 такого вообще есть. То есть ты не осознаёшь, что AMD64 + EM64T — это тоже набор костылей, «расширенный и улучшенный»? Ну и замечательно, только с этого и надо было начинать, я бы не тратил своё время на чтение твоих графоманских простыней. :)
	Ответить | Правка | ^ к родителю #271 | Наверх | Cообщить модератору

	293. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 17:41
	> успешную работу старинного Фотошопа версии 5.5 с громадной картинкой размером 20000 > х 20000 точек. Полноценной работой это, конечно, не назовешь, Ну а вот у меня NASAвская картинка на 300, если не ошибаюсь, мегапикселей - нормально открылась. Без вот этих вот оговорочек про полноценную работу. И вот так мне почему-то больше нравится. > но тут дело принципа. У меня простой принцип: компьютеры должны работать, а не канифолить мозг. И когда я не могу просто взять и просто воспользоваться всей оперативкой которую я установил, без дурных условий и оговорок - клятая железка греет мне мозг и это очков симпатий ей совсем не добавляет. > На большее в него захардкодили ограничения, ЕМНИП. Ну так юзер иначе повесится от такой "работы", когда аналог paging все время будет диском тарахтеть. В то время как половина оперативы компа не используется. Очень умно и эффективно. > Да, и я бы предпочел в качестве ПК компьютер Гарвардской архитектуры. Не > делают-с, увы. Програмить канительно. Кто не верит - ну вон атмеги и аттини есть. На них даже си натянули худо-бедно. И даже плюсы слегка. Но вот именно гарвардская природа таки основательно канифолит мозг и требует отдельных приседаний. ARM например умнее сделал - "электрически" у них ядро гарвардец. I и D шины - электрически разные. Поэтому оно может одновременно тащить инструкции и данные для них - по разным шинам. Одновременно. Но для софта это таки вывешено как фоннейман и програмить это все же не так геморно как настоящего гарвардца. > колоссальные объёмы памяти и большая разрядность адресации). Ты что, до сих > пор не в курсе? Чувак, я потрясён! :) Я в курсе что можно самому изобрести эрзац-своп и эрзац-mmu. Там вон чуваки на атмеге убунту забутявили - сэмулировав ARMv5 с MMU :D. Есть только одна проблема - они загрузки системы в минимальном виде ждали 2 часа, чтоли, а работа с шеллом больше смахивала на пошаговую стратегию - ваш ход, вы жмете букву. Ход переходит к AI, он обдумавает ваш ход минуту :) > Загугли же наконец про то, что такое виртуальная память. Я в курсе, спасибо. И на системном уровне это рюхается ядром и MMU. В которые user-mode софт в общем случае лучше не пускать, иначе расхакают всю систему вдрызг. Я также насмотрелся на всякие банки, окошки и проч. Достаточно для того чтобы возненавидеть все это и полюбить линейную адресацию и memory-mapped периферию. Потому что это просто, быстро, эффективно и не грызет мозг, в отличие от камасутры с переключениями банков, окошек, эрзацсвопов и прочей гадостью, заставляющей костылить убогость железа в софте. > Если руки не из нижней части спины, то это всё не обязательно. Ну как бы с точки зрения скорости работы и минимального объема кода, минимума глюков и проч - это самый простой и логичный вариант. > успешно выполнялись задачи для суперкомпьютеров, а на нынешних супер-ПК Ворд тормозит > так же, как и тогда тормозил. Я рад за суперкомпьютеры но у меня нет суперкомпьютерных задач. И таки вот конкретно мой компьютер таки не особо тормозит. Он достаточно мощный для того чтобы я его так по грубому завалить работами мог только весьма эпизодически. Ну ок, полный ребилд с ноля кернела со всеми наворотами в 8 потоков займет его на ~15 минут. Частичный или более скромную конфигу - меньше. А обычные задачи - блин у меня свопа то нет. Чтобы не наслаждаться латенси от paging. Ну zram вон есть, на случай если приперло. В него cold добро можно отгрузить компресанутым, если приперло. Но RAM, даже компреснутый и косящий под swap - не идет ни в какое сравнение с латенси винча :) > То есть ты не осознаёшь, что AMD64 + EM64T — это тоже набор костылей, То-есть я отлично осознаю что это набор костылей и далеко не предел мечтаний. Но это лучше чем IA32 и всякие PAE. А чего-то недорогого и сильно лучше пока особо и нет. Ну вот ARM еще появляются, да RISC-V на подходе. У ARM ядра в целом менее кривые, но при переходе 32 -> 64 они тоже ессно совместимостью с легаси обвесились. Без этого их порвут. RISC-V ... ну его в 32-битной инкарнации в штуках способных запустить linux никто не видел, так что там они могут и не париться :) но это лишь потому что они стартанули после начала заката 32-бит эпохи.
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

	355. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 01:51
	Ещё о Фотошопах. Photoshop 7 позволяет создать картинку размером 30000 на 30000 точек, то есть 900 мегапукселей. Её пустой стартовый вес — 2,51 ГБ. Photoshop CS позволяет создать картинку размером 300000 на 300000 точек, то есть 90000 мегапикселей. Стартовый вес пустого файла обещают нам аж в 251,5 ГБ. Достаточно или надо ещё? ;-) Дальнейших изысканий с последующими версиями я не проводил, ибо мне таки достаточно. Обращаю внимание твоё и всех адептов прогрессивной математики, что это 32-разрядные программы.
	Ответить | Правка | ^ к родителю #293 | Наверх | Cообщить модератору

	397. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 14-Дек-18, 15:14
	> Photoshop 7 позволяет создать картинку размером 30000 на 30000 точек, то есть > 900 мегапукселей. Её пустой стартовый вес — 2,51 ГБ. ...и когда у меня в системе есть 16 гигз памяти, невозможность линейно адресовать всего-то 2.5 гигза (для кернела тоже надо адреса) - не находит понимания. Еще более иди0тски, когда прога тарахтит винчом экономя адресное пространство :D :D :D в то время как большая часть оперативы пустует. Циферок, блин, в математике не хватило. Волшебно. > Photoshop CS позволяет создать картинку размером 300000 на 300000 точек, то есть > 90000 мегапикселей. Стартовый вес пустого файла обещают нам аж в 251,5 ГБ. И это прекрасно. Но без 64 битов он не сможет держать его одним куском в памяти и эффективно с ним работать. А свопить на диск даже "всего-то" 2.5 гига - это ты как-нибудь без меня. Поттому что SSD при такой "работе" тормозить будет, конечно, умерерно, но протрется довольно быстро. А на винче - скорость работы будет такой, что на третий день такого работинга захочется послать все к чертям и заняться выращиванием рассады. > Обращаю внимание твоё и всех адептов прогрессивной математики, что это 32-разрядные программы. Спасибо, я видел как фотошоп работает когда он не может держать всю картинку в памяти. Смею заверить, увиденного хватило для того чтобы предоставить эту участь другим.
	Ответить | Правка | ^ к родителю #355 | Наверх | Cообщить модератору

	401. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 15:38
	Прекрасный комментарий, настоящий гимн неэффективности! Даже в совке такого махрового лицемерного трындежа не было. :-) Так ты эмбедовкой занимаешься, говоришь? Ну-ну… Большой привет клиентам! :-)
	Ответить | Правка | ^ к родителю #397 | Наверх | Cообщить модератору

	453. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 15:33
	> Прекрасный комментарий, настоящий гимн неэффективности! Даже в совке такого махрового > лицемерного трындежа не было. :-) Гимн неэффективности - это когда машина хрустит винчом и решает задачу в десятки раз медленнее, вместо того чтобы просто взять и использовать весь свой имеющийся ресурс. > Так ты эмбедовкой занимаешься, говоришь? Ну-ну… Большой привет клиентам! :-) А в эмбедовке все просто: задача или умещается в ресурсы, или нет. И если умещается - то в общем то дальнейшие оптимизации имеют смысл разве что для души и прочих перспектив поюзать этот код потом и на более дохлом хардваре, или под более крутой поток данных, или там что еще. И в эмбедовке только сказочный талпайоп изначально хватает камень, ресурсы которого заведомо впритык. Уж разработка всяко делается на железе с запасом. А потом смотрится - если можно малой кровью обрубить под более хилую железку, это проносит какие-то профиты и не тормозит проект на годы - ок, может быть. А так еще дедушка Кнут сказал нам что преждевременная оптимизация - корень всех зол. Мы его таки услышали.
	Ответить | Правка | ^ к родителю #401 | Наверх | Cообщить модератору

	403. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (514), 14-Дек-18, 15:49
	> И это прекрасно. Но без 64 битов он не сможет держать его > одним куском в памяти и эффективно с ним работать. Вообще то, эффективнее всего работать не кусками влезающими в оперативку, а с кусочками влезающими в кеш процессора. Насколько я знаю, видео все и всегда обрабатывают как раз такими кусочками.
	Ответить | Правка | ^ к родителю #397 | Наверх | Cообщить модератору

	454. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 15:43
	> Вообще то, эффективнее всего работать не кусками влезающими в оперативку, а с > кусочками влезающими в кеш процессора. Аксиома: если математика несложная, а картинка большая - основное время работы с ней что так что эдак уйдет на выгруз из оперативы источника и вгруз в оперативу результата. Кэш как таковой кэш ничего с этим сделать не может. Ваша мысль имеет право только в допущении что все упирается в процессор, а не оперативку. Но процессоры сейчас быстрые и оперативку обгоняют сильно, по поводу чего и есть кэши. Так что какие-то такие соображения могут иметь смысл только для каких-то очень частных случаев, когда математика применяемая к кускам картинки очень крутая, обращается к пикселам много раз подряд и это - какой-то существенный процент времени по сравнению с IO с оперативой. А если вы жуете всю картинку - то вы ее всю прочтете и запишете в оперативу. Что с кэшом, что без. И таки при лопатинге 2.5 гигз кэш во многих случаях погоды вообще не сделает. Лучшее что там может закешироваться - сам алгоритм, но никак не данные которые он жевал. Да, я развлекался с компрессором данных. И когда у меня source и destination уместились в кэш, на повторных сжатиях и распаковках выигрыш получился офигительный. На однократной профита не наступает - в конечном итоге источник придется взять оперативки, а результат записать в оперативку. Что с кэшом, что без. Куда такой профит прикрутить - я толком и не придумал. Ну, можно бенчмарки накручивать, наверное. Если 7z b меряет 20000 MIPS, то подмухлевав в таком духе можно получить и все 100000 если не больше. Проблема в том что в реальных сценариях это никто не увидит. > Насколько я знаю, видео все и всегда обрабатывают как раз такими кусочками. Хотелось бы пруфца на столь храброе заявление. Желательно в исходниках.
	Ответить | Правка | ^ к родителю #403 | Наверх | Cообщить модератору

	457. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (514), 15-Дек-18, 16:21
	Помимо производительности шины памяти есть так же время запроса. Насколько мне известно кеш второго уровня страничный и если процессор запрашивает данные из страницы которой нет в кеше, то содержимое одной из страниц кеша сбрасывается в оперативку. И только после того как сброс будет полностью завершён будет произведён запрос блока из оперативки. Это операция занимает около 100нс и вообще не ускоряется с появлением нового железа, скорость света будь она не ладна. То есть узким местом будет даже не шина, а пинг до оперативки. Всего 10 млн. операций с памятью в секунду, пентиум-1 умрёт со смеху обрабатывая картинку за тоже время, что и топовый i7.
	Ответить | Правка | ^ к родителю #454 | Наверх | Cообщить модератору

	467. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 20:47
	> Помимо производительности шины памяти есть так же время запроса. Да. Однако RAM сильно отстает и на последовательном доступе, и на рандомном. В случае последовательного, кстати, характерного для работы с изображениями, GPU вообще используют специальные виды памяти. И таки даже GDDR5, не говоря про HBM и проч - очень хорошо показывает DDR3/4 кто в этом рулит. Пример: ПСП DDR3 и GDDR5 примерно сравнимых времен покупки около 20 GB/sec vs 180GB/sec. Разница почти в 9 раз. На именно рандомном доступе так конечно не будет. Но для работы с картинками - последовательный доступ достаточно характерен. Именно рандомно хватать пикселы картинки по всей площади - так можно, но что это за процессинг картинки лично я не понимаю. > секунду, пентиум-1 умрёт со смеху обрабатывая картинку за тоже время, что > и топовый i7. Таки со времен первого пентиума щины стали быстрее, частоты увеличились везде, DDR тоже улучшился. И в результате это скорее "одноплатник с половину кредитки умрет со смеха, уделав в 30 раз огроменный железный ящик, потребляя в 30 раз меньше энергии". Ну вот как-то так технологии со времен первого пня ушли, что первопень ползает со скоростью когда даже MIPS в роутере-мыльнице будет над ним смеяться.
	Ответить | Правка | ^ к родителю #457 | Наверх | Cообщить модератору

	492. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 16-Дек-18, 00:03
	Напомню лицам с девичьей памятью, что у первопня и вообще тогдашних процессоров был сравнительно короткий конвейер и совсем маленький множитель тактовой частоты, что вкупе с низком латентностью памяти прекрасно работает на сравнительно маленьких порциях данных. А в современных процессорах с многомегабайтными кешами нескольких уровней и длиннющим конвейером, большими множителями, очень большой латентностью ОЗУ (но при широкой оного шине) высокая производительность имеет место только для больших порций данных. На скромных и компактных «морально устаревших» программах, умевших-таки обрабатывать огромное файло, не умещавшееся даже в ОЗУ, а не только в кеш, выигрыш ультрасовременных вычислительных железяк внезапно нивелируется, если их не грузить чем-то очень объёмным. Что недвусмысленно намекает и на некоторые свойства железа, и на умения погромиздов, пишущих модно-прогрессивный софт. Я приводил уже в пример суперкомпьютер начала девяностых, имевший максимально 128 гигов памяти. Но оном суперкомпьютере люди решали суперкомпьютерные задачи. На сопоставимом по «чистой» вычислительной мощности современном писюке веб-макака способна разве что писать однодневный ненужнософт в невероятно прожорливых IDE. Мощность как бы выросла, ага, и «время ращработчиков дороже стоит», а польза от вычислений снизилась на многие-многие порядки.
	Ответить | Правка | ^ к родителю #467 | Наверх | Cообщить модератору

	494. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 16:11
	> вкупе с низком латентностью памяти прекрасно работает на сравнительно маленьких порциях > данных. А в современных процессорах с многомегабайтными кешами нескольких уровней и > длиннющим конвейером, большими множителями, очень большой латентностью ОЗУ (но при широкой > оного шине) высокая производительность имеет место только для больших порций данных. И тем не менее - с тех пор АБСОЛЮТНО ВСЕ разогналось как минимум В РАЗЫ. Настолько что по скорости и латенси памяти этому УГ может воткнуть даже мипсовая мыльница-роутер, потому что там видите ли DDR2, а то и 3 нормальный впаяли, на приличной частоте. А у пенька извините что было? EDO? Или в лучшем случае SDRAM? Одно это обеспечит ему чебурашью скорость работы. Придирчивый народ мониторит в тех же армовских одноплатниках частоты/ширину шины. Потому что одно дело DDR2 на 16-битной шине, и совсем другое 32 и тем более 64 бита DDR3 c более приличной частотой. Он такой красивый и на больших порциях выиграет, и на маленьки. Потому что порции при лопатинге картинки уж наверное покрупнее 16 битов подразумевались, и наверное с каким-никаким линейным доступом - по другому картинки процессят только очень странные люди, которым производительность явно не интересна была: они мигом аннулируют любые намеки на кеширование, префетч и создают море оверхеда на шине памяти т.к. там для каждой операции потребуется слать адреса, а не просто запустить отправку жирного блока и грести лопатой, уже без отсылки адресов на каждую порцию, чуть ли не по порции размером с ширину шины каждый такт, что гораздо веселее. > На скромных и компактных «морально устаревших» программах, умевших-таки обрабатывать > огромное файло, не умещавшееся даже в ОЗУ, Это все круто, НО есть весьма характерный tradeoff между памятью и скоростью. И как бы экономия памяти означает тормозной процессинг. Особенно весело когда половина оперативы в результате пустая, а программа занимается тасовкой файлов по причине нехватки, блин, циферок в своей математике. Очень "эффективно" получается. При том что против идеи процессинга данных не влезающих в RAM я ничего не имею. Это по своему красиво. Но производительность зачастую получается издевательской по сравнению с тем что можно получить врузив датасет в рам - и так делают только когда данные реально большие или неограниченно растут. Ну типа как OSMная база данных, особенно ежели со всей историей редактирования - там да, никакой RAM не хватит, и с течением времени данных будет только больше. > кеш, выигрыш ультрасовременных вычислительных железяк внезапно нивелируется, если их > не грузить чем-то очень объёмным. Таки оно все-же выигрывает даже и так. Из-за апгрейда остальных частей системы, и вообще. А так то можно порассуждать о том что будет если кэши вырубить, что пентиуму, что core i9. Они оба будут жалкими, но пень все-же продует в разы и так. Но менее эпично чем обычно :) > Что недвусмысленно намекает и на некоторые свойства железа, и на умения погромиздов, Погромизды стали оптимизировать свой софт под свойства актуального железа, делая удобно именно ему. Чтобы оно реализовывало свой потенциал. Таки железо и софт шли навстречу друг другу. Пэтому вот вам выравнивание структур на линию кэша. Даже если это и делает структуру более жирной, зато скорость доступа улучшается, т.к. кэшу удобно стало. А вот крипто, ворочает 64 бита за раз. Потому что проц может за такт долбануть 32 бита, а может 64. И если за тот же такт вдвое больше обмолочено, это профит. Почти в 2 раза. Нахаляву. И сама математика такая что уже не избегает операций регистр-регистр, потому что РОНов типа много. > уже в пример суперкомпьютер начала девяностых, имевший максимально 128 гигов памяти. > Но оном суперкомпьютере люди решали суперкомпьютерные задачи. При том эти задачи были интересны лишь очень узкому кругу лиц. И как бы тогда никто не смотрел видео на компьютерах. И картинки в 300Мпикс всерьез никто не редактировал. Ну вот может кроме нескольких рож с суперкомпьютерами на всю планету. Типовой же юзерь 5 фотошопа с пентиумом получив на вход 300Мпикс картинку очень быстро отползет, увидев как его фотож... с этим реально работает. Теоретически, конечно, он через недельку прожует это. Практически оно юзеру через недельку - не очень то и хотелось. А про монстроIDE и софт с полураспадом в год я таки согласен :)
	Ответить | Правка | ^ к родителю #492 | Наверх | Cообщить модератору

	515. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 16-Дек-18, 22:14
	> И тем не менее - с тех пор АБСОЛЮТНО ВСЕ разогналось как > минимум В РАЗЫ. Настолько что по скорости и латенси памяти этому > УГ может воткнуть даже мипсовая мыльница-роутер, потому что там видите ли > DDR2, а то и 3 нормальный впаяли, на приличной частоте. А > у пенька извините что было? EDO? Или в лучшем случае SDRAM? > Одно это обеспечит ему чебурашью скорость работы. Разогнали шины и множители, что даёт эффект на больших порциях данных (aka bloatware). А реальные «железные» скорости не разогнались особо, потому что там физика. Если сильно разгонять, начнёшь радио слушать чипом. Надеюсь, ты ещё помнишь про то, как получается «частота процессора», и про обещания Интела обеспечить всем коммунизм^W по 10 ГГц в каждый дом? > Придирчивый народ мониторит в тех же армовских одноплатниках частоты/ширину шины. Потому > что одно дело DDR2 на 16-битной шине, и совсем другое 32 > и тем более 64 бита DDR3 c более приличной частотой. Он > такой красивый и на больших порциях выиграет, и на маленьки. Как ты думаешь, почему оперативную память делают по «морально устаревшим» техпроцессам, и почему внутренняя скорость чипов памяти не растёт? >  c более приличной частотой Нету там внутри никакой «более приличной частоты». Только ширина шины больше. И накладные расходы на её обслуживание, ха-ха-ха. Старую память контроллеру обойти было быстро не только потому, что её было мало. :) Ты пойми: бесплатный сыр бывает только в мышеловке. >> На скромных и компактных «морально устаревших» программах, умевших-таки обрабатывать >> огромное файло, не умещавшееся даже в ОЗУ, > Это все круто, НО есть весьма характерный tradeoff между памятью и скоростью. > И как бы экономия памяти означает тормозной процессинг. Особенно весело когда > половина оперативы в результате пустая, а программа занимается тасовкой файлов по > причине нехватки, блин, циферок в своей математике. Очень "эффективно" получается. Я уже видел, как по стратегии «займём всю память, она же не должна простаивать» постоянно приходится пинать ОС вручную, чтобы освободила память для других приложений, а «только что закрытым» она понадобится не раньше, чем я это решу, а не тупой диспетчер памяти, настроенный обезьянами. Когда я читаю твои развесистые рассуждения о том, как правильно использовать памяти, мне кажется, что ты всё-таки на самом деле не понимаешь, что такое виртуальная память и что такое неймановская архитектура. Слова умные вроде знаешь, и даже складывать их в предложения умеешь, а смысла никакого из них не рождается. Представь, что ОЗУ — это быстрый кэш, не более того. Если ты забил промежуточный буфер между медленной долговременной памятью (диском) и процессором, то быстро ехать уже не получится даже при всём желании. Поэтому правильно держать эту буферную память максимально свободной, ибо иначе придётся постоянно лезть на диск за каждым ссаным байтом, пока ОЗУ будет занято тем, что «может пригодиться, ведь его только что недавно закрыли». И это в каждый момент времени! Ага, я такое видел. Спасибо, больше не хочу. Предпочитаю лучше подождать дополнительных 100 мс при каждом запуске приложения, а не постоянно доставать всё нужное из свопа. > При том что против идеи процессинга данных не влезающих в RAM я > ничего не имею. Это по своему красиво. Но производительность зачастую получается > издевательской по сравнению с тем что можно получить врузив датасет в > рам - и так делают только когда данные реально большие или > неограниченно растут. Ну типа как OSMная база данных, особенно ежели со > всей историей редактирования - там да, никакой RAM не хватит, и > с течением времени данных будет только больше. Бджд, для высокой производительности программ надо всего лишь писать производительный код на максимально близком к железу уровне, вот и всё. А не превращать всё в «интерпретатор языка высокого уровня». Почему-то у хорошей сисясто-ассемблерной программы обычно нет проблем с производительностью даже на старом железе и скудной памяти, а у модно-прогрессивных аппликух постоянно нехватка ресурсов, «надо докупить ещё, память нынче стоит копейки». >> кеш, выигрыш ультрасовременных вычислительных железяк внезапно нивелируется, если их >> не грузить чем-то очень объёмным. > Таки оно все-же выигрывает даже и так. Из-за апгрейда остальных частей системы, > и вообще. А так то можно порассуждать о том что будет > если кэши вырубить, что пентиуму, что core i9. Они оба будут > жалкими, но пень все-же продует в разы и так. Но менее > эпично чем обычно :) Внутренние скорости работы чипов и прочего железа — гугл ит, плиз, энд рид ит. >> Что недвусмысленно намекает и на некоторые свойства железа, и на умения погромиздов, > Погромизды стали оптимизировать свой софт под свойства актуального железа, делая удобно > именно ему. Чтобы оно реализовывало свой потенциал. Таки железо и софт > шли навстречу друг другу. Нет, товарищ комсорг, не так всё было. Никто ничего не оптимизировал, ибо оптимизацию ваши товарищи по комсомолу и партии возложили на трудящихся в формате регулярного похода в магазин за новым железом. Дальше лень.
	Ответить | Правка | ^ к родителю #494 | Наверх | Cообщить модератору

	523. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (523), 17-Дек-18, 02:52
	> Разогнали шины и множители, что даёт эффект на больших порциях данных (aka bloatware). То-есть если я бэкап жму - это bloatware, оказывается? Да и фоточки разрешением 640х480 не втыкают. > А реальные «железные» скорости не разогнались особо, потому что там физика. Сильнее всего в те поры физика упиралась в нормы техпроцессов и результирующее оттуда потребление и тепловыделение. По мере уменьшения элементов схем тепловыделение уменьшалось, довольно круто. Пропорционально 3...4 степени. Кроме того - не умели делать компактное, массовое и эффективное охлаждение на подобные мощности (в серверах лучше, но звук!!!). А еще - преобразователи питания и управление питанием, DVFS и проч. С тех пор как минимум... - Многофазные схемы питания с регулируемым вольтажом. Которые не пасуют перед отгрузкой 1V 100A в проц. Ну вот такой вот трамвайчик. - Полимерные lowESR кондеры, которые и не вскипают от нагрева своим же ESR. - DVFS, power & clock gating - позволили схемам быть быстрым в пике но не жрать как трамвай на холостых режимах. - Частоты стали выше в разы. Глобально, везде. - Вентиляторами научились управлять с регулировкой оборотов. - Сами технологии охлаждения здорово прокачали (на десктопах, в лаптопах, а теперь и в мобильных устройствах). - Шины - усовершенствовали и довольно радикально сменили парадигмы местами. Это была эпоха начала конца параллельных шин. - Оператива сейчас напрямую к процу, а не чипсету. Минус латенси гейтовки CPU FSB <-> RAM чипсетом. > Если сильно разгонять, начнёшь радио слушать чипом. В железном ящике? :) А так слив по transmission line и антеннам засчитан. Да, это пришлось узнать не только RF engineer'ам, но и цифровикам c энного момента. Как раз поэтому. Как ты думаешь, почему в IDE стало 80 проводов? :) Посотри на кабель SATA, особенно 6Gbps. Это не просто кусок провода. А дорожки на платах следуют хитрым паттернам и идут парами. Не просто так. Они все стали низковольтными, дифференциальными, более последовательными и менее синхронными в отличие от наивных первобытных шин сделанных "в лоб". А так у цифры фронты крутые - даже в "низкоскоростной" схеме уровня ардуины по этому поводу можно выкусить. Спроси у Зенкова какой спектр у прямоугольника с его фронтами. > Интела обеспечить всем коммунизм^W по 10 ГГц в каждый дом? Таки интел лоханулся именно по линии частот и тепловыделения. Загнать кремний на 10ГГц как таковой можно. Но не миллиардом транзисторов, в этом случае он умрет по перегреву. Вести 10ГГц по плате так себе идея. Реально по FR4 разводят до примерно 5. Кто не верит - смотрит домашние роутеры. Хотя в спутникаовых штуках и 10 вроде делают, но выглядит специфично. Собственно опытом RFщиков пользуются. Когда надо, излучает. Когда не надо - не излучает. Правда теперь цифровики реально мыслят как СВЧшники наполовину. Даже не только из-за мегагерцев, но и из-за наносекундных фронтов, которые разлетаются независимо от периодичности. Если кто не понял - возможны странные методы синтеза сигнала, когда периодики с энным периодом как таковой может и не быть. Какой период у wideband сигналов? > Как ты думаешь, почему оперативную память делают по «морально устаревшим» техпроцессам, > и почему внутренняя скорость чипов памяти не растёт? А потому что смысла нет. Если сделать DRAM меньше по размеру элемента, конденсаторы DRAM начнут жутко утекать, вместо счастья случится EPIC FAIL. Этот эффект очень сильно долбит на мелких техпроцессах. И там где потребление важно, борьбе с этим посвящен целый раздел технологий power management. Потребление ничего не делающего тонкого чипа довольно сильно состоит из утечек. А когда так DRAM делает - она еще и склерозом становится. И чем жарче - тем лучше. Любители тырить пароли из ребутнутого компа - уважают жидкий азот :) > Нету там внутри никакой «более приличной частоты». Да все там есть. Хотя самые высокие частоты синтезируют прямо в чипах, чтобы не тащить по плате. Man PLL. > Только ширина шины больше. А теперь посмотри в вике что означает "DDR" - одно это делает шину вдвое быстрее на той же частоте. Даже если забить на прочие оптимизации и ощутимый пересмотр "электрики" в сторону дружественности высоким скоростям. > И накладные расходы на её обслуживание, ха-ха-ха. Старую память контроллеру обойти > было быстро не только потому, что её было мало. :) Старая память была тормозной аки трактор, неоптимальной по циклам шины, дурной по физике, тормозной по частотам. И работала с непотребной скоростью. Пеньку с EDO, да даже и с SDR SDRAM - воткнет даже 20-баксовая MIPSовая мыльница с DDR'ом. > Ты пойми: бесплатный сыр бывает только в мышеловке. Бывает эволюция технологий. Физику нельзя обмануть. Но можно взять на свою сторону. Там где мы хотим излучать - антенна. Не хотим - делаем transmission line (wave guide). Это просто делается по разному. С явным осмыслением. Да, это уже не просто протяжка дорожек наобум и требует странные скиллы. И не всегда выходит с первого раза даже с крутейшими CAD и симуляторами. ...а цена в чуть ином. Например DVFS и управление вентилями позволяет системе с одной стороны не выть как пылесос в холостом режиме, с другой - показывать впечатляющую производительность. Но это делает систему более хрупкой. Можно срубить сдуру вентилятор. Можно заказать чипу питания напряжение выше чем он физически выдержит на этой частоте. Начинают требоваться сервисные процики, которые этим займутся в жестком реальном времени. Система становится сложнее и хлипче. Ее старт напоминает запуск ракеты. > Я уже видел, как по стратегии «займём всю память, она же не > должна простаивать» постоянно приходится пинать ОС вручную, Кому приходится - тот пусть этим и страдает. А я в моей ОС не занимаюсь ручным менеджментом память по счастью. > такое виртуальная память и что такое неймановская архитектура. Слова умные вроде > знаешь, и даже складывать их в предложения умеешь, а смысла никакого из них не рождается. Таки понимаю. Это ты не понимаешь что в обозримом будущем возможно вообще вся память в системе станет адресуемой напрямую. Без такого понятия как стораж. NVDIMM тому первый звоночек, но ни разу не последний. Вообще идея пропихать NAND через SATA - изврат. И даже через PCI-E. Он логичнее смотрится замапленым напрямую в адреса, с тонким и быстрым слоем трансляции. MRAM/FRAM - и подавно. Упомянутых кстати уже промышленно делают. Ramtron так по жизни для индустриалов делает "вечные EEPROM", Ti слегка это лицензировал для своих МК. > Представь, что ОЗУ — это быстрый кэш, не более того. Скоро, похоже, сторажи станут "медленным RAM", как мне кажется. Периферия уже стала, она вся сплошь "memory mapped". Это удобно. И сишникам с точки зрения програмизма, и виртуалкам, достаточно очевидный IOMMU позволяет отрезать железку в VM. Делая то же что MMU, но с другой стороны. > буфер между медленной долговременной памятью (диском) и процессором, то быстро ехать > уже не получится даже при всём желании. Плохо стыкуется с примером 300Мпикс картинки и процессинга ее пикселей. Вгрузить ее с диска 1 раз, к тому же сжатую. Декомпресс и любая возня с пикселями будут намного лучше, если попадут в хотя-бы RAM, без насилия над диском вообще. На линейных операциях характерных для обсчета картинок к тому же неплох даже обычный RAM. Хотя GDDR или HBM в GPU лучше. Но их меньше, потому что они дорогие и не апгрейдабельные. > буферную память максимально свободной, ибо иначе придётся постоянно лезть на диск > за каждым ссаным байтом, пока ОЗУ будет занято тем, что «может > пригодиться, ведь его только что недавно закрыли». И тем не менее, по моему опыту, жирный дисковый буфер - делает работу с ОС намного приятнее. По сути превращая медленный стораж в подобие быстрого рамдиска. Спору нет, если все забить приложениями - эта иллюзия отвалится. Поэтому забивать память под завязку приложениями все же не стоит. ...но если картинка весила допустим 5 гигз, в системе было 16, то у меня еще 11 гигз на все такое прочее. А обсчитать картинку как просто массив в оперативе явно быстрее чем таскать ее расжатую версию из свопа с диска и чего там еще. Вот отлить несколько гигз на диск - это не быстро по хоть каким стандартам. И поэтому фотожоп с 300Мпикс картинке на первом пне - не упадет, но скорость его работы - заманает в край. В отличие от скорости работы любого редактора на машине с 16 гигз. > лучше подождать дополнительных 100 мс при каждом запуске приложения, а не > постоянно доставать всё нужное из свопа. У меня нет свопа. Как максимум у меня есть zram, типа-своп в сжатом рамдиске. Если оперативы хронически не хватило - холодные данные можно попробовать закомпрессить, в надежде что вот так ее все же хватит. Если и так не хватит - и нафиг. Камасутра с 5-м фотошопом на пентиуме и 300 мпикс картинкой - не ко мне. > Бджд, для высокой производительности программ надо всего лишь писать производительный > код на максимально близком к железу уровне, вот и всё. С современным железом это легче сказать чем сделать. Начиная с того что реально код не имеет дело с блоками выполнения. Он попадает в uCode ROM и тот разваливает его на микрооперации, а что случится дальше, а также сколько и каких блоков фактически есть в том или ином камне - известно лишь крайне приблизительно. Кроме того - при чрезмерном увлечении код получается не портабельным или обладает хреновой производительностью на других архитектурах, если там сделано иначе. А так то да, дрова в досе и даже 95 писали на асме. Было круто и быстро. Но работало только на x86. А нтя таки с дровами на си уже была. Поэтому и была неповоротливой, зато таки портированной на кучу архитектур. Этот тренд и в остальных системах продолжился. > А не превращать всё в «интерпретатор языка высокого уровня». Как бы интерпретаторы никогда не были быстрыми. Еще со времен бэйсика. > Почему-то у хорошей сисясто-ассемблерной программы обычно нет проблем > с производительностью даже на старом железе и скудной памяти, а у модно-прогрессивных > аппликух постоянно нехватка ресурсов, «надо докупить ещё, память нынче стоит копейки». И все же, даже если ты запустишь чисто сишный вариант допустим современного крипто на чем-то 32-битном а потом на сравнимом 64-битном, разница будет довольно убедительной. Так же с мультимедийным добром и прочей тяжелой математикой. А где еще производительность собственно нужна? Ну наверное не в туповэйтинге юзерского ввода. > Внутренние скорости работы чипов и прочего железа — гугл ит, плиз, энд рид ит. Хотите об этом поговорить? :) Я как бы в курсе ПСП шин. И так для понимания... - ПСП шины памяти на K6-2 (даже покруче первого пентиума) около 600Мб/сек была. - ПСП DDR3 у моего десктопа около 20 Гб/сек. - ПСП GPU GDDR5 под 180Гб/сек. Это более-менее линейный доступ. Первые 2 измерены мемтестами, последнее opencl'ными бенчами похожими по смыслу. И как угодно но при прочих равных линейный доступ к оперативе, типовой для обсчета картинки, воткнет той штуке эпохи пентиумов в 33 раза на типовых паттернах характерных для обсчета картинок. Но еще лучше будет если это влезет в GPU и туда придет opencl фильтр, который мало того что массово SIMDшный как черти что, так еще и ПСП эвон какой. И он таки реально в разы быстрее основного cpu сжует это. Поэтому и GPU, собственно - хорошо с графикой работает. > Нет, товарищ комсорг, не так всё было. Никто ничего не оптимизировал, Посмотри на эволюцию крипто и не тупи. Симметричные алгоритмы и хэширование. Salsa, chacha, sha-3, да даже AES... их лучше на 64-бит проце крутить. Больше за 1 такт обсчитывается. И вот так было везде где скорость счета кого-то колыхала. Будь то графические фильтры или мультимедийные кодеки или что там еще. > ибо оптимизацию ваши товарищи по комсомолу и партии возложили на трудящихся в > формате регулярного похода в магазин за новым железом. Да ну ерунда, не все же - вебмакаки. Есть и алгоритмисты. И они таки тоже на 32 бита забили. А как я это узнал? Блин попробовал найти алгоритмов под 32 битный микроконтроллер. И обчертыхался. Таки да, 64-бит математика там есть, и даже работает, но таки из 32-бит регистров она получается медленнее. И код жирнее, чем если нативный юнит с которым оперировали был бы 32 бита. А на 64 бит проце оно конечно же офигенно раскладывается.
	Ответить | Правка | ^ к родителю #515 | Наверх | Cообщить модератору

	532. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 08:39
	> Сильнее всего в те поры физика упиралась в нормы техпроцессов и результирующее > оттуда потребление и тепловыделение. По мере уменьшения элементов схем тепловыделение > уменьшалось, довольно круто. Пропорционально 3...4 степени. Почему не 7...8? Где теплоёмкость? Тепловыделение в электронных элементах зависит от объёма единичного элемента, который *в общем* пропорционален 3-й степени линейного размера, силы протекающего тока и частоты переключений.
	Ответить | Правка | ^ к родителю #523 | Наверх | Cообщить модератору

	548. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 17-Дек-18, 10:39
	>> Разогнали шины и множители, что даёт эффект на больших порциях данных (aka bloatware). > То-есть если я бэкап жму - это bloatware, оказывается? Да и фоточки > разрешением 640х480 не втыкают. Не в кассу. Будьте добры высказывать ваши тезисы по существу, тов. комсорг. >> А реальные «железные» скорости не разогнались особо, потому что там физика. > Сильнее всего в те поры физика упиралась в нормы техпроцессов и результирующее > оттуда потребление и тепловыделение. По мере уменьшения элементов схем тепловыделение > уменьшалось, довольно круто. Пропорционально 3...4 степени. Техпроцессы считают по производственному оборудованию, ёпт, а не по транзисторам. :) Тепловыделение делают настолько высоким, сколько можно остудить за приемлемую стоимость без стремительной деградации кристалла. А можно сделать любым, да. В том числе таким, что печка i9 будет работать при комнатной температуре вообще без радиатора. Но будет немножко не так быстро. И в этом месте любому здравомыслящему человеку должно стать понятно, что прогрессивные современные процессоры уже с завода разогнаны. Самую малость, ага, чуть-чуть. И ещё это трезвомыслящим людям повод для размышлений о том, насколько велики на самом деле внутри архитектурные изменения в сравнении с Pentium Pro. Если мысленно отрезать, эксперимента ради, весь кэш, то останется из внутренних отделов… ой, какое всё знакомое! Что ж ты делаешь, Интел! > Кроме того - не умели делать компактное, массовое и эффективное охлаждение на > подобные мощности (в серверах лучше, но звук!!!). А еще - преобразователи > питания и управление питанием, DVFS и проч. С чего ты взял, что не умели? Или речь про теплотрубки? Ну да, на писяках этого когда-то не было. А схемы питания с каких пор стали рокетсаенсом? Просто не гнали первопни до тепловыделения под 300—500 Вт, как гонят i9. П-ц, натуральный же утюг. >[оверквотинг удален] > - DVFS, power & clock gating - позволили схемам быть быстрым в > пике но не жрать как трамвай на холостых режимах. > - Частоты стали выше в разы. Глобально, везде. > - Вентиляторами научились управлять с регулировкой оборотов. > - Сами технологии охлаждения здорово прокачали (на десктопах, в лаптопах, а теперь > и в мобильных устройствах). > - Шины - усовершенствовали и довольно радикально сменили парадигмы местами. Это была > эпоха начала конца параллельных шин. > - Оператива сейчас напрямую к процу, а не чипсету. Минус латенси гейтовки > CPU FSB <-> RAM чипсетом. Некоторые элементы значительно улучшены, верно, и появилось чуть нового. Но всё остальное, ты уж извини, это не рокетсаенс. И не надо тут людям вешать на уши про управление оборотами вентиляторов, смешно же читать. :) А шины просто расширили, по сути. Никаких научно-технических прорывов не было. Касательно ОЗУ — ты хоть сам себе честно ответь на вопрос: CL 2 и CL 20 — это сколько разницы в абсолютной скорости на уровне ячеек, и на уровне шины, и на уровне контроллера? Про эффективность так про эффективность! ;-) >[оверквотинг удален] > засчитан. Да, это пришлось узнать не только RF engineer'ам, но и > цифровикам c энного момента. Как раз поэтому. > Как ты думаешь, почему в IDE стало 80 проводов? :) Посотри на > кабель SATA, особенно 6Gbps. Это не просто кусок провода. А дорожки > на платах следуют хитрым паттернам и идут парами. Не просто так. > Они все стали низковольтными, дифференциальными, более последовательными и менее синхронными > в отличие от наивных первобытных шин сделанных "в лоб". > А так у цифры фронты крутые - даже в "низкоскоростной" схеме уровня > ардуины по этому поводу можно выкусить. Спроси у Зенкова какой спектр > у прямоугольника с его фронтами. Вот и пришлось менять параллельные шины на последовательные. Чтоб на высоких скоростях не слушать сплошное радио всеми внутренними потрохами и внешними устройствами. Радио не буквально, разумеется, а в виде помех и наводок, ибо местами на несколькогигагерцовых частотах мелкие проводники сами начинают излучать. Таки да, внутри железного ящика. :) >> Интела обеспечить всем коммунизм^W по 10 ГГц в каждый дом? > Таки интел лоханулся именно по линии частот и тепловыделения. Загнать кремний на > 10ГГц как таковой можно. Но не миллиардом транзисторов, в этом случае > он умрет по перегреву. Загнать-то можно. Ещё в какие годы Межделмаш сделал транзистор, переключающийся на 100+ ГГц. Только с этого нет пользы, ибо на высоких частотах появляются новые факторы из-за новых физических явлений, а не только тепловое излучение. >> Как ты думаешь, почему оперативную память делают по «морально устаревшим» техпроцессам, >> и почему внутренняя скорость чипов памяти не растёт? > А потому что смысла нет. Если сделать DRAM меньше по размеру элемента, > конденсаторы DRAM начнут жутко утекать, вместо счастья случится EPIC FAIL. Этот > эффект очень сильно долбит на мелких техпроцессах. И там где потребление > важно, борьбе с этим посвящен целый раздел технологий power management. Потребление > ничего не делающего тонкого чипа довольно сильно состоит из утечек. А > когда так DRAM делает - она еще и склерозом становится. И > чем жарче - тем лучше. Любители тырить пароли из ребутнутого компа > - уважают жидкий азот :) Ну вот, вроде как человек в теме и в курсе всех проблем. А за системду топит. Непостижимо. Заплатили? Скажи хоть сколько. Может и я начну писать за деньги агитпродукт за системду. >> И накладные расходы на её обслуживание, ха-ха-ха. Старую память контроллеру обойти >> было быстро не только потому, что её было мало. :) > Старая память была тормозной аки трактор, неоптимальной по циклам шины, дурной по > физике, тормозной по частотам. И работала с непотребной скоростью. Пеньку с > EDO, да даже и с SDR SDRAM - воткнет даже 20-баксовая > MIPSовая мыльница с DDR'ом. Ну я не про аж такую старую. Берём 20-летней давности SDRAM типа PC-100, например. > Таки понимаю. Это ты не понимаешь что в обозримом будущем возможно вообще > вся память в системе станет адресуемой напрямую. Без такого понятия как > стораж. NVDIMM тому первый звоночек, но ни разу не последний. Вообще > идея пропихать NAND через SATA - изврат. И даже через PCI-E. > Он логичнее смотрится замапленым напрямую в адреса, с тонким и быстрым > слоем трансляции. Сомневаюсь в скором наступлении этого светлого будущего. Это неэффективно с точки зрения накладных расходов для большинства применений. То есть сделать-то можно, но мало кому это на самом деле нужно. А кому нужно, те не удовлетворятся ширпотребом. Жадные производители настолько зажрались, что распаивают на материнках лишние слоты с расшаренными линиями. Зато всё в разноцветных огнях светодидов, разукрашено в цвета китайского дракона и так далее. > MRAM/FRAM - и подавно. Упомянутых кстати уже промышленно делают. Ramtron так по > жизни для индустриалов делает "вечные EEPROM", Ti слегка это лицензировал для > своих МК. Ну, я думаю, что излишне напоминать, сколько мы читаем о «завтраках» на эту тему. А воз и ныне там. Я уже забил ждать. :) >> Представь, что ОЗУ — это быстрый кэш, не более того. > Скоро, похоже, сторажи станут "медленным RAM", как мне кажется. Периферия уже стала, > она вся сплошь "memory mapped". Это удобно. И сишникам с точки > зрения програмизма, и виртуалкам, достаточно очевидный IOMMU позволяет отрезать железку > в VM. Делая то же что MMU, но с другой стороны. Идея очень хорошая и плодотворная, но не с теми ячейками, которые пихают в SSD. >> буфер между медленной долговременной памятью (диском) и процессором, то быстро ехать >> уже не получится даже при всём желании. > Плохо стыкуется с примером 300Мпикс картинки и процессинга ее пикселей. Вгрузить ее > с диска 1 раз, к тому же сжатую. Декомпресс и любая > возня с пикселями будут намного лучше, если попадут в хотя-бы RAM, > без насилия над диском вообще. На линейных операциях характерных для обсчета > картинок к тому же неплох даже обычный RAM. Хотя GDDR или > HBM в GPU лучше. Но их меньше, потому что они дорогие > и не апгрейдабельные. В теоретической неймановской модели вся память условно одинакова и равноценна. Почему бы не править только те куски файла, которые надо, через окошко, не дёргая весь файл? Экономия налицо, причём при любых условиях. Ну понятно, что на актуальном железе память на самом деле не одинакова, не однородна, и ещё в ней есть медленные диски, а файло на них ещё и упаковано. :) >> буферную память максимально свободной, ибо иначе придётся постоянно лезть на диск >> за каждым ссаным байтом, пока ОЗУ будет занято тем, что «может >> пригодиться, ведь его только что недавно закрыли». > И тем не менее, по моему опыту, жирный дисковый буфер - делает > работу с ОС намного приятнее. По сути превращая медленный стораж в > подобие быстрого рамдиска. Спору нет, если все забить приложениями - эта > иллюзия отвалится. Поэтому забивать память под завязку приложениями все же не > стоит. Я имел в виду всё-таки ОЗУ. > ...но если картинка весила допустим 5 гигз, в системе было 16, то > у меня еще 11 гигз на все такое прочее. А обсчитать > картинку как просто массив в оперативе явно быстрее чем таскать ее > расжатую версию из свопа с диска и чего там еще. Вот > отлить несколько гигз на диск - это не быстро по хоть > каким стандартам. И поэтому фотожоп с 300Мпикс картинке на первом пне > - не упадет, но скорость его работы - заманает в край. > В отличие от скорости работы любого редактора на машине с 16 > гигз. Не. Не всё так просто. Руконогие эту картинку будут («а чо? память дивошая!») кэшировать и перекэшировать многократно и на каждую отмену сделанных операций и ещё на массу факторов. Поэтому всё равно памяти всегда будет мало. Простое увеличение объёма ОЗУ никак не решает проблему неэффективных алгоритмов и рук, выросших из низа спины. Возможно, что создателям эффективных графических редакторов и файловых форматов пригодились бы знания разработчиков файловых систем, но эти ребята как-то не пересекаются между собой по роду деятельности. >> лучше подождать дополнительных 100 мс при каждом запуске приложения, а не >> постоянно доставать всё нужное из свопа. > У меня нет свопа. Как максимум у меня есть zram, типа-своп в > сжатом рамдиске. Если оперативы хронически не хватило - холодные данные можно > попробовать закомпрессить, в надежде что вот так ее все же хватит. > Если и так не хватит - и нафиг. Камасутра с 5-м > фотошопом на пентиуме и 300 мпикс картинкой - не ко мне. Идея свопа в ОЗУ спорна, но обсуждать её лень. >> Бджд, для высокой производительности программ надо всего лишь писать производительный >> код на максимально близком к железу уровне, вот и всё. > С современным железом это легче сказать чем сделать. Начиная с того что > реально код не имеет дело с блоками выполнения. Он попадает в > uCode ROM и тот разваливает его на микрооперации, а что случится > дальше, а также сколько и каких блоков фактически есть в том > или ином камне - известно лишь крайне приблизительно. Кроме того - > при чрезмерном увлечении код получается не портабельным или обладает хреновой производительностью > на других архитектурах, если там сделано иначе. Ну это уже вопросы, выходящие даже за те рамки, что мы тут расширяем и углубляем. :) Пока Си и ассемблеры работают для того железа, которое сейчас у нас есть, можно принять как соглашение, что это железо внутри не изменилось со времён первых x86. > А так то да, дрова в досе и даже 95 писали на > асме. Было круто и быстро. Но работало только на x86. А > нтя таки с дровами на си уже была. Поэтому и была > неповоротливой, зато таки портированной на кучу архитектур. Этот тренд и в > остальных системах продолжился. А нам точно-точно  надо, чтоб работало где-то ещё? Кроссплатформенность — это непродуктивная идея, с точки потребителя. Нативный софт всегда работает лучше и быстрее. > И так для понимания... > - ПСП шины памяти на K6-2 (даже покруче первого пентиума) около 600Мб/сек > была. > - ПСП DDR3 у моего десктопа около 20 Гб/сек. > - ПСП GPU GDDR5 под 180Гб/сек. Согласен. А теперь ответь на мой любимый простой вопрос: почему при таком впечатляющем прогрессе новый Ворд тормозит на самом новом железе так же, как тогдашний Ворд на тогдашнем железе. >> Нет, товарищ комсорг, не так всё было. Никто ничего не оптимизировал, > Посмотри на эволюцию крипто и не тупи. Симметричные алгоритмы и хэширование. > Salsa, chacha, sha-3, да даже AES... их лучше на 64-бит проце крутить. > Больше за 1 такт обсчитывается. И вот так было везде где > скорость счета кого-то колыхала. Будь то графические фильтры или мультимедийные кодеки > или что там еще. Мне до крипто никакого дела, мне есть дело только до браузеров, фотошопов и вордов. >> ибо оптимизацию ваши товарищи по комсомолу и партии возложили на трудящихся в >> формате регулярного похода в магазин за новым железом. > Да ну ерунда, не все же - вебмакаки. Есть и алгоритмисты. И > они таки тоже на 32 бита забили. Да ладно, не по сеньке эта шапка. Забили производители железа. Как я уже говорил, фактически ADM64 это та же PAE, только «наоборот». Это не настоящая 64-битная архитектура. Сорри, я не всё комментирую, а кусочками, нет времени.
	Ответить | Правка | ^ к родителю #523 | Наверх | Cообщить модератору

	373. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Онаним (?), 14-Дек-18, 09:30
	Что да - то да, ручной paging - это жопа. Ребята просто ZX Spectrum 128K не застали, где было одно окно в 16 килобайт. Чтобы через это окно работать со всем объёмом памяти - надо было очень сильно извращаться.
	Ответить | Правка | ^ к родителю #271 | Наверх | Cообщить модератору

	398. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 14-Дек-18, 15:17
	Я застал другие 8-битные железки. Тоже с банкингами и прочей камасутрой. И именно поэтому - на фоне этого УГ даже cortex M0 - masterpiece of engineering :D
	Ответить | Правка | ^ к родителю #373 | Наверх | Cообщить модератору

	571. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Алексей Михайлович (?), 17-Дек-18, 18:51
	Да не гони. Вот я, положим, решил песню написать. Живых барабанов у меня дома нет, да и вряд ли появятся (сосед не хуже меня стреляет всё-таки), а ещё я жадный и не хочу платить сессионнику, поэтому нужны электронные. Пошёл я качать библиотеку для драм-машины, чтобы песенка всё-таки жила. Скачиваю библу, распаковываю… А там — эка невидаль! — аж целых 5 с хреном гигов чистых данных. И что-то нет у меня желания выбирать библиотеки сэмплов по разрядности моей системы.
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

	275. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 16:35
	> Что должно произойти в 38 году? «Часы сломаются»? Это не страшно. И > это на самом деле не зависит от адресации памяти. А таки в результате на самом деле требуется "старшая часть" этого 32-битного счетчика. И я такой костыль вбил даже на STM32 где именно железный счетчик 32 разряда на уровне железа. Но есть (bat-backed) регистр где хранится старшая часть. Чтобы если оно дотикает до 2038 - не сдохло бы внезапно по дурной причине. А вся работа с временем таки в 64 битах. Хоть это и чуть более пухлый код на 32-бит платформе. Зато не подохнет внезапно в 2038, если к тому моменту это еще будет работать и будет кому-то надо. Потому что х...во когда железка внезапно взглюкивает по такой причине.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	283. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:05
	> А таки в результате на самом деле требуется "старшая часть" этого 32-битного > счетчика. И я такой костыль вбил даже на STM32 где именно > железный счетчик 32 разряда на уровне железа. Но есть (bat-backed) регистр > где хранится старшая часть. Чтобы если оно дотикает до 2038 - > не сдохло бы внезапно по дурной причине. А вся работа с > временем таки в 64 битах. Хоть это и чуть более пухлый > код на 32-бит платформе. Зато не подохнет внезапно в 2038, если > к тому моменту это еще будет работать и будет кому-то надо. > Потому что х...во когда железка внезапно взглюкивает по такой причине. С этим соображением я согласен. Если часы железные, то придётся менять железо. А оно вполне может быть живо к году Г, и даже незаменимо, если прикручено к какой-нибудь домне или станку за десять миллионов зелени или к чему похуже. Но наших серверов и персоналок этой всё не касается.
	Ответить | Правка | ^ к родителю #275 | Наверх | Cообщить модератору

	299. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 17:55
	> С этим соображением я согласен. Если часы железные, то придётся менять железо. Часы железные. Но - время из них я перегружаю лишь эпизодически, в основном при старте после ресета и все такое. А на самом деле оно живет в 64-бит переменной которая "никогда не переполнится" (по крайней мере, я до этого не доживу, и железяка тоже). Оно апдейтится по IRQ от RTC, но софт не видит 32-бит счетчик. Он ворочает 64-бит переменную. Это удобнее и безопаснее по математике и к тому же доступ к тому 32-бит счетчику специфичный, так что 64 бита в RAM как-то менее проблемны в целом, и иметь дело с ними может оказаться еще и быстрее. > А оно вполне может быть живо к году Г, и даже незаменимо, если прикручено к > какой-нибудь домне или станку за десять миллионов зелени или к чему похуже. Ну вот я не знаю заранее куда этот код и потомки этих железок будут в 2038 году прикручены и мне бы не хотелось чтобы меня вспомнили нелестным словом за такую отложенную по времени свинью. Поэтому в новых проектах этот момент я стараюсь учитывать. А хотя-бы и поступившись немного эффективностью кода. Потому что 64 бита на 32-битном ядре таки требуют больше кода. Так что с точки зрения только эффективности - меня можно за это и замесить.
	Ответить | Правка | ^ к родителю #283 | Наверх | Cообщить модератору

	278. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КО (?), 13-Дек-18, 16:48
	x32 нет, ибо там не честный x86, а с префиксами, т.е. не то не сё. Регистров больше чем в 32 битах, команды длиннее, памяти для приложения столько же. Да и толком не тестировал никто, как оно себя ведет.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	284. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:06
	> x32 нет, ибо там не честный x86, а с префиксами, т.е. не > то не сё. Регистров больше чем в 32 битах, команды длиннее, > памяти для приложения столько же. Да и толком не тестировал никто, > как оно себя ведет. Да и линукс с ним, я уже устал от этой дискуссии. :)
	Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

	126. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Проходил мимо (?), 13-Дек-18, 07:39
	> Я никак не могу представить себе, для чего, например, браузеру, мультимедийному проигрывателю, табличному процессору или текстовому редактору быть 64-битными. Если ты можешь назвать конкретные выгоды — назови. Мой браузер, после того, как откроет все окна и вкладки, которыми я пользуюсь, потребляет существенно больше, чем 4Гб памяти. Так что идите вы со своими 32 битами на маршрут по умолчанию.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	131. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (514), 13-Дек-18, 07:53
	> Мой браузер, после того, как откроет все окна и вкладки, которыми я > пользуюсь, потребляет существенно больше, чем 4Гб памяти. Так что идите вы > со своими 32 битами на маршрут по умолчанию. Твой браузер умеет работать в несколько процессов при необходимости. Проблемы могут быть только если одна вкладка выжрет 4ГиБ памяти.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	137. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Акакжев (?), 13-Дек-18, 08:17
	Деревья, списки и аналогичные используемые браузером структуры данных столько потребляют как раз из-за размера указателей.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	156. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 09:16
	> Деревья, списки и аналогичные используемые браузером структуры данных столько потребляют > как раз из-за размера указателей. Ну вот с некоторых пор даже в ИТ многие люди не понимают столь банальных основополагающих вещей.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	215. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (215), 13-Дек-18, 12:32
	> потребляет существенно больше, чем 4Гб памяти ... > Деревья, списки и аналогичные используемые браузером структуры данных столько потребляют как раз из-за размера указателей. Грубо говоря, если _существенно_ больше 4 ГБ и именно "из-за указателей", то, опять же очень грубо, разделив 4ГБ на два получим под 2ГБ - как раз близко к ограничению памяти для процесса на 32битной ОС (ну там конечно можно еще повыкручивать - пользовательскому процессу в выделенной виртуальной памяти отдать 3 гига, оставив 1 "технический" гиг под нужды ОС). Ну т.е. под картинки в сотнях вкладок уже ничего не останется. И не заводите шарманку про сотню открытых вкладок.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	225. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от www2 (??), 13-Дек-18, 13:14
	У каждой вкладки своё адресное пространство, если она обслуживается отдельным процессом. Внезапно, современные Chrome и Firefox работают именно так - запускают по отдельному процессу на каждую вкладку. Можешь запустить хоть 100 вкладок, каждая из которых будет жрать по 3 гигабайта, лишь бы у тебя было столько виртуальной памяти.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	265. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 16:00
	> У каждой вкладки своё адресное пространство, если она обслуживается отдельным процессом. > Внезапно, современные Chrome и Firefox работают именно так - запускают по > отдельному процессу на каждую вкладку. Можешь запустить хоть 100 вкладок, каждая > из которых будет жрать по 3 гигабайта, лишь бы у тебя > было столько виртуальной памяти. 294-й не понимает, что такое виртуальная память и её адресация. И в кучу к нему этого не понимают, судя по таким дискуссиям, 2/3 анонимов опеннета.
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	274. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 16:31
	Тот анонимус таки не 294 :P. Но общую идею вроде уловил и вещает нормально. Как там у стругацких было? Слепил дубля, отправил его на работу. Дубль получился туповатый... как-то так, да :)
	Ответить | Правка | ^ к родителю #265 | Наверх | Cообщить модератору

	165. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 10:07
	мы очень рады услышать что твой браузер - раздутое шпионское bloatware, но спрашивали - зачем оно такое, и какие выгоды ты получил от того, что оно не умещается в 4G (у меня - умещается, да, вкладок около сотни, но лишь десяток регулярно используемых. Да, разумеется он не 64битный.)
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	224. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от www2 (??), 13-Дек-18, 13:11
	Твой браузер работает в 64-битной системе и по умолчанию для всего целочисленного использует не 32, а 64 бита. Если его с теми же вкладками открыть в 32-битном режиме, он может и сожрёт существенно больше 4 гигабайт памяти, но сожрёт существенно меньше, чем жрал в 64-битном режиме. А если учесть, что современные браузеры умеют работать в многопроцессном режиме, то у каждого процесса будет своё адресное пространство в 4 гигабайта. На каждую вкладку приходится по одному процессу. В 4 гигабайта двухчасовой фильм на DVD умещается. Что там в браузере в одной вкладке может быть на 4 гигабайта?
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	174. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от Nuzhny (?), 13-Дек-18, 10:45
	Воинствующее невежество. 32-х битные программы на 64-битной ОС будут практически всегда работать медленнее, чем 64-х битные. Почему? Потому что для работы с этими самыми указателями надо будет производить в 2 раза больше ассемблерных инструкций (64-х битный можно просто положить в регистр одной командой). Размер указателей, как правило, очень слабо влияет на производительность, потому что программы пишутся для работы с данными, а не с указателями. Самые медленные программы - это обработка мультимедиа, архивация, научные расчёты. В них указателей мало, а самих данных много. Поэтому в случае с 64-х битыми программами поток команд уменьшается, обрабатываются данные быстрее (регистры стали больше), а в памяти по данным проигрыш совсем небольшой, на уровне погрешности. Теперь от теории перейдём к практике: 1. Ubuntu: https://www.phoronix.com/scan.php?page=article&item=ubuntu-1... 2. Windows: 2.1. https://www.passmark.com/forum/performancetest/283-comparing... 2.2. http://www.iinuu.eu/en/it-guru/windows-7-32-vs-64-bit-perfor... Тестирование всяких Фотошопов и т.п. ПО показывает примерно аналогичные цифры: 64-х битные программы выигрывают около 10-30%. Готов послушать контраргументы, подкреплённые тестами.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	228. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Совершенно другой аноним (?), 13-Дек-18, 13:34
	> 32-х битные программы на 64-битной ОС будут практически всегда работать медленнее, чем 64-х битные. нет, не поэтому. В архитектуре x86_64 банально вдвое больше регистров общего назначения, так-что хотя-бы за счёт этого - гораздо больше можно провести вычислений не производя чтение/запись из/в память. > Почему? Потому что для работы с этими самыми указателями надо будет производить в 2 раза больше ассемблерных инструкций (64-х битный можно просто положить в регистр одной командой). тут Вы неправы. В 32-х разрядной архитектуре размерность адресного пространства ограничена 4G - 32 бита, никаких доп.регистров там не требуется - при работе в 64-х разрядной ОС 32-х разрядное прикладной ПО будет ограничено 4G адресного пространства. Плюс, конечно, ОС должна знать и не выделять память сверх этого лимита. Кстати у 64-х разрядных программ и ОС есть и свои отрицательные моменты - как минимум вдвое большее потребление памяти при сохранении восстановлении контекста как задачи так и функций, просто их, как я понимаю, нивелирует кэш.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	247. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (243), 13-Дек-18, 15:11
	> нет, не поэтому. В архитектуре x86_64 банально вдвое больше регистров общего назначения, > так-что хотя-бы за счёт этого - гораздо больше можно провести вычислений > не производя чтение/запись из/в память. И еще гарантированный SSE2, так что можно и пачку SSE2 регистров еще приплюсовать. > 4G адресного пространства. Плюс, конечно, ОС должна знать и не выделять > память сверх этого лимита. Выделить более 4 гигз при 32 битах - еще ухитриться надо. Потому что вся математика к этому очень недружелюбна. > Кстати у 64-х разрядных программ и ОС есть и свои отрицательные моменты > - как минимум вдвое большее потребление памяти при сохранении восстановлении контекста > как задачи так и функций, просто их, как я понимаю, нивелирует кэш. Реально потребление растет процентов на 15-30. Вот никто и не хочет возиться. Тем более что юзерам будет периодически падать на бошку внезапный рояль с 20 этажа, в виде например падающего граф. редактора и проч, совершенно независимо от того сколько памяти воткнуто в комп.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	260. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Q2W (?), 13-Дек-18, 15:45
	У меня на 32-х битах всё работает быстро, а на 64-х свопится при трёх вкладках с джирой. Вот это вот факт. А то, что некоторые могут купить себе вагон памяти, сути дела для меня не меняет.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	289. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (289), 13-Дек-18, 17:23
	http://lurkmore.to/УМВР
	Ответить | Правка | ^ к родителю #260 | Наверх | Cообщить модератору

	229. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от meantraitor (?), 13-Дек-18, 13:47
	> При прочих равных 32-разрядный софт почти всегда лучше, быстрее и экономнее для ресурсов. Заканчивайте уже с этой ерундой. Это не так, если, конечно, у программистов руки растут откуда надо. К примеру, изо всех SPEC CPU2006 (26, что ли, их всего) только одна выиграла от x32. Других примеров, когда x32 кому-то помогло, я не знаю. Далее, если-таки вам в приложении нужно много указателей, но не нужно много памяти, то вам-таки необязательно использовать указатели ;) Возьмем, к примеру, компиляторный бэкенд, если вы знаете, что это такое. Казалось бы, в компиляторах все на указателях (см. LLVM). Однако же, когда мы портировали один такой бэкенд с 32- на 64-бита, потребление памяти у него увеличилось не более 10%, а работать он стал быстрее. А все потому, что его изначально писали люди с мозгами и прямыми руками. А не pointer-heavy приложения выигрывают от 64 бит обычно за счет большего числа регистров (и их размера) и передачи параметров через регистры, а не стек. Не говоря уже про SIMD.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	136. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Акакжев (?), 13-Дек-18, 08:12
	> пересобрал под него, не знаю, хромиум? Или firefox? # V8 upstream said they won't support x32, bug #423815
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	44. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+4 +/–
	Сообщение от Crazy Alex (ok), 13-Дек-18, 00:26
	Разницу между адресацией и выделением памяти лучше всё же понимать. memory-mapped files, всякие рандомизации адресов и подобное используют адресное пространство только в путь, да и другие применения есть. Я в своё время очень радовался x32, тем более, что вообще-то почти любой сложный софт активно манипулирует указателями - another level of indirection и всё такое. Но раз не взлетело - смысл тащить труп?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	48. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–3 +/–
	Сообщение от Michael Shigorin (ok), 13-Дек-18, 00:34
	Да, мы тоже посмотрели (и glebfm@ попримеривался) -- в итоге решили, что оно того не стоит даже с учётом вагона контейнеров прям у себя.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	455. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 15:49
	> Да, мы тоже посмотрели (и glebfm@ попримеривался) -- в итоге решили, что > оно того не стоит даже с учётом вагона контейнеров прям у себя. И правильно сделали. С нехваткой ресурсов как у альта на куда более прозаичные и базовые вещи, ввязаться в такую войну с ветряными мельницами было бы форменным донкихотством. За которое отдуются например, ваши пользователи.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	102. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от Аноним (514), 13-Дек-18, 05:14
	Практика показывает, что даже БД не используют memory-map огромных баз. Дело в том, что выигрыш совсем не очевиден. Ведь кеш-промах равносилен системному вызову read, но считано будет не столько, сколько нужно, а столько сколько ядро решит. Собственный кеш эффективней. А по поводу ненужности x32, я бы и рад использовать его на виртуалках, где мне взять Debian x32? Должен ли я часами компилировать Gentoo?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	168. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 10:14
	собрать один раз как тебе надо минимальный дистрибутив в котором ты хотя бы умеешь собирать пакеты и дальше его ставить там где нужен - не, не по силам? Собрать ядро, поставить на x86 дистрибутив и потихоньку собирать отдельные библиотеки и софт который реально может получить выигрыш от ускорения - тоже не? проходи мимо, очередь за божественной десяточкой вооон там стоит, открытый софт тебе бесполезен - даже в той малой мере, в которой он мог бы пригодиться. P.S. "даже бд", ага. Как раз БД-то пишут профессионалы (или хотя бы когда-то писали) а не гуанокодеры, и иногда их даже принято оптимизировать, а не "шлите еще денег, мы что-то перестали влезать в 64 бита, даешь 128".
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	177. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 10:47
	> P.S. "даже бд", ага. Как раз БД-то пишут профессионалы (или хотя бы > когда-то писали) а не гуанокодеры, и иногда их даже принято оптимизировать, > а не "шлите еще денег, мы что-то перестали влезать в 64 > бита, даешь 128". А вот пишут про будни профессионалов и даже немного в тему: https://vitus-wagner.dreamwidth.org/2041653.html
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	254. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 15:39
	Мне больше понравился turn-by-turn navigation :) http://www.wagner.pp.ru/~vitus/personal/village.html
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	249. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 15:18
	> собрать один раз как тебе надо минимальный дистрибутив в котором ты хотя > бы умеешь собирать пакеты и дальше его ставить там где нужен - не, не по силам? Ну как бы готовый дебиан раскатать - на порядки менее трудозатратно и куда как предсказуемее. Даже с debootstrap'ом и кастомизацией. А в своем минимальном дистре придется быть самому себе билдером, тестером, майнтайнером, QA, спецом по секурити и чем там еще. В общем такой себе человек-оркестр. И очень быстро окажется что объем работ - реально на целый оркестр. А так можно не мелочиться и вообще, написать свою операционку с нуля. И проги. Можно даже на ассемблере, чтобы еще эффективнее. Суперманьяки даже так пробовали, так появился колибри ОС. Но они уже подвыдохлись, устав от ассемблера, особенно когда с 32 на 64 захотелось. И что-то у них там уже какой-то c-- чтоли. Ща они еще сравнят с оптимизатором кода современного gcc, офигеют, и чего доброго проект задвинут совсем. Или на питоне с досады перепишут, так по крайней мере не надо 10 лет камасутрой заниматься, а результат однофигственный. > проходи мимо, очередь за божественной десяточкой вооон там стоит, открытый софт тебе > бесполезен - даже в той малой мере, в которой он мог бы пригодиться. Вот лично ты сколько коммерческих применений на открытом софте запилил, мистер эксперт?
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	294. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 13-Дек-18, 17:43
	> А в своем минимальном дистре придется быть самому себе билдером, тестером, майнтайнером, QA, > спецом по секурити и чем там еще. для пересборки чужих готовых пакетов - ничего из этого не требуется. А я себе в любом дистре - билдер, тестер и майнтейнер, потому что наверняка что-то отсутствует, что-то сделано не так и не там как мне хочется. Но, конечно, проще ждать ебилдов. Ждите, чо. > Вот лично ты сколько коммерческих применений на открытом софте запилил, мистер эксперт? что такое "коммерческое применение" ? и с чего вдруг мы перескочили от сборки для себя, любимого, дистрибутива с приглянувшейся архитектурой, к каким-то коммерческим применениям?
	Ответить | Правка | ^ к родителю #249 | Наверх | Cообщить модератору

	303. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:03
	> для пересборки чужих готовых пакетов - ничего из этого не требуется. Ну как бы если воспроизвести конфигу 1 в 1 как у популярного дистра - зачем тогда эта камасутра? Выигрыш в чем? А если конфига другая - ну тогда все новые заскоки ты и будешь сам разруливать. Поляна получится не вытоптанной, и соответственно плясать на ней станет сложнее. Это ради чего? > А я себе в любом дистре - билдер, тестер и майнтейнер, потому > что наверняка что-то отсутствует, что-то сделано не так и не там > как мне хочется. Но, конечно, проще ждать ебилдов. Ждите, чо. Ну я как бы сильно иногда и сильно некоторые программы к которым есть какой-то особый интерес разумеется билдую. Однако билдить так весь дистр - та еще камасутра, неизвестно ради чего, приводящая нас на невытоптанную поляну, где за все глюки отдуваемся мы и только мы. Это так офигенно! > что такое "коммерческое применение" ? Наверное, применение которое принесло бабки своим внедрением. Или хотя-бы сэкономило. > и с чего вдруг мы перескочили от сборки для себя, любимого, дистрибутива > с приглянувшейся архитектурой, к каким-то коммерческим применениям? Хм, а что, зарабатывать тем что нравится деньги уже стало чем-то зазорным? А мне так это дело почему-то очень нравится :). Без всяких десяточек с бэкдорами. Такое мне западло и самому использовать и клиентам давать. Не мой стиль!
	Ответить | Правка | ^ к родителю #294 | Наверх | Cообщить модератору

	330. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 13-Дек-18, 20:27
	> Ну как бы если воспроизвести конфигу 1 в 1 как у популярного дистра - зачем тогда эта > камасутра? Выигрыш в чем? так я что-то не понял - тебе нужна неподдерживаемая популярным дистром архитектура или нет? конфига другая в мелочах, большя часть содержимого /bin все еще собирается autoconf'ом, который используется там по назначению, а не модным meson'ом, поэтому очень многое чудесным образом соберется само, правильно определив архитектуру. Чему-то удастся помочь, найдя вопрос на stackoverflow (может даже и ответ). v8 починить - вероятно, не в силах человеческих. остальное придется взвесить на тему - оно лично тебе вообще зачем-то сдалось, или ну его нах, и собрать в 32 бита, благо оно на этой платформе выполняется. > Однако билдить так весь дистр эта задача вполне автоматизируема, да и не весь на самом деле нужен. > Наверное, применение которое принесло бабки своим внедрением. Или хотя-бы сэкономило. тоже как-то очень общо. Оно вот мое время сэкономило - которое во-первых, небесконечно, во-вторых платно. Тоже в общем-то бонус. А бабки своим внедрением - ну разьве что во времена Агавы, первый и последний раз я продавал именно установленную и работающую операционную систему как таковую, а не побочные эффекты ее работы. А система документооборота, платформы под которой я сейчас, к примеру, админю, денег не зарабатывает, и даже не экономит, деньги зарабатывают менеджеры впаривающие нужные и полезные бумажки ло...дорогим клиентам. Мы там расходная статья, как и большинство обычного IT. > Хм, а что, зарабатывать тем что нравится деньги уже стало чем-то зазорным? подмена темы "не могу сделать" на "зарабатывать" безусловно является зазорным. "не хочу делать потому что мне за это не заплатят ни копейки" - ну так с этого можно было начать.
	Ответить | Правка | ^ к родителю #303 | Наверх | Cообщить модератору

	404. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 14-Дек-18, 15:49
	> так я что-то не понял - тебе нужна неподдерживаемая популярным дистром архитектура или нет? Мне - нет. Вопрошавшему - хрен знает. Мной это рассматривается как весьма серьезная заявка на залет. Потому что долботни скорее всего будет необоснованно много, результат - весьма негарантированный, а плюшек которые бы реально оправдывали все эти жертвы - лично я не вижу. Поэтому я считаю это довольно х...вым tradeoff. > конфига другая в мелочах, большя часть содержимого /bin все еще собирается autoconf'ом, > который используется там по назначению, а не модным meson'ом, Однако даже просто кодогенерация и ABI там другие. И ты будешь для начала юзать плохо валидированный тулчейн, выхлоп которого вообще за все время запускало полтора анонимуса. Вот на себе и потестируешь все грабли, начиная с корректности кодогенерации и оптимизаций тулчейна. Офигенная перспектива, да? И нет, даже если автотулсы сработают прекрасно - это еще вовсе не гарантирует безглючной генерации кода, корректной работы либ и всего такого прочего :) Как очевидный пример: сжатие например довольно плотно завязано на арифметику с указателями. А зачастую и крипто. И вот этот код ты будешь валидировать и обезглючивать в нестандартной конфигурации как-нибудь сам. Или наслаждаться какими-нибудь багами из разряда черной магии, когда 3.5 сайта из 1000 почему-то не конектятся. А оказывается, это с конкретным сочетанием алгоритмов в недрах TLS что-то отваливается - и на ка вот тебе decryption error на ровном месте, так что конекта к сайту сегодня не будет. Еще более интересно будет если либа решит что платформа вроде 64 бита, а тут вдруг указатели почему-то 32. Так наверное и integer overflow и чудеса при работе с данными более 4G можно в принципе словить. В очень экзотичных сценариях. > многое чудесным образом соберется само, правильно определив архитектуру. Это однако абсолютно не гарантирует корректной работы программ, либ, кодогенераторов и проч. Ты будешь дергать экзотичное ABI c свойствами здорово отличными от того к чему привык типовой софт. Это хорошие стартовые условия чтобы собрать кучу глюков. Если тебе платят за число найденых багов - ты нашел клад. Но вот в остальных случаях это не клад а головняк. > Чему-то удастся помочь, найдя вопрос на stackoverflow (может даже и ответ). v8 починить > - вероятно, не в силах человеческих. Да там небось и qemu не заработает. По крайней мере full virt с трансляцией систем команд. Или заработает с такой скоростью что это будет просто пох. Потому что он и так то не ракета, трансляция команд даже с jit'ом то - прилично тормозит. > остальное придется взвесить на тему - оно лично тебе вообще зачем-то сдалось, > или ну его нах, и собрать в 32 бита, благо оно на этой платформе выполняется. Да вон все как-то взвесили ... и по большому счету дружно удрапали на 64 бита всей оравой. Так что там IA32 то скоро наверное в abandonware превратится, а уж маргинальное abi - и вообще не жилец. > эта задача вполне автоматизируема, да и не весь на самом деле нужен. Однако на это придется потратить человеческие ресурсы и машинное время. И как-то очень не факт что эти затраты себя достойно окупят. > тоже как-то очень общо. Оно вот мое время сэкономило - которое во-первых, > небесконечно, во-вторых платно. Тоже в общем-то бонус. Не догоняю как куча камасутры с непопулярным направлением может кому-то "сэкономить время", если уж про сабжа. > я продавал именно установленную и работающую операционную систему как таковую, а > не побочные эффекты ее работы. А почему побочные эффекты учитывать нельзя? Ну да, по большому счету кастомер хочет "решение". Однако без хорошей операционки на нормальных условиях - "решение" чисто технически не получится. И соответственно если ее не найдется - проект не состоится, кастомерских денег не видать. Или придется отдать львиную долю барыгам из майкрософта, так что придется пытаться развести клиента жестче и наглее чтобы и самому что-то досталось. И тогда выше вероятность что клиента не устроят соотношения, проект будет слит. Проприетарщики в этом плане вообще очень неудобные ребята, которые к тому же могут влегкую приложить рожей об стол в любой момент да так что фиг оспоришь. > А система документооборота, платформы под которой я сейчас, к примеру, админю, > денег не зарабатывает, и даже не экономит, Очень странно. Зачем ее тогда вообще внедрили? Я почему-то всегда думал что система документоооборота поднимает эффективность документооборота - и это собственно и есть аргумент за ее содержание :D. А если это не так - тогда смысл такой активности для меня становится большой загадкой. > деньги зарабатывают менеджеры впаривающие нужные и полезные бумажки ло...дорогим > клиентам. Мы там расходная статья, как и большинство обычного IT. Так может быть, менеджеры без такой системы будут работать, на минуточку, менее эффективно? И заработают меньше денег, потому что будут больше времени тратить на возню с документами? Которая сама по себе - опять же неизбежное техническое зло, не приносящее дохода. Ну а вот если система позволяет тратить на это меньше времени манагеров - она получает некий пойнт. А так то да, в принципе бизнес и бумажными документами ворочал. Да и сейчас местами ворочает до сих пор. Но вот с тем что это круто, быстро и эффективно - можно таки поспорить. Так, вспоминая как какие-то чуваки в ответ на взбрык, кажется, налоговой подрасперлись и таки выгрузили им бумажных документоа. Почти на товарный вагон. Я даже представить себе боюсь каки сколько ЭТО вообще обрабатывается. > подмена темы "не могу сделать" на "зарабатывать" безусловно является зазорным. По идее - если не сможешь сделать то и заработать не сможешь. Вроде бы логично. > "не хочу делать потому что мне за это не заплатят ни копейки" > - ну так с этого можно было начать. Тут даже чуть более глобально: проблема упомянутого начинания в том что соотношение возможного выигрыша с объемом потребной долботни - отбивает у большинства людей всякую охоту этим заниматься. Оплата может быть и не в копейках а в результате работинга. Но, видимо, он недостаточно впечатляющ и к тому же со своими минусами (как то более 4 гигз опачки). И вот заметь, гражданин КГБ вещает про то как надо. Но сам заниматься этим все-таки не хочет почему-то :)
	Ответить | Правка | ^ к родителю #330 | Наверх | Cообщить модератору

	409. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 16:38
	На почти все вопросы, которые здесь обсуждались, есть куда более простой и одновременно правильный ответ: из линуксячьего ведра выбрасывают всё то, что не нужно главным эксплуатантам.
	Ответить | Правка | ^ к родителю #404 | Наверх | Cообщить модератору

	411. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Ю.Т. (?), 14-Дек-18, 16:46
	> На почти все вопросы, которые здесь обсуждались, есть куда более простой и > одновременно правильный ответ: из линуксячьего ведра выбрасывают всё то, что не > нужно главным эксплуатантам. Как ни горько, но вероятнее всего именно так. Ведь то, что изделие переусложнилось и перетяжелилось, там отлично видят (причём первыми).
	Ответить | Правка | ^ к родителю #409 | Наверх | Cообщить модератору

	444. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 12:35
	> одновременно правильный ответ: из линуксячьего ведра выбрасывают всё то, что не > нужно главным эксплуатантам. Вариантов в общем то два: либо мусор вытряхивается, либо система превращается в помойку. Ну а жить на помойке лично я например не хочу. Всякие ГКБ СССР умильно конечно вещают, как и кто чего кто им там "должен", но сами впрягаться разгребать это они не хотят, а остальным оно на практике - нах и пох, близнецы братья! И тогда случается BIT ROT и балласт либо сбрасывается за борт, либо система превращается в свалку неподдерживаемого кода, как в некоторых *bsd. p.s. в линухе таки есть поддержка и довольно экзотичных штук, которые "главным эксплуатантам" просто до 3.14. Но эти штуки все же кто-то майнтайнит и использует. Если форумные эксперты вместо пиндежа на форуме и рассуждений про задолженности пойдут и будут майнтайнить и использовать - выкидывать стул из-под их задницы никто не будет. А вот "бабушкину рухлядь" которая за полвека сгнила и которой никто не пользуется - все же утилизируют.
	Ответить | Правка | ^ к родителю #409 | Наверх | Cообщить модератору

	448. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от КГБ СССР (?), 15-Дек-18, 13:25
	>> одновременно правильный ответ: из линуксячьего ведра выбрасывают всё то, что не >> нужно главным эксплуатантам. > Вариантов в общем то два: либо мусор вытряхивается, либо система превращается в > помойку. Ну а жить на помойке лично я например не хочу. Начинать такой разговор следует с того, что ляпчатое ведро всегда было помойкой, прямо вот с первых дней и по сейчас. Взлетело оно усилиями толпищ тогдашней хипстоты, напоминаю, единственно из-за того, что BSD жёстко тягали по судам. Никто в здравом уме не стал бы использовать эту помойку даже бесплатно, если бы за использование BSD не полагались весьма нешуточные санкции до окончания разборок с правообладателем Юникса. > Всякие ГКБ СССР умильно конечно вещают, как и кто чего кто им > там "должен", но сами впрягаться разгребать это они не хотят, а > остальным оно на практике - нах и пох, близнецы братья! И > тогда случается BIT ROT и балласт либо сбрасывается за борт, либо > система превращается в свалку неподдерживаемого кода, как в некоторых *bsd. А зачем это мне? Для моих скромных потребностей мне вполне хватает и того, что у меня уже есть. Я предпочитаю полноценные и эффективные программы и системы, написанные здравомыслящими людьми с руками из плечей, а не из низа спины. К сожалению, есть тренд убывания таких людей из экосистем BSD и MS, что заметно ухудшает качества операционных систем и других продуктов. Но, повторяю, вовсе не обязательно использовать всё самое новое. Более того — по ряду причин нежелательно использовать многий софт, выпущенный за прошедшие 10—15 лет. > p.s. в линухе таки есть поддержка и довольно экзотичных штук, которые "главным > эксплуатантам" просто до 3.14. Но эти штуки все же кто-то майнтайнит > и использует. Если форумные эксперты вместо пиндежа на форуме и рассуждений > про задолженности пойдут и будут майнтайнить и использовать - выкидывать стул > из-под их задницы никто не будет. А вот "бабушкину рухлядь" которая > за полвека сгнила и которой никто не пользуется - все же > утилизируют. Видишь ли, дорогой аноним, я на своём среднеевропейского калибра линуксе вертел этот ваш софтверный линукс. Мне ни тепло, ни холодно от происходящего после превращения его в GNU/Systemd. Если я вижу тенденцию замены в сообществе людей обезьянами, а хоть как-то приемлемых технологий булшитом, то пусть оно там в булшитном обезьяньем мирке и варится, а у меня достаточно приятных и полезных занятий в моей жизни. :-)
	Ответить | Правка | ^ к родителю #444 | Наверх | Cообщить модератору

	456. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (456), 15-Дек-18, 16:08
	> Начинать такой разговор следует с того, что ляпчатое ведро всегда было помойкой, > прямо вот с первых дней и по сейчас. В первые дни оно было значительно более хаотичной хипстерской мусоркой. Хипстеры повзрослели, набрались опыта, корпорасы показали им реальные задачи двуногих - и вот теперь, с этими знаниями и опытом, они смогли пересмотреть дизайн ряда подсистем. Не так как академики вообразили в своих абстракционных грезах сферического вакуума, а так как это потом еще и кому-то надо. И как лучше работает. ...поэтому благодаря этим людям я могу не пиндеть о прелестях юниксвэя из NT6 :P. > помойку даже бесплатно, если бы за использование BSD не полагались весьма > нешуточные санкции до окончания разборок с правообладателем Юникса. У BSD всегда были большие проблемы с project management. Это частный случай того самого. Эти бакланы не изволили изучить у кого какие права и вляпались. И платформу которая у Торвальдас не поддерживали. Ну и вообще, "бы" в этом мире не считается. Глядя на то как управляются бзды - я очень рад что есть Linux. А бзды ты как-нибудь используй сам. Фигли ты NT6 то козыряешь? :) > А зачем это мне? Для моих скромных потребностей мне вполне хватает и > того, что у меня уже есть. Ну тогда наверное и не тебе других учить о правильности вэев и концепций, коли продвигаемое тобой не сработало даже для тебя и твоих скромных потребностей. > Я предпочитаю полноценные и эффективные программы и системы, написанные > здравомыслящими людьми с руками из плечей, ...поэтому размахиваешь NT6 а вовсе и не BSD. > из экосистем BSD и MS, что заметно ухудшает качества операционных систем > и других продуктов. Ну так насколько я вижу... - BSD "по итогам" не способны обслужить даже скромные нужды кгб-шника, так что тот пиндит из NT6, делом доказывая чего стоят разглагольствования про вэи и управление проектами в BSD. - Нормальным про наверное все же западло подписываться под HTML5 пакостью с 2 наборами настроек, где основной фичой - кейлоггер. А ядро работает так что его извините вчерашняя студенческая поделка - чпх-пых в хвост и гриву по скорости большинства операций. > Более того — по ряду причин нежелательно использовать многий софт, выпущенный > за прошедшие 10—15 лет. Ну так никто ж не заставляет. Можешь играть музон в 2.95-м винампе, только не взыщи если кто захочет помайнить и эксплойт пришлет. Правда, есть надежда, что скоро это станет столь же немассово как win95 и основная масса хакеров на это подзабьет. > ваш софтверный линукс. Мне ни тепло, ни холодно от происходящего после > превращения его в GNU/Systemd. Зато мне так например вполне ничего. По крайней мере системд может нормальный вачдог апи мне вывесить в отличие от твоей sysv init наколенщины и даже в курсе кейсов когда программа не обязательно сетевая. > Если я вижу тенденцию замены в сообществе людей обезьянами, а хоть как-то > приемлемых технологий булшитом, то пусть оно там в булшитном обезьяньем мирке и варится, > а у меня достаточно приятных и полезных занятий в моей жизни. :-) Я как бы обезьянами и булшитом считаю людей и технологии по итогам того как это работает. И если ваш sysv init кладет на таймаут моего сервиса, предлагая мне самому кодить себе довольно вещь которую я за глаза считаю довольно базовой - ну знаете, кушайте свое добро сами, имхо. Вместе со своими вэйностями и концепциями. А вы что-то кушать это тоже не хотите и пиндите из NT6 в результате.
	Ответить | Правка | ^ к родителю #448 | Наверх | Cообщить модератору

	474. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 15-Дек-18, 21:35
	Наверняка ты был старостой класса, а потом группы или даже факультета, а ещё «комсомольским вожаком» и всё такое, ибо потрясающий талант к балабольству и передёргиваниям. Иди в политику, чувак, не закапывай в землю такой дар.
	Ответить | Правка | ^ к родителю #456 | Наверх | Cообщить модератору

	495. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 16:15
	> Наверняка ты был старостой класса, а потом группы или даже факультета, а > ещё «комсомольским вожаком» и всё такое, ибо потрясающий талант к балабольству > и передёргиваниям. У меня талант показывать некоторым рожам что мир несколько более многогранный и разнообразный чем они там в своей келье себе вообразили. И что если нечто случается, были какие-то причины на это. Всего лишь. > Иди в политику, чувак, не закапывай в землю такой дар. К сожалению российские политиканы больше всего напоминают мне орчьих варлордов. А с такими я дел не имею. Это дело принципа, на такой уровень плинтуса я рухнуть не готов.
	Ответить | Правка | ^ к родителю #474 | Наверх | Cообщить модератору

	517. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 16-Дек-18, 22:21
	>> Наверняка ты был старостой класса, а потом группы или даже факультета, а >> ещё «комсомольским вожаком» и всё такое, ибо потрясающий талант к балабольству >> и передёргиваниям. > У меня талант показывать некоторым рожам что мир несколько более многогранный и > разнообразный чем они там в своей келье себе вообразили. И что > если нечто случается, были какие-то причины на это. Всего лишь. Такой «талант» есть у каждой бабы с возраста согласия (и чем баба старше, тем талант сильнее). Называется — манипуляции (главным образом в стиле «сам дурак», «настоящий мужчина должен» и «сперва добейся»).
	Ответить | Правка | ^ к родителю #495 | Наверх | Cообщить модератору

	530. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 17-Дек-18, 07:51
	ИМХО ты меня с шигориным путаешь. А линух мне нравился и когда я был значительно моложе. Равно как я увидел весьма валидный пойнт и в GPL как таковом. ИМХО мне такие паттерны команды и управления проектом были бы симпатичны с момента когда я бы про них узнал и оказался в состоянии их осознать, при весьма разных возрастах. Кроме совсем уж юных, когда это было бы вне моего понимания. И кстати 1-м *nix-like которым я рулил была таки фрибзда. И так, потом, сравнив с даже просто RHEL/Centos которые подвернулись под руку а потом и дебианобразными, если что-то на этой планете и помойка - это фрибсд. По крайней мере с точки зрения управления системой это был кусок гемора. Даже по сравнению с тогдашними RHEL и Centos. Недавно до этих жирафов все же дотикало зачем люди пакетным менеджером пользуются, хы. Годиков через 10 наверное научатся и политики майнтайнерам вменяемо писать. А потом дотумкает и нахрена народ системд пользуется, глядишь. Только как обычно - с таким отставанием как будто все вокруг самые МакЛауды.
	Ответить | Правка | ^ к родителю #517 | Наверх | Cообщить модератору

	538. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 17-Дек-18, 09:01
	Любая потре***дь, не контролирующая навеянных извне позывов, для меня по определению баба. И вдвойне баба, когда включает манипулятивный аппарат. Я уже не раз писал: не трудись ляпать графоманские простыни, я их всё равно не читаю. По вышеназванной, как раз, причине. Ты в состоянии осознать, что никого не интересует история твоей болезни^W профессиональной, интеллектуальной и моральной деградации, которую ты подшиваешь к своим манипулятивным выпадам в качестве их обоснования?
	Ответить | Правка | ^ к родителю #530 | Наверх | Cообщить модератору

	447. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 15-Дек-18, 12:48
	> Однако даже просто кодогенерация и ABI там другие. И ты будешь для начала юзать плохо > валидированный тулчейн, выхлоп которого вообще за все время запускало полтора анонимуса. > Вот на себе и потестируешь все грабли, начиная с корректности кодогенерации и оптимизаций > тулчейна. Офигенная перспектива, да? ну да, если оно неинтересно - нефиг было и браться. > Это хорошие стартовые условия чтобы собрать кучу глюков. или отделить "типовой софт" от хорошо написанного. ;-) > Однако на это придется потратить человеческие ресурсы и машинное время. ну да, возвращаемся к исходному - "время разработчиков дорогое, давайте купим еще больше железа, которое еще через месяц устареет". > Очень странно. Зачем ее тогда вообще внедрили? Я почему-то всегда думал что система > документоооборота поднимает эффективность документооборота который тоже денег не зарабатывает. Он лишь помогает людям, которые это делают. Или мешает, по разному. Так что мы рангом лишь чуть выше уборщицы - можно в обгаженном офисе выписывать бумажки от руки, а можно в отмытом и чистеньком - и клиенты в общем-то скорее второй предпочтут при прочих равных, но претензии уборщицы что она "приносит деньги компании" мне кажется, немножко не поймутс. > По идее - если не сможешь сделать то и заработать не сможешь. Вроде бы логично. если сможешь сделать - возможно все равно не сможешь заработать. Ну вот собрал бы я себе такое для домашней помойки, если бы она не была гвоздем прибита вообще к ix86 - но вряд ли дальше пары виртуалок оно бы имело шансы распространиться при текущих бизнес-задачах. Но just for fun - вполне себе когда-то привело к появлению линукса как такового. Очень жаль, что модным-современным разработчикам не только не интересно (хотя для уважающего себя хакера такой гибрид ужа с ежом по-моему, вполне должен быть интересен), но они еще и норовят отломать и испортить побыстрее все, что мешает им пилить гранты и зарплаты разных фондов. > И вот заметь, гражданин КГБ вещает про то как надо. Но сам заниматься этим все-таки не > хочет почему-то :) ну потому что не в той области у него квалификация, и возраст уже тоже не тот. У меня на необычные околокомпьютерные хобби сил и времени уже нет, и не будет - я предпочитаю теперь собак. Там, если что, тоже все плохо с модными-современными тенденциями, но они хотя бы теплые и шерстяные.
	Ответить | Правка | ^ к родителю #404 | Наверх | Cообщить модератору

	458. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 17:03
	> ну да, если оно неинтересно - нефиг было и браться. Это уже вопросы к тем кто порт делал. Это был не я. Даже Шигорин продемонстрировал удивительно здравый смысл в оценке перспектив подобных начинаний. > или отделить "типовой софт" от хорошо написанного. ;-) И останется у тебя какой-нибудь qmail и djbdns. И еще пара десятков прог. И? :) > ну да, возвращаемся к исходному - "время разработчиков дорогое, давайте купим еще > больше железа, которое еще через месяц устареет". Ну так никто ж не может тебя заставить это делать. Если ты считаешь что тебе это менее выгодно чем пахать над сабжем - вперед на мины! > который тоже денег не зарабатывает. Он лишь помогает людям, которые это делают. Хорошо, возьмем самолет компании FedEx возящий почту. Никто не приносит деньги к трапу. Получается что пилот и самолет FedEx - некоммерческие? А зарабатывает только клерк в отделении компании? > Или мешает, по разному. Ну вот ставить систему которая только мешать будет - как мне кажется, никто все-таки не стал бы. Совсем провальные внедрения конечно бывают. Но их все же откатывают если бизнес хоть сколько-то парится операционной эффективностью. Не парятся разве что госы всякие, которым из бюджета накинут. У этих и спортзал в центре москвы убыточным бывает :D. > но претензии уборщицы что она "приносит деньги компании" мне кажется, немножко не поймутс. Если клиент придет в засpаный офиc, он дважды подумает иметь ли дело с такой компанией. > если сможешь сделать - возможно все равно не сможешь заработать. Ну как бы да, есть необходимые условия, а есть достаточные. Вот работающая операционка - это необходимое условие для решения на основе компьютеров. Но не достаточное. Хинт: если FedEx уволит всех водил и пилотов - кому их клерки в офисах станут нужны? Некоторые слишком ретивые эффективные менеджеры на этом таки иногда наобываются :). Ну вон фирму нокия MS так отменеджил, образцово-показательно вышло :) > Но just for fun - вполне себе когда-то привело к появлению линукса как такового. Дык fun нынче и поинтереснее найти можно. Когда линь взлетает на штуке с полкредитки - там и 32 бита никого не смущают. Хотя и там уже переход на 64 бита все-же идет. Даже не потому что памяти больше надо, а потому что считает все же быстрее в общем случае. > (хотя для уважающего себя хакера такой гибрид ужа с ежом по-моему, > вполне должен быть интересен), Для Настоящих Хакеров в мире появилось множество намного более интересных возможностей чем гальванизация всяких полутрупов. Ну вон I и Q сэмплы из броадкомского процыка для вайфая вынуть - для настоящих хакеров. И там даже куцая битность процыка никого не смутит. А на здоровенном мощном десктопе налетать на лимит в 4 гига - как-то глупо, чтоли, стало. > ну потому что не в той области у него квалификация, и возраст уже тоже не тот. А значит хакеры должны переться с перспектив обслуживания старческих чудачеств, вместо того чтобы заняться тем что им интересно, гы :) > У меня на необычные околокомпьютерные хобби сил и времени уже нет, и > не будет - я предпочитаю теперь собак. Ну, блин, так - значит так. В этом случае ты, соответственно, ничего сильно отспорить не сможешь. И будешь кушать что дают. Или как-то очень отдельно оплатишь причуды. В конце концов, макдональдс не перекроит меню для лично тебя. А персональный шефповар - возможен, но за весьма отдельные деньги, не идущие в сравнение с попсовым гамбургером, это уж ой.
	Ответить | Правка | ^ к родителю #447 | Наверх | Cообщить модератору

	459. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 15-Дек-18, 17:39
	> Ну, блин, так - значит так. В этом случае ты, соответственно, ничего > сильно отспорить не сможешь. И будешь кушать что дают. Или как-то > очень отдельно оплатишь причуды. Очень недальновидное отношение, даже глупое. Не говоря о том, какой климат таким образом создаётся в сообществе, проигнорировано то, что текущее поколение "типа молодых и энергичных" (типа хакеров) -- не наследственные владельцы того же линукс-ядра, и не они с нуля и до верху всё там сделали.
	Ответить | Правка | ^ к родителю #458 | Наверх | Cообщить модератору

	462. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 20:09
	> Очень недальновидное отношение, даже глупое. Как по мне, плясать бесплатно под чужую дудку, делая то что мне самому не надо - удовольствие ниже среднего. И на что-то такое я готов только эпизодически и при хорошей компенсации. Как еще понятнее это объяснить? :) > не наследственные владельцы того же линукс-ядра, и не они с нуля > и до верху всё там сделали. Наследственный владелец этого кода - Торвальдс и его команда. Я против них ничего не имею, они очень круты и эффективны. Я некоторым участникам этой команды даже пытаюсь подыгрывать в меру умений и талантов там где это актуально и мне и им. И это вроде бы работает. ...но типы с опеннета с своими вэйностями ко всему этому - отношения не имеют.
	Ответить | Правка | ^ к родителю #459 | Наверх | Cообщить модератору

	488. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 15-Дек-18, 23:21
	>> Очень недальновидное отношение, даже глупое. > Как по мне, плясать бесплатно под чужую дудку, делая то что мне > самому не надо - удовольствие ниже среднего. И на что-то такое > я готов только эпизодически и при хорошей компенсации. Как еще понятнее > это объяснить? :) Объяснять-разобъяснять не надо, это давно известная позиция. И лишь вопрос -- уместен ли и полезен ли такой подход в libre-проекте?
	Ответить | Правка | ^ к родителю #462 | Наверх | Cообщить модератору

	496. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 16:23
	> И лишь вопрос -- уместен ли и полезен ли такой подход в libre-проекте? Ну как бы тут каждый сам для себя отвечает на него, затевая проект. Дальше он пытается создать вокруг проекта ту или иную атмосферу. У кого-то получается, у кого-то не очень. Ну и глядя на проект мистера Торвальдса - я как-то не без причин полагаю что учить его делать опенсорсные проекты - дело неблагодарное. Потому что он умеет это намного лучше большинства землян, для начала. И трезвое понимание этого факта - первый шаг к реалистичной оценке своих сил и возможностей, чтоли. А если мы о ком-то другом - ну вот затевая открытый проект я наверное сделаю его прежде всего удобным себе. И постараюсь чтобы пришли те кому хочется приблизительно этого, примерно так же, после чего буду заботиться и об их удобстве - ожидая некоей симметрии в этом. А в вашем спиче - не фигурирую я и мое удобство. Соответственно у меня тоже нет причин заботиться о вас и вашем удобстве. Можете разрабатывать какой-нибудь hurd, тем временем работая в какой-нибудь мерзкой проприетарной конторе, с тупицей-шефом клюющим мозг и коллегами-пофигистами, если вам так больше нравится. Ну или как там выглядит ваш жизненный путь, чтобы еще и с голода в процессе не помереть. Потому что да, людям надо что-то жрать. И для меня намного лучше если я срублю себе на жрат занимаясь чем-то интересным и приятным мне, да еще и без деревяхи-шефа над головой, пожалуй.
	Ответить | Правка | ^ к родителю #488 | Наверх | Cообщить модератору

	497. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 16-Дек-18, 16:37
	> А в вашем спиче - не фигурирую я и мое удобство. Соответственно > у меня тоже нет причин заботиться о вас и вашем удобстве. Мы друг друга не понимаем. Кстати, не я разражаюсь здесь "спичами" по поводу и без.
	Ответить | Правка | ^ к родителю #496 | Наверх | Cообщить модератору

	531. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 17-Дек-18, 07:56
	> Мы друг друга не понимаем. Ага. На самом базовом уровне - вы явно не понимаете цели и мотивы участия людей в опенсорсных проектах. А я не только участвую в некоторых проектах, но и насмотрелся на достаточное количество народа в них. Поэтому имею нескромность полагать что некоторое понимание у меня все же появилось. > Кстати, не я разражаюсь здесь "спичами" по поводу и без. Да вообще-то сэр тоже лезет со своими поучениями жизни по поводу и без в каждую щель. Периодически напоминая мне, что есть класс людей, которые норовят сесть на шею своими хотелками, при том что помощи в проекте от них нифигища не дождешься. У выходцев exUSSR вообще есть офигительные замашки пытаться работать работу чужими руками. Ну а у меня есть иммунитет к этому ;)
	Ответить | Правка | ^ к родителю #497 | Наверх | Cообщить модератору

	537. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 08:59
	>> Мы друг друга не понимаем. > Ага. На самом базовом уровне - вы явно не понимаете цели и > мотивы участия людей в опенсорсных проектах. Глупость какая. Как раз понимаю, как и то, куда эти мотивы и цели ведут и приводят опенсорсные проекты. То есть внимание на бОльшую картину, а не только на сиюминутные хотелки ("цели и мотивации" отдельно взятого поколения). Между прочим, западные деятели это куда чётче понимают. >> Кстати, не я разражаюсь здесь "спичами" по поводу и без. > Да вообще-то сэр тоже лезет со своими поучениями жизни по поводу и > без в каждую щель. Сэры все в ЛондОне. А лезу, ну так участники здесь равноправны пока. *Зато* я это делаю *кратко* и держась достаточно узкого круга тем. Тем более я не пытаюсь выглядеть знающим обо всём. > Периодически напоминая мне, что есть класс людей, > которые норовят сесть на шею своими хотелками, при том что помощи > в проекте от них нифигища не дождешься. У выходцев exUSSR вообще > есть офигительные замашки пытаться работать работу чужими руками. Ну а у > меня есть иммунитет к этому ;) Такие глобальные заявления хорошо бы подкреплять ссылками на столь же глобальные исследования. А не чьим-то чуйством, что "все кругом ***, один я дартаньян". И даже в моём частном случае вы попадаете пальцем в небо.
	Ответить | Правка | ^ к родителю #531 | Наверх | Cообщить модератору

	468. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 15-Дек-18, 20:48
	>> ну да, если оно неинтересно - нефиг было и браться. > Это уже вопросы к тем кто порт делал. так мы про опенсорс или где? Порт я могу сделать - у меня, правда, как раз нет подходящей железки - имеющаяся почти подходящая, к сожалению, с закрытым драйвером ix86 only, поэтому мне в данный момент неинтересно. Мне непонятно, что мешает ноющим "а вот в репозиторий не положили". > И останется у тебя какой-нибудь qmail и djbdns. И еще пара десятков прог. И? :) да нет, думаю, если отвлечься от видео, останется почти все нужное - sendmail уж точно соберется. > Ну так никто ж не может тебя заставить это делать. могут - вот выпилят сейчас abi, и привет. Мои возможности ограничены, бесконечно сопровождать старое ведро я не смогу. > Дык fun нынче и поинтереснее найти можно. ну не знаю, что-то "поинтереснее", типа поддержки причудливых dsp, тоже уже выпилили давно. по-моему им интересно только бабло с "коммерческих дистрибутивов", на которые они без конца ссылаются. > В конце концов, макдональдс не перекроит меню для лично тебя. ну вот линукс это такой же макдональдс и стал - мерзкая рыгаловка с непомерными для такого качества ценами, единственной полезной фичей которой является общедоступный бесплатный сортир. удивительно, что горе-разработчикам на это начхать - но, видимо, бабло давно уже порешало. А поскольку мне неинтересно забесплатно работать уборщиком в макдональдсе - помогать им я точно ничем не планирую. И очень хочу найти работу подальше от модной-современной it-индустрии. выгул собак, пожалуй, выглядит пока максимально перспективно.
	Ответить | Правка | ^ к родителю #458 | Наверх | Cообщить модератору

	489. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 15-Дек-18, 23:23
	>> Ну так никто ж не может тебя заставить это делать. > могут - вот выпилят сейчас abi, и привет. ... > А поскольку мне неинтересно забесплатно работать уборщиком в макдональдсе - помогать им > я точно ничем не планирую. > И очень хочу найти работу подальше от модной-современной it-индустрии. Вот вы и (пере)открыли отчуждение. А ведь и выпиливаемое abi кто-то делал.
	Ответить | Правка | ^ к родителю #468 | Наверх | Cообщить модератору

	498. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (498), 16-Дек-18, 17:25
	> так мы про опенсорс или где? Порт я могу сделать - Да можешь, принцип опенсорца - форкай наздоровье, если здоровья хватает. Вопрос как раз в этом. > к сожалению, с закрытым драйвером ix86 only, поэтому мне в данный > момент неинтересно. Я не помню, влияет ли поддержка x32 ABI ядром для *программ* на что либо связанное с дровами ядра. Может и не влияет. Это ж прежле всего для программ новое ABI. А ядро остается вроде более-менее обычным 64-битным при этом. Но я этот режим не гонял - и поэтому это очень приблизительное понимание как там и что. Так что тапками сильно не кидаться. Ну вот не соблазнили меня декларируемые доводы и синтетика - так что плотно я это не изучал. > Мне непонятно, что мешает ноющим "а вот в репозиторий не положили". Ну как что. Это ж работу надо работать, а не на форуме ныть. При том бесплатно и в свое свободное время, вероятно, если никто не готов такое проспонсировать. И тут то и оказывается что морковка походу не такая уж и сладкая, и не очень то и нужна. Вот если кто другой сделает сэру ЗБС... но для них морковка тоже походу кажется не очень сладкой. Deadlock. И сколько ни вопи о том что она все-же сладкая, это не убедительно, особенно когда якобы "фанаты марки" ныкаются по шестым нтям или где там еще. > да нет, думаю, если отвлечься от видео, останется почти все нужное - > sendmail уж точно соберется. Мне, пожалуй, так по жизни - видео понужнее sendmail'а будет. > могут - вот выпилят сейчас abi, и привет. Мои возможности ограничены, бесконечно > сопровождать старое ведро я не смогу. Ну так тут то и встает вопрос ребром - хватает ли здоровья. И таки если ты этим реально пользуешься - ну тогда во первых отпиши в рассылке, а во вторых изволь способствовать майнтенансу этой штуки так кли иначе. А теоретические пользователи, которые может быть, когда нибудь, а как до дела так в кусты и то лепят отмазы то вообще 6м НТ размахивают - никого не интересуют. Разработчики не первый год замужем и такой наглый перевод стрелок с больной головы на здоровую - не получится и в проекте. > ну не знаю, что-то "поинтереснее", типа поддержки причудливых dsp, тоже уже выпилили давно. Ну так одно выпилили, другое запилили. Как железки перестали выпускать и не осталось тех кто хотел бы майнтайнить код - так и отправилось восвояси. В ядре никто не настроен разводить bit rot. Поэтому поддержка железа живет столько сколько это кому-то надо. Ну вон например 68К доисторический - до сих пор в майнлайне. Но там народ с этим железом есть, майнтайнит это дело, подрихтовывая по мере необходимости под изменения остального ядра. И в таком виде всем плевать что это архидревнее железо и даже давно не выпускается. Но тут заслуга народа который извините готов себе попку сам подтирать. В таком виде против древней архитектуры никто ничего не имеет. А если начинаются потуги перепиха своих проблем на других - вот тут ой. Очень быстро вынут факи из кармана и объяснят как делать не надо, превентивно задропав источник головняка. Такова жизнь. > по-моему им интересно только бабло с "коммерческих дистрибутивов", на которые они без > конца ссылаются. Ну не знаю, кто-то даже 68К пилит. А так вообще-то нормальное человеческое желание еще и денег за свою работу получать. По-моему так прикольно когда за работу которая тебе по приколу еще и денег платят. А вот ходить на работу которая ничего кроме отвращения не вызывает - мне почему-то не хочется. А людям надо что-то жрать, в сутках только 24 часа, и поэтому совсем уж игнорить этот вопрос большинство людей все же не может. > ну вот линукс это такой же макдональдс и стал - мерзкая рыгаловка Ну тут как бы можно поспорить. Проблема в том что остальные еще хуже. - Когда вы заходите в кафе мс вам подгоняют смузи из плесневелого кефира и гнилых бананов, рассказывая что это самый смак. На хвост садится пара шпиков. И даже если вы адаптировались к жратве и научились дурить шпиков, завтра маркетинг перекроит меню - будете любить мухоморы. Или помирать с голода, потому что в еду что-то подмешивали и теперь вы можете заправляться только там, от остальных заведений вас крючит. - Мак ламурно, шикарно, кормят иногда прилично. Но тоже подмешивают что-то и зачем-то к стулу приматывают цепями с позолотой. А когда наступает время платить, выносят паяльник с позолоченым жалом. Так клиент сговорчивее насчет чаевых, подписывается что меню зашибись и рассылает 10 инвайтов дружбанам. Шпик на всякий случай тоже садится на хвост. - Бзды тусовка олдскульных хиппи. Признают только спирт не менее 90 градусов и мексиканскую кухню. Если изо рта не идет огонь - это не еда! Могут показывать фокусы в цирке. Но в тайне от других заправляются в первых двух забегаловках, залечивая ожоги и печень. Это не по пацански, на публике такое малодушие всячески отрицается. - Hurd - это такие олдскульные хиппи. Денег нет, ресурсов нет. Готовить не умеют. Но с удовольствием зарубятся с любым шефповаром на тему правильной готовки мыша на костре. Правда, результат только сами хиппи и жрут. ...ну и вот на фоне какого-то такого ассортимента, макдональдсобразный линукс пожалуй не самая плохая из опций :) > с непомерными для такого качества ценами, единственной полезной фичей которой является > общедоступный бесплатный сортир. Ты так говоришь, как будто линуксоиды тебя пинками туда загнали и заставили юзать именно это. А, да, макдональдс имеет славу сети бесплатных туалетов. Достаточно неплохих по сравнению с остальными заведениями такого типа, btw. А у упомянутых - либо полтос баксов за вход и шпион-вуайерист, либо вон там хиппи в заснеженном поле вдалеке, иди к ним, это бесплатно, типа :) > видимо, бабло давно уже порешало. Ну как бы людям надо что-то жрать. И как бы если что-то хорошо умеешь - логично этим и зарабатывать себе на жизнь наверное. А не так как лицемерные рожи, нахваливающие одно а зарабатывающие другим. Демонстрируя что их подходы не работают даже для поддержания на плаву того кто подход рекламил. Блин, а остальным зачем эта лодка которая не плавает?! > А поскольку мне неинтересно забесплатно работать уборщиком в макдональдсе - помогать им > я точно ничем не планирую. Ну и тебе тогда помогать никто не будет. И тогда в чем прикол пытаться качать права? Дураков нет. Особенно - среди разработчиков линя. > И очень хочу найти работу подальше от модной-современной it-индустрии. Ну как бы готовность оплачивать работу - зависит от нужности работы. И если в целом люди решат что такой работинг им не надо - будет тяжко. Хотя при очень сильном желании ты можешь до сих пор устроиться хоть инструктором верховой езды. Но желание потребуется сильное, и это скорее всего будет не в соседнем квартале. Возможно даже придется сменить место обитания. Но тем кому очень принципиально - таки решают вопрос. Другое дело что это весьма немассово и в целом общество ставит некий фильтр, потому что в целом потребность в такой работе крайне низкая. Так что среднего пошиба конюху средних веков - ничего не светит. > выгул собак, пожалуй, выглядит пока максимально перспективно. Тут уж кому что. А мне вот не очень интересно собак выгуливать. Цифровые технологии мне как-то больше по кайфу. И собственно по этой причине я тебя и не буду слушать на предмет того что есть хорошо. Не хочется мне выгулом собак заниматься пока :)
	Ответить | Правка | ^ к родителю #468 | Наверх | Cообщить модератору

	181. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Moomintroll (ok), 13-Дек-18, 11:06
	> где мне взять Debian x32? https://wiki.debian.org/X32Port
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	202. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 12:06
	это ты ему машину времени посоветовал, да? debian sid, прекрасный древний артефакт
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	256. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 15:43
	> https://wiki.debian.org/X32Port Как бы https://www.debian.org/ports/ уже давно висит в "in progress" что намекает на состояние и живость порта.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	220. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (220), 13-Дек-18, 12:56
	> равносилен системному вызову read, но считано будет не столько, сколько нужно, а столько сколько ядро решит Системный вызов read тоже прочитает "не столько, сколько нужно, а столько сколько ядро решит", только если для memory-map ядро может (как минимум, теоретически) просто вернуть указатель на содержимое системного кэша с расшариванием физических страниц между разными процессами, то при использовании read гарантированно будет копирование в память процесса с дублированием прочитанных данных во всё том же системном кэше. Тут именно что "выигрыш совсем не очевиден".
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	304. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:06
	> Системный вызов read тоже прочитает "не столько, сколько нужно, а столько сколько > ядро решит", И таки если это меньше чем запрошено, это если и не ошибка то как минимум ситуация требующая весьма отдельного внимания. А так то да, posix'ное апи мягко говоря не подарок и там много всяких очень интересных дeбилизмов накопилось за годы.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

	221. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (221), 13-Дек-18, 12:58
	> Прочтите интервью с доченькой Линуса I'm actually not active in particular open source communities. I feel much more comfortable discussing computing with other w̶o̶m̶e̶n̶  openneters Да это же про нас!
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	273. "Разработчики ядра Linux обсуждают вопрос удаления..."	+/–
	Сообщение от arisu (ok), 13-Дек-18, 16:30
	> Прочтите интервью с доченькой Линуса спасибо. а зачем? кто это такая, и почему меня должно волновать интервью с ней? намекаю, если кто вдруг забыл: FOSS не монархия, посты по наследству не передаются.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	286. "Разработчики ядра Linux обсуждают вопрос удаления..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:08
	Для общего развития. Для представления о трендах. Как там было с сообществом Гнома? Все деньги прос… инвестировали в дайверсити и против харразмента. И как там с FSF? полмиллиона на фуршеты и буклеты. Вместо того, чтобы доделать Hurd, например.
	Ответить | Правка | ^ к родителю #273 | Наверх | Cообщить модератору

	338. "Разработчики ядра Linux обсуждают вопрос удаления..."	–1 +/–
	Сообщение от Аноним (-), 13-Дек-18, 21:47
	> как там с FSF? полмиллиона на фуршеты и буклеты. Вместо того, Как бы фуршеты и буклеты тоже нужны - для продвижения FSF и их идей. > чтобы доделать Hurd, например. Был бы он кому-то всерьез нужен - давно бы доделали.
	Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

	354. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (354), 14-Дек-18, 01:09
	> борьба за равенство и против харазмента и гендерного шовинизма. Проблема в том, что штатах это идет отдельным предметом в колледжах/унивеситетах/институтах - соответственно после полугодовой еженедельной прокачки психика бывших школьников даёт трещину и они начинают бороться с воображаемыми врагами, ни на жизнь, а на смерть. Представь, ты должен на отлично написать курсовую на тему "как я победю харасмент и гендерный шовинизм в моей семье/компании/стране" - обратного пути уже не будет - вокруг враги и несправедливость!
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	359. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Васёк (?), 14-Дек-18, 04:33
	Таки она страшная! Лучше бы мужик родился, Торвальдс красивее своей жены
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	362. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (362), 14-Дек-18, 05:13
	> Ведь всем известно, что типичному приложению жизненно необходимо адресовать более 4 гигов памяти. Что? Экономия? Пусть мясные докупят ещё оперативной памяти и новый процессор! Все претензии к разработчикам дистрибутивов. Разработчики ядра поддерживали x32 несколько лет, и если бы за это время дистрибутивы начали ее полноценно использовать, удаление бы сейчас обсуждалось.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	363. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (362), 14-Дек-18, 05:15
	> использовать, удаление бы сейчас обсуждалось. * не обсуждалось
	Ответить | Правка | ^ к родителю #362 | Наверх | Cообщить модератору

	366. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 08:01
	По состоянию на конец 2018-го года я знаю только один дистрибутив линукса — GNU/Systemd. Это который для контейнеров и докеров, чтоб девляпсам удобненько было. Ключевые разработчики этого дистрибутива не заинтересованы в развитии устаревших и компромиссных технологий, поскольку Linux наш новый стандарт и stable API is nonsense.
	Ответить | Правка | ^ к родителю #362 | Наверх | Cообщить модератору

	463. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 20:11
	Anonymoustus'у из его NT6 видней, конечно, за линукс...
	Ответить | Правка | ^ к родителю #366 | Наверх | Cообщить модератору

8. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (17), 12-Дек-18, 23:04
> В своё время при тестировании x32, один из разработчиков Gentoo пришёл к выводу, что выигрыш в производительности при переходе на x32 ABI не столь велик Под производительностью, я так понимаю, понимается скорость работы кода, запущенного на машине с потенциально бесконечным количеством памяти? Что насчёт ограниченного объёма памяти? Кто-нибудь тестировал?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (10), 12-Дек-18, 23:09
	Экономия небольшая, браузеры не работают
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	15. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от GentooBoy (ok), 12-Дек-18, 23:14
	ну экономия насколько помню была большая, где то 30%. что очень существенно когда у тебя 4гб.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	22. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (22), 12-Дек-18, 23:32
	> ну экономия насколько помню была большая, где то 30%. что очень существенно > когда у тебя 4гб. В меня подгорает: у меня вообще 2. Если уже 4 считается непозволительно мало, то это ппц, так как ddr2 хрен докупишь, особенно если плата поддерживает максимум 8 гигов при отказе от двухканального режима и использовании максимальных таймингов.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	27. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+7 +/–
	Сообщение от КГБ СССР (?), 12-Дек-18, 23:42
	>> ну экономия насколько помню была большая, где то 30%. что очень существенно >> когда у тебя 4гб. > В меня подгорает: у меня вообще 2. Если уже 4 считается непозволительно > мало, то это ппц, так как ddr2 хрен докупишь, особенно если > плата поддерживает максимум 8 гигов при отказе от двухканального режима и > использовании максимальных таймингов. А ещё есть такой класс устройств как ноутбуки на чудесных интеловских чипсетах, не позволяющих использовать памяти больше 1, 2 или 3 с небольшим гигов. Таких ноутбуков на руках несметные количества (лично у меня есть аж три штуки). Но чистые помыслами прихожане Церкви Прогресса непременно посоветуют в самых любезных выражениях купить новый ноутбук, а через год — ещё один, а а ещё через год — снова покупать.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	74. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Crazy Alex (ok), 13-Дек-18, 01:46
	Скажем так - я на трёх гигах сидел долго, и это было крайне неуютно даже с моими скромными потребностями (x86, без DE, в браузере жёстко режется всё и вся, JS для большинства страниц отключён, гента, софт подобран так, чтобы жрать минимум). На x32 жрало бы больше. Уж не знаю, что там с этими буками про процессору/видео, но в плане памяти из них сейчас мало что получится выжать.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	79. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Анонимчжан (?), 13-Дек-18, 02:03
	пересобрать с флагами оптимизации забыли.)))) и вообще я за ассемблер . достали говнокодеры)))
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	86. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 02:18
	Да и канонического Си бы хватило, а где надо безопасно и надёжно — там Ада к месту, а где надо писать для бизнеса и финансов — там Кобол. И так по всему списку инструментов и средств. Всё ведь уже придумали до нас — нам только пользоваться да радоваться. Но кому-то всегда страшно зудит от сидрома NIH.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	285. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 17:08
	> Да и канонического Си бы хватило, А вот с этим можно поспорить... Added SSE4_1 variant support of horizontal, vertical, identity txfm types for     txfm blk_sizes 4x4,4x8,8x4,4x16 and 16x4.          Module level gains:     Tx_size   Gain w.r.t. C     4x4        5.58x     4x8        4.65x     8x4        5.00x     4x16       4.63x     16x4       5.70x "Один день из жизни libaom"
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	296. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:51
	Ни в коем случае не стану отрицать полезность и где-то даже нужность расширений, которые прикручивают к ЦПУ, однако имею особое мнение, что для многих из них было бы правильно делать отдельный специализированный процессор. Например, для шифрования. И для мультимедии. В идеале — чтоб на материнках были «кроватки» для таких спецпроцессоров, как в старые добрые времена: хочешь — докупай и устанавливай, не хочешь — сэкономь пару копеек. Правда, у Интела изрядно бы похудели прибыли в этом случае. Да ещё и разнообразие и конкуренция вдруг бы вернулись…
	Ответить | Правка | ^ к родителю #285 | Наверх | Cообщить модератору

	305. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:13
	> многих из них было бы правильно делать отдельный специализированный процессор. Вон GPU есть, если кто еще не заметил. Хренова куча SIMD крупным оптом. Мало чтоли? Все майнеры и крякеры паролей ими давно и пользуются. > и устанавливай, не хочешь — сэкономь пару копеек. Кому сильно надо - криптоакселераторы таки есть. Если GPU мало - есть и более специализированные. Но, конечно, не в кроватку а в какой-нибудь PCI-E x16, такие потоки данных уместнее куда-то туда. А с более маргинальными потоками и системный проц справится. Ну или GPU, если надо много и параллельно. > Правда, у Интела изрядно бы похудели прибыли в этом случае. Да ещё и > разнообразие и конкуренция вдруг бы вернулись… На самом деле кому оно было реально надо - давно все есть. Майнеры одно время так вообще вынесли все топовые amd-хи на рынке. А нвидия кстати выкусила фигу с потугой карты под майнинг делать. Может и потому что проприетарный драйвер в лине все же боль, и вообще у нвидии в среде майнеров репутация не очень, дорого, бестолково, проблемно.
	Ответить | Правка | ^ к родителю #296 | Наверх | Cообщить модератору

	307. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 18:36
	Это всё не то и про другое. Сейчас если людям хочется быстрого шифрования, то приходится покупать интеловский процессор за несколько сотен вечнозелёных единиц. А в случае отдельных специализированных процессоров и простого ЦПУ дело бы ограничилось несколькими десятками. А в микроэлектронике навар, напоминаю, зависит главным образом от коэффициента розничной цены куска «сверхчистого песка». Неспроста Штеуд с давних пор пытается всё, что только можно, запихнуть в ЦПУ. Юзеру фактически приходится переплачивать тысячи процентов против реальной стоимости товара.
	Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

	325. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 20:18
	> Это всё не то и про другое. Сейчас если людям хочется быстрого > шифрования, то приходится покупать интеловский процессор за несколько сотен вечнозелёных единиц. Ряд софта таки научился в GPGPU на этой почве. Для TLS есть криптоакселераторы, если уж реально надо. А кому еще крипто крупным оптом надо и где, что системный проц напрягается? > А в случае отдельных специализированных процессоров и простого ЦПУ дело > бы ограничилось несколькими десятками. Ну как бы для начала системный проц вообще у всех нахаляву есть. И современное шифрование обычно под него и подогнано более-менее. И таки сейчас - под 64 бита оптимизировано. Поэтому на 32 битах оно как-то работает, конечно, но на 64 - быстрее в разы. А потому что 64-битные операции и по регистрам раскладывается как раз. Алгоритмы и их реализации эволюционировали в сторону чтобы популярным процам было удобно. Местами икается - на микроконтроллерах, даже 32-битные, эффективные реализации крипто найти - затея не из простых. А какие-нибудь 8-битники вообще в конкретном пролете. > А в микроэлектронике навар, напоминаю, зависит главным образом от коэффициента > розничной цены куска «сверхчистого песка». Вообще-то он зависит от тиражей. Потому что в R&D - изволь, маски и прочее - изволь, так что несколько мегабаксов вынь да полож. А потом можешь 10 чипов нашлепать, или 10 миллионов. Само шлепание то может и будет по цене песка, но вон те миллионы отбить надо. И это или убердорогой кастом в 10 чипов, или ты пытаешься кому-то впарить 10 миллионов чипов, чтобы они не были дорогими. При этом они занимают место на складе, аренда склада стоит бабла и покуда ты их не продал - залетаешь на бабки просто за сам факт хранения. И вот тут возникает дилемма: не сильно попсовое решение не может быть дешевым. Дорогое решение не может быть попсовым. Это бесконечный цикл. Сломать его ухитряются лишь некоторые. И то что это сработает для предложенной штуки - ну вот вообще совсем не факт. Я бы оценил что этот проект никогда не отобьет затраты на него с высокой вероятностью. Так что тот кто ввяжется потом еще и должен всем по уши окажется. А если что-то встраивать в процессор/чипсет как фичу - там всех очень колышет площадь кристалла сжираемая фичой. И таки полновесный могучий криптопроцессор и мелкая специфичная для задачи железка AES - две большие разницы в этом плане. Когда чип большой, чем больше площадь тем ниже вероятность что он заведется после выпечки. И тем меньше чипов на вафле. Это удорожает чипы и снижает выход. Заметный профит будет далеко не у всех. > Неспроста Штеуд с давних пор пытается всё, что только можно, запихнуть > в ЦПУ. Юзеру фактически приходится переплачивать тысячи процентов против реальной стоимости товара. Ну как бы дополнительный чип - это дополнительные несколько мегабаксов на его выпуск. Аргумент даже для интела. Особенно когда нет уверенности что это отобьется на раз.
	Ответить | Правка | ^ к родителю #307 | Наверх | Cообщить модератору

	344. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (22), 13-Дек-18, 23:07
	криптоакселераторы не могут быть не в процессоре. Иначе нешифрованные данные придётся гнать в память и по шине, а это - перехват любой аппаратной закладкой.
	Ответить | Правка | ^ к родителю #307 | Наверх | Cообщить модератору

	469. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 20:59
	> криптоакселераторы не могут быть не в процессоре. Очень спорное утверждение. Подразумевающее к тому же что аноним сам сделал себе проц и поэтому уверен в его начинке больше чем во всем остальном. ...хотя некий пойнт есть: для high-secure применений штуки типа микроконтроллеров для атакующих очень неудобны, потому что ключ в внутренней памяти и слямзить его оттуда нельзя. Но у x86 систем все извините в RAM на внешней шине, для начала. И между делом, пропатчить данные на этой шине при сильном желании - возможно. Перехватив инициативу. Для PS3 такой фокус даже был продемонстрирован - так гражданин Геохот положил на хренову кучу цифровых подписей, шифрование и прочий DRM. Но вот как сколь-нибудь попсовая атака для незаметного тыринга ключей это все же проблематично. > Иначе нешифрованные данные придётся гнать в память и по шине, > а это - перехват любой аппаратной закладкой. Перехват pci-e с десятками гб/сек - это круто. Особенно чтобы это не тормозило и чтобы делало что-нибудь полезное. Ну, для начала, есть у нас 10 гигов в секунду. Что с этим делать и куда это девать? А, второй компьютер поставить и там процессить? Блин, это дешево и незаметно не получается, а закладка в виде отдельного мощного компа способного хотя-бы складировать такой поток очень уж паливно выглядит.
	Ответить | Правка | ^ к родителю #344 | Наверх | Cообщить модератору

	83. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 02:14
	Если не использовать негодный софт, написанный обезьянами, то достаточно и намного меньшего количества памяти и других ресурсов. На порядок меньше. Если, конечно, ты понимаешь, на что на самом деле тратится вся та прорва современной памяти и зачем процессоры греют воздух, и сколько в этих «накладных расходах» выполняется чего-то хоть мало-мальски полезного. Поразительно, что в ИТ, главным смыслом существования которых являются эффективность и рациональность, воплощённые в обслуживании _других_ областей человеческой жизнедеятельности, эти самые эффективность и рациональность ни во что не ставят. Впрочем, «дешёвый кремний» уже закончился. Да, навсегда. Учитесь жить в новых условиях.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	143. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Онаним (?), 13-Дек-18, 08:42
	Эффективность и рациональность заключается в том, что чем тратить 100500 ДОРОГУЩИХ человекочасов на поддержание в полуживом состоянии ненужно (например такое извращение, как x32), проще добавить в систему RAM, которая стоит копейки.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	151. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 08:56
	Это не эффективность и не рациональность, а экстенсивный (количественный) способ изменения чего-либо. Обязательно ведёт к деградации отрасли. Например, экстенсивный способ ведения сельского хозяйства приводит к истощению и приведению в негодность земель. Человекочасы, по моему личному мнению, чудовищно переоценены. Программистская работа в большинстве случаев не заслуживает такой оплаты. Программирование — сравнительно простая и доступная практически всем прикладная и обслуживающая деятельность, которая в норме должна служить решению задач из реальной жизни. Это не должно быть отдельной индустрией, ежегодно выкачивающей из общества триллионы долларов для малоизвестных публике инвестиционных компаний (которые стоят за спиной всех софтверных). Но, как я уже сказал, дешёвый кремний закончился. Думаю, что через какое-то время (предположительно — после фиаско с ИИ и автопилотами в автопроме, ибо речь пойдёт о безопасности и жизни людей) произойдёт крах невероятно раздутых пустых капитализаций софтверных компаний и всё вернётся примерно к тому виду, как было в семидесятых. Кто из кодописов действительно умеет решать инженерные задачи, будут иметь работу. Остальные отправятся подметать улицы и носить ящики.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	164. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Crazy Alex (ok), 13-Дек-18, 09:56
	О, понятно, с кем дискутировать бессмысленно. Фиаско ии и автопилотов, говорите?
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	167. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 10:14
	> О, понятно, с кем дискутировать бессмысленно. Фиаско ии и автопилотов, говорите? Желаете заключить пари?
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	288. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 17:16
	> Желаете заключить пари? Критерии в студию. А то что-то автопилоты теснят человека на всех фронтах. Даже у консервативных как черти что больших авиаторов - у эйрбаса компьютеры таки строят пилота в flifgt envelope уже. Тягай, не тягай, компьютер лучше знает сколько безопасно и больше этого порулить не даст. Автоматические поезда без машиниста - в общем то никого и не удивляют уже. Ракеты так и вовсе отродясь летали по программе, сперва командоаппаратом, потом компьютерами - там человек при всем желании не успеет рулить с нужной скоростью. А не отпарировать как надо и быстро - что бывает с ракетой дальше - можно посмотреть в ролике роскосмоса "кажется что-то идет не так". На это кстати прозрачно намекали типу делающему турбореактивный hoverboard, полагающему что он сможет без гироакселей и системы управления сам вытянуть. Ему и намекнули на перспективу разгона движками башкой в асфальт. Француз который такое достроил - таки гироаксели и систему управления воткнул, видимо прочухав это дело :)
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	291. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:34
	Идиллия заканчивается, когда вдруг в СМИ пробегает статья о том, например, что пилотов обязали рулить вручную, потому что у бота в нештатных ситуациях нет варианта «принять нестандартное решение», а по стандартному он убьёт борт вместе с пассажирами. :) Ну и ж поезда таки ездят с машинистами. Для отработки множества «нестандартных ситуаций». Например, когда сломались светофоры. Или позвонили девочки из колл-центра^W диспетчерской и неформально попросили машиниста опоздать и пропустить другой состав («ну а чо такова? ты всё равно дрова везёшь»), потому что тому другому очень-очень надо, он рок-звезду с барабанами и гитарами везёт на концерт. Или просто стрелка (внезапно!) неисправна не туда направила. Робот в таких обстоятельствах и свой состав сломает, и всё движение в данной области. А с автомобилями всё значительно сложнее, потому что трафик и водятлы, каждый из которых Индивидуальность.
	Ответить | Правка | ^ к родителю #288 | Наверх | Cообщить модератору

	308. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:36
	> Идиллия заканчивается, когда вдруг в СМИ пробегает статья о том, например, что > пилотов обязали рулить вручную, потому что у бота в нештатных ситуациях > нет варианта «принять нестандартное решение», а по стандартному он убьёт борт > вместе с пассажирами. :) FYI ошибки пилотов убивают больше пассажиров чем все остальное. Собственно по этой причине штурвал у двуногих и забирают. Так лучше работает - дохнет меньше народа. Компьютер не может не выспаться, бухнуть, рассудить что раз все уволят по прибытии то и в океан/гору влететь ок - и все такое прочее. Люди по запаре могут отправить самолет садиться на занятую полосу. Или выпустить маглев на занятый путь. Человек - самый ненадежный компонент систем. Чистая статистика. Поэтому исключение людей из управления как таковое повышает надежность систем. Хотя бэкапом на именно нестандартные ситуации я бы машинистов/пилотов/водителей все же оставил, имхо. Но тут еще жаба возникает - если система как таковая и без них работает, платить им зарплаты становится по сути пижонством. > Ну и ж поезда таки ездят с машинистами. Таки некоторые вообще совсем без машиниста. > Для отработки множества «нестандартных ситуаций». Я таки видел очень интересные фоты, кажется где-то в вике. Где таки можно плюхнуться в самый-самый перед состава. Пассажиром. Забавно выглядит - 2 рельсы перед самым носом. Приборов нет. Автоматическая штука, от и до. > Например, когда сломались светофоры. Вообще-то сейчас в моде такие штуки как "автоматическая линейная сигнализация". У ЖД в европах под это даже есть специфичный диалект GSM. А если нет конекта - СТОП. Ехать нельзя. Вот так вот. И таки это позволяет гонять заметно больше поездов по тем же рельсам. С людьми так нельзя, там малейшая оплошность и они в зад предыдущего состава впилят. А вот автоматические системы указания серверов диспетчерского центра выполняют четко. Или остановка, если это не получается. > диспетчерской и неформально попросили машиниста опоздать и пропустить другой состав («ну а чо такова? ЧСХ, именно такие вот нестандартные вещи и приводят к ЧП. Автоматика отберет это и весь интерфейс будет только через нее. И вот тогда она и пропустит как надо, и стрелки переведет правильно, и от степени выспанности диспетчера и того что его кто-то в этот момент дернул другой проблемой зависеть не будет. А с людьми вот как раз такое вот приводило к весьма солидным бабахам, и по линии лажи диспетчеров, и по линии лажи машинистов. > Робот в таких обстоятельствах и свой состав сломает, и всё движение в данной области. Роботы будут держать максимально возможную в таких условиях скорость, максимально плотно загружая собой путь. Конечно же диспетчерский центр их апдейтит постоянно на тему с какой скоростью им ехать. И тот соответственно знает где у него какой поезд. Общую идею таких штук можешь найти у яндекса, они на какой-то конфе довольно хорошо расписывали одну такую вещицу на примере московского метро. Там правда вроде не везде перешли на линейную сигнализацию вместо светофоров, но если ты видишь на ветке синий свет - и более совсем нифига - там таки автоматика на самом деле. А светофоры как максимум индикатор занятости соседнего участка и такой совсем минимальный автостоп, клинящий поезд если участок перед ним занят. Сами светофоры при этом как таковые имеют довольно мало смысла. > А с автомобилями всё значительно сложнее, потому что трафик и водятлы, каждый > из которых Индивидуальность. Будет им всем таким красивым индивидуальность. В хучшем случае, если будут сильно настаивать, права отберут и управление будет выглядеть так: указываешь на планшете куда тебе надо - и тебя везут. Ну по крайней мере в городе. А ручной режим - ну ок, где-нибудь в пердях, куда трансивер линейной сигнализации не достреливает - так и быть, педаль вручную.
	Ответить | Правка | ^ к родителю #291 | Наверх | Cообщить модератору

	342. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 13-Дек-18, 22:24
	> FYI ошибки пилотов убивают больше пассажиров чем все остальное. Собственно по этой потому что "все остальное" к рулю не подпускают вообще - поэтому у него собственных жертв ноль, и даже там где оно виновато - все равно "ошибка пилота". Да, современный самолет в принципе может сесть на высококатегорированный аэродром в полном автомате и при нулевой видимости (и даже сам с полосы уберется) - но при этом нужен еще и почти полный штиль. > причине штурвал у двуногих и забирают. Так лучше работает - дохнет > меньше народа. Компьютер не может не выспаться, бухнуть, рассудить что раз > все уволят по прибытии то и в океан/гору влететь ок - зато может повиснуть, ошибиться в рассчетах, нарваться на fdiv bug... Случай посадки шаттла с ручной ориентацией по звездам и ручным включением двигателей на торможение как бы говорит, что даже космическая автоматика (в которой нет непредсказуемых явлений, типа порывов ветра и вертикальной турбулентности, и которую уж казалось бы вылизывали не считаясь с затратами) иногда лажает. И что там в Нижнем - "runaway stabilizer", да? (ну да, тоже ошибка затраханного пилота, который должен был услышать и увидеть, что эта тварь крутится невпопад, но не услышал и не увидел, и не успел среагировать. Без пилота  - и реагировать было бы некому.) > Поэтому исключение людей из управления как таковое повышает надежность систем. Хотя бэкапом > на именно нестандартные ситуации я бы машинистов/пилотов/водителей все же оставил, имхо. они утратят навыки, которые в экстремальной обстановке надо применять незадумываясь. И внимание утратят - заметить примотанную проволочкой стрелку мог только машинист, занятый управлением, а не читающий книжку пока поезд сам едет. >> Ну и ж поезда таки ездят с машинистами. > Таки некоторые вообще совсем без машиниста. таки очень некоторые, и обычно это что-то наглухо закрытое от внешних условий, типа оленя, забредшего на пути. > Будет им всем таким красивым индивидуальность. В хучшем случае, если будут сильно до первого оленя, забредшего на дорогу.
	Ответить | Правка | ^ к родителю #308 | Наверх | Cообщить модератору

	374. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (374), 14-Дек-18, 09:43
	Ишчо один идiот. Объяснял же - у состава мобыть тормозной путь больше километра, поэтому совершенно монопенисуально, автомат там или мешок с мясом. Автобусы с детишками на переездах сносили, и ничего там живой хомяк поделать не мог, разве что застрелиться из пальца. Вот срок - то да, автоматике не впаяешь, а ежели электорат требует, придется кому-то из начальства присесть, тем это понятно дело не по нраву. И хоть аленя (и двух-, и четвероного), и пятьсоткилограммового лося поезд перемалывает как здрасьте. Вот застрявшее ведро с гайками, или положенный добрыми людьми бетонный блок - это да, мобыть уже опасно, а может и не быть, зависит от массы и прочего.
	Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

	475. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 21:51
	> потому что "все остальное" к рулю не подпускают вообще - В поездах таки уже подпускают, таки временами full authority, когда машиниста нет, или он декоративно наблюдает. С остальными сложнее - взаимодействия с внешними миром разнообразнее. И все же даже пилот лайнера большую часть времени ничего не делает, в принципе лайнер даже взлететь и сесть может сам. Правда пока не все аэропорты оборудованы полностью, и даже "улучшенные" варианты систем разработаны давно и таки не предел мечтания технологий. У них циклы тестирования и сертификации очень длительные. И на то есть причины. > поэтому у него собственных жертв ноль, и даже там где оно виновато - > все равно "ошибка пилота". Вспоминается россиянский пилот, приложивший A320, если не ошибаюсь, именно с пассажирами, именно по линии автопилота. Папаша-КВС додумался дать своим детишкам порулить. Дочка не выделывалась, а сынок сильный оказался, смог пересилить автопилот и перехватить инициативу. Так что папаша начал ажно по кабине летать (из кресла он вылез, ыгы0. А когда папаша взял ситуацию под контроль - кончилась высота. Ну и размазались на полной скорости. Компьютер сам по себе не захочет так выделываться, без вариантов. > Да, современный самолет в принципе может сесть на высококатегорированный аэродром > в полном автомате и при нулевой видимости (и даже сам с полосы уберется) - > но при этом нужен еще и почти полный штиль. Ну вот кстати парирование порывов ветра (а также компенсацию нестабильной аэродинамики и проч) сделать можно даже без AI как таковых. И таки скорость реакции при этом может быть лучше. У военных и моделистов, не связанных сертификациями - активная стабилизация полетов уже довольно давно практикуется. Это позволяет летать даже на штуках с аэродинамикой, совершенно непригодной для двуногих самой по себе. Уже есть несколько моделей военных самолетов, которые вообще не катит пилотировать без flight assist бортовыми компьютерами, парирующими нестабильность аэродинамической схемы, для начала. > зато может повиснуть, ошибиться в рассчетах, нарваться на fdiv bug... Поэтому авиаторы делают так, чтобы это не приводило к проблемам. Компьютеров может быть несколько, на разных архитектурах, с разным софтом писаным разными командами. Это чтобы они не сглюкнули одинаково - тогда заглючившего перезагружают или отключают, а процесс управления не заваливается. > на торможение как бы говорит, что даже космическая автоматика (в которой > нет непредсказуемых явлений, типа порывов ветра и вертикальной турбулентности, Вообще-то спейсшатл садится как самолет и все что актуально для самолетов актуально и для него. Другое дело что там извините полет планируют гораздо круче, и вообще. > и которую уж казалось бы вылизывали не считаясь с затратами) иногда лажает. Но умирали космонавты в шаттлах все-таки не из-за компьютеров. > тварь крутится невпопад, но не услышал и не увидел, и не > успел среагировать. Без пилота  - и реагировать было бы некому.) И даже тут вы видим про "затраханного пилота". Правда хуже когда затрахивают диспетчеров - там вообще взлет или посадка на занятую полосу бывают. А, да и в воздухе диспетчеры лажают. Можешь поинтересоваться почему TCAS теперь для пилотов приоритетнее указаний диспетчеров. Ага, диспетчер перекрыл указания TCAS - и таки по запаре все же впечатал самолеты друг в друга. А вот чтобы TCAS кого-то впечатал... не встречал. > они утратят навыки, которые в экстремальной обстановке надо применять незадумываясь. В экстремальной обстановке невозможно применять навыки не задумываясь - это нестандартная ситуация, требующая нестандартной реакции. На этом погорело множество пилотов. И как раз таки в нормальной ситуации пилоту требуется уйма времени чтобы с нестандартной ситуацией что-то сделать. А если этого времени нет - печалька. В лучшем случае пилот забьет на инструкции и попробует сымппровизировать. Но может и лажануть. Как те герои, выключившие исправный двигун, ковыляя на неисправном до почти самого аэропорта. Но в посадочном режиме он сдох - и они размазались буквально за сотни метров до аэродрома на шоссе. За относительно удачную посадку они сперва были героями. Но потом оказалось что герои двигатель перепутали, после чего герои стали немного убийцами. Это частично проблема Man-Machine-Interface, компьютер бы так не ошибся, например - ему интуитивность контролов вообще до лампочки. > И внимание утратят - заметить примотанную проволочкой стрелку мог только машинист, занятый > управлением, а не читающий книжку пока поезд сам едет. У машиниста нет шансов разглядеть такую мелочь на нормальной скорости. Никто и не замечал, пока поезд не устроил multi track drifting. Который обломался, потому что в тоннеле оказывается этому стены мешают. И поезд буквально убился о стену с разбега. Так что не помог ему машинист. Кстати говоря, в самолетах и скоростных поездах скорость реакции человека еще и попросту недостаточна. Характерный пример - столкновение истребителя и авиалайнера, показавшее что на такой скорости сближения VFR не особо то и работает. Даже в условиях нормальной видимости. Таки лишний аргумент за IFR во все поля. Даже для амеровских ястребов, которые такие из себя асы, что в результате снесли кабину лайнеру. > таки очень некоторые, и обычно это что-то наглухо закрытое от внешних условий, > типа оленя, забредшего на пути. Даже если человек увидит оленя на пути... типично вариантов два: он или не успеет среагировать если поезд быстрый, или не успеет затормозить. Как максимум он отсигналит, но большинство живности от опасности топит прямым курсом, максимальной скорстью. А где удобнее всего драпать быстро? Правильно - по рельсам. Там видите ли ровно и расчищено, в отличие от бурелома сбоку. > до первого оленя, забредшего на дорогу. Для оленей у поездов таки есть отбойники. Ну и люди оленей регулярно выносят не только на поездах, но и на авто.
	Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

	483. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 15-Дек-18, 22:37
	Ты явно не понимаешь, зачем ко всякой сложной технической системе нужен оператор для наблюдения и ручного управления. Даже при многократном дублировании и резервировании. Потому что невозможно предусмотреть и смоделировать все обстоятельства и условия и их сочетания. Они могут сойтись в самом причудливом и непредсказуемом виде. Недавно у некой авиакомпании на бортах некоторой модели обнаружилось, что при определённых условиях автоматика отклоняет элероны или закрылки или что-то другое из механизации, запамятовал, в другую сторону, чем надо. И так на всей серии этих машин, ага. Особенности, так сказать. И поэтому мясной пилот (даже два) за штурвалом жизненно необходим. Разумеется, это не отрицание существующей вероятности, что мясной сойдёт с ума, забухает, умрёт на рабочем месте от инфаркта, его не застрелят террористы или что-то ещё. Мясной за рулём любого пепелаца сидит не для безопасности посторонних оленей.
	Ответить | Правка | ^ к родителю #475 | Наверх | Cообщить модератору

	491. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 15-Дек-18, 23:29
	машина не рожает машину
	Ответить | Правка | ^ к родителю #475 | Наверх | Cообщить модератору

	340. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 13-Дек-18, 22:16
	ИР это *модель* некоторых возможностей человеческого разума, предназначенная встраиваться в человеческое же сообщество. "Совершенный ИР" это квадратура круга или достигнутая линия горизонта. Но их будет всё больше, да.
	Ответить | Правка | ^ к родителю #288 | Наверх | Cообщить модератору

	226. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от PnDx (ok), 13-Дек-18, 13:15
	> Но, как я уже сказал, дешёвый кремний закончился. Думаю, что через какое-то > время (предположительно — после фиаско с ИИ и автопилотами в автопроме, ибо > речь пойдёт о безопасности и жизни людей) произойдёт крах невероятно раздутых > пустых капитализаций софтверных компаний и всё вернётся примерно к тому виду, > как было в семидесятых. Кто из кодописов действительно умеет решать инженерные > задачи, будут иметь работу. Остальные отправятся подметать улицы и носить ящики.   Касаемо "фиаско", я бы не был столь категоричен (и да, "по первому пункту возражений нет"). То что "экспертные системы" станут обзывать "ИИ" — аналог переименования "майнфреймов" в "облака". Специалисты продолжают заниматься своим делом, "руководители" — водить руками, а большинству как всегда пох. С автопилотами — достаточно масштабная и при этом комплексная (административно-техническая) проблема. Так что внедрение будет проходить достаточно медленно, чтобы успеть адаптировать фантазии к реальности. (Да, кто-то обязательно обосрётся, но где это не так?)
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	233. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от meantraitor (?), 13-Дек-18, 13:58
	> Программистская работа в большинстве случаев не заслуживает такой оплаты. Программирование — сравнительно простая и доступная практически всем прикладная и обслуживающая деятельность, Ну так напишите себе свой браузер, текстовый редактор и чем вы там еще пользуетесь. А пока вы все это пишите, пользуйтесь результатами работы современных программистов. Только не плачьте про криворуких обезьян тогда. Экстенсивный путь развития - это никакая не особенность индустрии программирования самой по себе, так все современное общество устроено. Плохо это или хорошо - отдельный вопрос, к данной теме не относящийся
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	268. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Урри (?), 13-Дек-18, 16:11
	Писали уже, и все работало - месяцами без перезагрузок и выключений Но обезьяны и маркетинг воспитывают клиентов в духе никому не нужных свистоперделок и клиенты больше не хотят качественный софт, а хотят красиво выглядящее и регулярно падающее говно, лишь бы было "стильно, модно".
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	272. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от meantraitor (?), 13-Дек-18, 16:27
	Ну так а что вы тогда хотите - рынок ;-P Если никто не хочет качаственный софт (и не хочет за него платить) - ешьте, что дают. Или сами пишите, если считаете, что это так просто.
	Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

	309. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (309), 13-Дек-18, 18:38
	> Ну так напишите себе свой браузер, текстовый редактор и чем вы там еще пользуетесь. > А пока вы все это пишите, пользуйтесь результатами работы современных программистов. > Только не плачьте про криворуких обезьян тогда. Ну так напишите себе свой комментарий, восхваляющий современных программистов. А пока вы его пишите, читайте результаты работы других комментаторов. Только не плачьте про называющих криворуких обезьян криворукими обезьянами тогда.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	163. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Crazy Alex (ok), 13-Дек-18, 09:53
	Какой софт есть - тот и использую. Но, например, при линковке чего-то крупного гиг выжрать - вообще не проблема, особенно если lto. Монстры вроде хромиума и четыре сожрут спокойно при сборке. Браузер - при всех ограничениях 800 сожрёт, если там не одна вкладка. Обработка графики тоже прожорлива. Ну то есть стонать можно сколько угодно (и я местами подпеть могу, сам не люблю лишнюю сложность), но бук с двумя-тремя гигами от этого более юзабельным не станет. Если что - в современных недорогих смартфонах памяти от трёх, так что насчёт "дешёвый кремний закончился" - как-то сомнительно.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	166. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 10:13
	> Какой софт есть - тот и использую. Но, например, при линковке чего-то > крупного гиг выжрать - вообще не проблема, особенно если lto. Монстры > вроде хромиума и четыре сожрут спокойно при сборке. Браузер - при > всех ограничениях 800 сожрёт, если там не одна вкладка. Обработка графики > тоже прожорлива. Из моего примера выше: Seamonkey 2.0.14 ( Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 ) чуть за сотню МБ ОЗУ потребляет на два десятка вкладок, а типично около 120 МБ. Я ею читаю HTML-документацию (то есть длинные простыни) и, если надо, Википедию, а на модно-современный Веб ей уже не хватает сертификатов и секьюрных умений. Другие браузеры приходится немного сильнее стреноживать посредством расширений и значительной правки в about:config. Самый современный, что я считаю действительно пригодным к использованию — Firefox ESR 38,8. Да, он типично жрёт от 600 до 1200 МБ памяти, но это при пяти-семи сотнях вкладок (из коих загруженными бывают до сотни). Хромые браузеры я тоже ограничиваю. В любом случае — браузеры у меня не жрут память десятками гигабайтов. Хотя в моих системах есть запас, не жалуюсь. Но я люблю быстрый и отзывчивый софт, как можно более эффективно использующий ресурсы, а не «раздайся море». > Ну то есть стонать можно сколько угодно (и я местами подпеть могу, > сам не люблю лишнюю сложность), но бук с двумя-тремя гигами от > этого более юзабельным не станет. Если что - в современных недорогих > смартфонах памяти от трёх, так что насчёт "дешёвый кремний закончился" - > как-то сомнительно. В смартфонах даже и близко нету той производительности, что в десктопах или серверах, то «бумажные» гигагерцы. Поэтому сравнивать не вижу смысла. Да и память там прямо на процессорах, и немного другая она. Короче, это совсем отдельная тема для разговора. Смарфтон — это игрушка, а ноутбук — это (для меня) универсальное средство производства, где важна высокая производительность в относительных и абсолютных значениях. :)
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	261. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 15:48
	> Из моего примера выше: Seamonkey 2.0.14 ( Build identifier: Mozilla/5.0 (Windows; U; > Windows NT 6.0; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 ) чуть за сотню > МБ ОЗУ потребляет на два десятка вкладок, А ты попробуй этот seamonkey сбилдовать. Вот и узнаешь сколько линкеру надо на проекте такого масштаба. Особенно если оптимизации еще захотеть. А так то разглагольствовать о том кто и что должен, не имея понятия как это даже билдуется - офигенно, конечно. > В смартфонах даже и близко нету той производительности, что в десктопах или серверах, то «бумажные» гигагерцы Современный ARM на гигагерц легко и ненапряжно втыкает какому-нибудь селерону на гигагерц. Фирма ARM свои деньги тоже не за красивые глаза зарабатывает.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	269. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 16:13
	Ну а это-то при чём? Справка для альтернативно одарённых: большой софт вменяемые люди собирают не на десктопах и ноутбуках, а на специальных сборочных машинах или даже фермах. Да, это там, где мурзилла будет компилироваться не два дня, а два часа или даже две минуты.
	Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

	310. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:44
	> Справка для альтернативно одарённых: большой софт вменяемые люди собирают не на десктопах > и ноутбуках, а на специальных сборочных машинах или даже фермах. Да, > это там, где мурзилла будет компилироваться не два дня, а два > часа или даже две минуты. А я не вижу с чего бы вдруг мой десктопник не сойдет еще и за небольшую билдферму :). Где билдовку могу прогнать вот конкретно лично я, а не какие-то абстрактные корпоративщики, где-то там, которым я и мои юзкейсы до 3.14-ы. А покупать себе половину датацнтра как-то дорого, занимает много места и жрет электричество. Хотя Ларабель и так смог. Но он это монетизировал по хитрому, иначе на одном только электричестве сплошной разор.
	Ответить | Правка | ^ к родителю #269 | Наверх | Cообщить модератору

	343. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 13-Дек-18, 22:30
	> А я не вижу с чего бы вдруг мой десктопник не сойдет > еще и за небольшую билдферму :). Где билдовку могу прогнать вот мы рады что у тебя много ненужных денег. а мне вот понадобилось раз пять подряд пересобрать mysql "угадай с какими флагами сборки оно не ломается" - так что-то резко расхотелось этим заниматься на десктопе - вытряс с коллег лезвие о 64 ядрах, где этот процесс занимает меньше минуты, а не полтора часа. > конкретно лично я, а не какие-то абстрактные корпоративщики, где-то там, которым > я и мои юзкейсы до 3.14-ы. А покупать себе половину датацнтра похоже ты не в курсе как работает тот же OBS.
	Ответить | Правка | ^ к родителю #310 | Наверх | Cообщить модератору

	476. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 22:06
	> мы рады что у тебя много ненужных денег. Я просто хотел себе компьютер который не будет меня клинить в моих задачах - и я его сделал именно таким. Хотя на самом деле прилично работать может и более хилая конфига. Особенно если кто не ребилдует кернель в 8 потоков с разлапистой конфигурацией. А я таки порой ребилдую и меня время этой операции таки немного интересовало. > заниматься на десктопе - вытряс с коллег лезвие о 64 ядрах, > где этот процесс занимает меньше минуты, а не полтора часа. Голимый видимо десктоп если там это полтора часа требует. А лезвие это прекрасно. Но все же не для всех. Мне проще сделать десктоп чем-то похожим на этом. Попутно там и CADы нормально ворочаются, и архиватор неплохо жмет, и видео можно транскодировать, etc. Только вот в отличие от лезвия там большие и тихие 120мм гидродинамики. Они условно вечные по надежности. Но в отличие от блейда они таки не визжат как истребитель на взлете когда это еще и нагрузишь. Некоторые конечно ставят и блейды дома, как Ларабель. Но у него видите ли есть подвал под это дело и он там достатчно серьезно попахал оборудуя это. > похоже ты не в курсе как работает тот же OBS. Мне как-то проще когда у меня все на виду. И я не настолько масштабный и злобный чтобы всякие системы распределенной билдовки и проч наворачивать. Да и толку от наворачивания, если самый мощный комп - у меня перед носом, десктопом работает? Остальные конечно что-то добавят, но не столько уж и много. А блейд с 64 ядрами если только за свой счет и как бы выть рн будет упаси боже, зафиг он мне такой?
	Ответить | Правка | ^ к родителю #343 | Наверх | Cообщить модератору

	551. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 17-Дек-18, 11:31
	>> мы рады что у тебя много ненужных денег. > Я просто хотел себе компьютер который не будет меня клинить в моих > задачах - и я его сделал именно таким. Хотя на самом > деле прилично работать может и более хилая конфига. Особенно если кто > не ребилдует кернель в 8 потоков с разлапистой конфигурацией. А я всего-то? > Голимый видимо десктоп если там это полтора часа требует. А лезвие это судя по тому что ядро в восемь потоков для тебя проблема - современный (да и старый тож) mysql ты собирать никогда не пробовал. Попробуй, удивишься, что ведро линyпca далеко не самый, оказывается, сложный и большой проект на свете. > прекрасно. Но все же не для всех. Мне проще сделать десктоп > чем-то похожим на этом. Попутно там и CADы нормально ворочаются, и > архиватор неплохо жмет, и видео можно транскодировать, etc. видео транскодирует железка, обычно все равно сколько это занимает, поскольку твоего непосредственного участия не требует. А вот подобрать параметры компиляции с энным количеством перезапусков - это уже немного печально, если каждого результата надо ждать до завтра. > Только вот в отличие от лезвия там большие и тихие 120мм гидродинамики. мне все равно, как оно там жужжит - я даже не в том же здании. странно, что фанаты линуксов не умеют даже основной фичи еще работающей по сей день - удаленной работы совершенно не отличающейся от непосредственной - мне вообще-то абсолютно все равно, этот xterm локальный или нет, специально крашу их в разные цвета чтоб не перепутать. >> похоже ты не в курсе как работает тот же OBS. > Мне как-то проще когда у меня все на виду. И я не у меня все на виду ровно настолько, насколько я хочу это видеть. В случае, когда сборочный скрипт делает ровно то что в нем написано - мне его видеть вообще незачем. В случае когда как выше - надо поковыряться-поподбирать - мне нужен прямой доступ, но незачем сидеть в метре от того, на чем я это делаю, и канала шире 64k мне для этого вообще даром не нужно. Чай не винда. К сожалению, трудами современных опенсорсных горе-программистов "как в винде" во многих областях уже настало и скоро окончательно настанет везде. Они по другому не умеют.
	Ответить | Правка | ^ к родителю #476 | Наверх | Cообщить модератору

	499. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 17:45
	> гента, софт подобран так, чтобы жрать минимум). Дык небось компилежка и напрягала больше всего, и прочие убер "эффективные" портажи на пихтоне, который совсем не тормозит, и вообше. А именно десктоп, на 3 гигз, особенно с zram вполне прилично получается. Из какого-нибудь Debian'а с XFCE например. У меня на ноуте так вообще 2 гига. Конечно мегаразработок там не происходит, но вообще-то больше всего там анноит скорость компиляции больших проектов. И таки если мы про скорость компиляции и сжирание RAM при этом - зато, блин, код потом оптимизирован хорошо. А быстрый компилер жрущий мало RAM и код будет оптимизировать понятно как - ну нет у него ресурсов на глобальный анализ с разумной скоростью при этом. Значит и возможности оптимизации прошлепает.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	552. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 17-Дек-18, 11:37
	>> гента, софт подобран так, чтобы жрать минимум). > Дык небось компилежка и напрягала больше всего, и прочие убер "эффективные" портажи как человек, сдуру поставивший ее на недоноут (давно) подтверждаю - она не предназначена для эффективно, она предназначена для др...ва на то что "йа все могу пересобрать из исходников (ни разу не понимая что там под капотом), смотрите,я у мамы великий пересборщик!" обкорнать абсолютно любой дистрибутив под недокомпьютер было бы куда быстрее, проще и, вероятно, даже эффективнее. Те полтора пакета, которые действительно требовалось оптимизировать, я пересобрал бы сам - разумеется, на билдхосте с нормальным быстрым железом, откуда потом не придется замысловатым способом выковыривать результат (бинарные пакеты у gentoo как бы есть, но со многими но). > на пихтоне, который совсем не тормозит, и вообше. вообще-то почти не тормозит - по сравнению с yum/zypper - можно сказать, летает. Они, если что, на том же пихоне. но непригодность генты для осмысленного использования складывается не из этого
	Ответить | Правка | ^ к родителю #499 | Наверх | Cообщить модератору

	561. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 17-Дек-18, 14:22
	> но непригодность генты для осмысленного использования складывается не из этого Мне известно одно разумное и вполне оправданное исключение, когда Gentoo обращают во благо — SystemRescueCd.
	Ответить | Правка | ^ к родителю #552 | Наверх | Cообщить модератору

	109. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от freehck (ok), 13-Дек-18, 06:05
	> Если уже 4 считается непозволительно мало, то это ппц, так как ddr2 хрен докупишь, особенно если плата поддерживает максимум 8 гигов Да ппц не то слово прямо. У меня только после старта всех необходимых для работы мессенджеров сжирается 3 гига рамы. А что поделать, засилье электрона, никуда не деться...
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	301. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:57
	> Да ппц не то слово прямо. У меня только после старта всех > необходимых для работы мессенджеров сжирается 3 гига рамы. А что поделать, > засилье электрона, никуда не деться... Я бы присмотрелся к Миранде через Вайн. https://www.miranda-ng.org/ru/ К ней есть великое множество дополнений.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	312. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:46
	В линухе проще пиджина поставить. Протоколов под него напилено ну уж не меньше чем под миранду. По крайней мере всякие вайберы-фэйсбуки-телеграмы и чего я там еще забыл там есть. Насколько полные - черт знает, но плагины попадались. А так то девопсику и окружение под стать привалило, с каким-нибудь хипста-шлаком небось :)
	Ответить | Правка | ^ к родителю #301 | Наверх | Cообщить модератору

	345. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 23:27
	> В линухе проще пиджина поставить. Протоколов под него напилено ну уж не > меньше чем под миранду. По крайней мере всякие вайберы-фэйсбуки-телеграмы и чего > я там еще забыл там есть. Насколько полные - черт знает, > но плагины попадались. > А так то девопсику и окружение под стать привалило, с каким-нибудь хипста-шлаком > небось :) Teach Yourself JavaScript for System Administration in 24 Hours: DevOps Edition!
	Ответить | Правка | ^ к родителю #312 | Наверх | Cообщить модератору

	500. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 17:48
	> Teach Yourself JavaScript for System Administration in 24 Hours: DevOps Edition! Я намекал олдскульщику что псинодевы идут с неким catch в виде хипста-команды :). Погоди, скоро ему объяснят и что systemd это хорошо и правильно. И таки в этом месте я с псинодевами даже соглашусь. Просто на той почве что для меня оно работает лучше чем то что было до него. Я ж тоже учусь у псинодевов разным трюкам. Просто в своей адаптации и без всех этих электронов, отбирая мелкие, эффективные по ресурсам трюки. "И в гамне встречаются жемчужины."
	Ответить | Правка | ^ к родителю #345 | Наверх | Cообщить модератору

	369. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от freehck (ok), 14-Дек-18, 09:07
	> Я бы присмотрелся к Миранде через Вайн. > К ней есть великое множество дополнений. Скайп вижу. А слак, зум, тимс там как?
	Ответить | Правка | ^ к родителю #301 | Наверх | Cообщить модератору

	370. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 09:12
	Хм. Я и слов-то таких не знаю. :)
	Ответить | Правка | ^ к родителю #369 | Наверх | Cообщить модератору

	477. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 22:08
	> Хм. Я и слов-то таких не знаю. :) Я первое знаю. Очередная дрянь на электроне от вебмакак, конечно же.
	Ответить | Правка | ^ к родителю #370 | Наверх | Cообщить модератору

	490. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 15-Дек-18, 23:24
	>> Хм. Я и слов-то таких не знаю. :) > Я первое знаю. Очередная дрянь на электроне от вебмакак, конечно же. закрывают уже.
	Ответить | Правка | ^ к родителю #477 | Наверх | Cообщить модератору

	501. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 17:48
	> закрывают уже. Так что я там про период полураспада в 2 года то говорил...? На этом фоне даже пиджин очень стабильная и качественная прога :)
	Ответить | Правка | ^ к родителю #490 | Наверх | Cообщить модератору

	526. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от freehck (ok), 17-Дек-18, 06:38
	>>> Хм. Я и слов-то таких не знаю. :) >> Я первое знаю. Очередная дрянь на электроне от вебмакак, конечно же. > закрывают уже. Не знаю, в какой там местности его закапывают. Я пока вижу, что в большинстве зарубежных контор это нынче выбор по умолчанию.
	Ответить | Правка | ^ к родителю #490 | Наверх | Cообщить модератору

	534. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 08:42
	[слак] >> закрывают уже. > Не знаю, в какой там местности его закапывают. Я пока вижу, что > в большинстве зарубежных контор это нынче выбор по умолчанию. пробегало в одной из рассылок, мол, туда же, куда и гугль-плюс
	Ответить | Правка | ^ к родителю #526 | Наверх | Cообщить модератору

	553. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 17-Дек-18, 11:38
	> [слак] >>> закрывают уже. > пробегало в одной из рассылок, мол, туда же, куда и гугль-плюс а, что - неужели? Инфа 100%?
	Ответить | Правка | ^ к родителю #534 | Наверх | Cообщить модератору

	556. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 13:36
	>> [слак] >>>> закрывают уже. >> пробегало в одной из рассылок, мол, туда же, куда и гугль-плюс > а, что - неужели? Инфа 100%? Не знаю, увы. Копнул и в корзине -- нет, не найду. Мне это и интересно-то было лишь настолько, что похоже названием на используемый мною дистр.
	Ответить | Правка | ^ к родителю #553 | Наверх | Cообщить модератору

	130. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от анон (?), 13-Дек-18, 07:53
	Открываю Алиэкспресс и вижу там вагоны ддр2
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	152. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 09:05
	Это «плохая» DDR2. Её делают китайцы из неликвидов — то есть давно списанных и подлежащих утилизации отработавших своё модулей памяти. В сараях Дядюшки Ляо с модулей выпаивают чипы памяти и с каким-нибудь попавшимся под руку SPD напаивают на новые, иногда наносят какую-то маркировку поверх старой. Бывает так, что зашитая в SPD информация не отвечает распаянным на плате микросхемам памяти. Весь этот творческий ералаш использовать в ряде случаев можно, но нет никаких гарантий, что он будет полноценно работать, а не развалится сам собой (например, из-за температурного режима эксплуатации). У меня, скажем, в одном из компьютеров работает такая память на уменьшенной вдвое частоте против заявленной — 400 вместо 800 DDR2. На практике это не играет роли и почти не влияет на скорость работы, но зато полезно для стабильности, а на «полной скорости» эти модули иногда показывали ошибки без какой-либо очевидной и понятной логики. Но зато дёшево, да. Можно и пользоваться, учитывая, опять же, что новую полноценную DDR2 найти сложно и стоит она дорого.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	313. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:48
	> Это «плохая» DDR2. Её делают китайцы из неликвидов  Еще китаезы немного балуются просто распайкой нормальных модулей на чипы. Это нравится народу которые роутеры апгрейдят, перепаивая более жирные чипы. Так что вон тот 32-меговый задохлик парой пыщ-пыщ фена становится солидным агрегатом с 128 мегов, и может торенты полподъезду гонять, в отличие от 32 мегов то. Так даже нормальный DDR2 купить реально.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	381. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Иваныч (??), 14-Дек-18, 10:58
	Зубожиння #2. От создателей геймерских процессоров за 400 рублей.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	21. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (17), 12-Дек-18, 23:30
	> Экономия небольшая Большая. > браузеры не работают Вообще не аргумент. Браузеры надо поправить, и будут работать.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	28. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 12-Дек-18, 23:43
	>> Экономия небольшая > Большая. >> браузеры не работают > Вообще не аргумент. Браузеры надо поправить, и будут работать. Не для того макака научилась немытым хвостом бряцать по клавиатуре, производя новые улучшенные программы.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	55. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (10), 13-Дек-18, 00:47
	>Вообще не аргумент. Браузеры надо поправить, и будут работать. Никто не поправил до сих пор, значит на десктопе никому толком не надо
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	62. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 01:07
	>>Вообще не аргумент. Браузеры надо поправить, и будут работать. > Никто не поправил до сих пор, значит на десктопе никому толком не > надо Кому надо, те не умеют. Вот в чём заковыка. А кто умеют, тем работодатели покупают самое топовое железо для работы. Поэтому линукс ничего никому не должен — ведь работодатель оплачивает разработку софта не для простых юзеров, а для себя. Юзеры могут утешиться… виндой, например.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	100. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (10), 13-Дек-18, 05:06
	>Кому надо, те не умеют. А хотят, чтобы им даром на блюдечке принесли >Юзеры могут утешиться… виндой, например. Или использовать linux x86_64
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	103. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (514), 13-Дек-18, 05:19
	>Или использовать linux x86_64 Который жрёт на 30% больше памяти.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	106. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (10), 13-Дек-18, 05:57
	Чем винда? Да ты угараешь
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	107. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от Аноним (514), 13-Дек-18, 05:59
	Чем чистый x64
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	170. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от nobody (??), 13-Дек-18, 10:27
	Что такое "чистый x64", который не x86_64?..
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	172. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (514), 13-Дек-18, 10:35
	> Что такое "чистый x64", который не x86_64?.. Чистый в смысле без хаков по изменению размера указателей. То есть именно x86_64.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	169. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 10:19
	чем винда x86 - да, чему тут удивляться?  Тому что /\апчатая обезьянка ту винду видела только во сне и на скриншоте, потому что она не така как все, и понятия не имеет, что в ней можно и на гигабайте работать, если не заниматься непонятно зачем пересборкой из исходников непойми чего - да что тут тоже удивительного-то...
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	235. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (374), 13-Дек-18, 14:06
	>и на гигабайте работать Когда-то у нас оракля9 работала на 256М под ХР. И даже не очень тормозила. А теперь я сменил на рабочей тачке Вынь7 на ту же ХР, и ... и нифига. Потому что запустил браузер, аутглюк, скайп и все, память кончилась, здравствуйте тормоза. Один Фуррифокс жретЪ 1,5 гига на двух вкладках. Ну да, вкладки "тяжелые"... но 1,5 гига!!! Куды котиццо мир...
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	423. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 14-Дек-18, 22:09
	Что ты  с ним сделал? Прямо сейчас 10 закладок и 15 загруженных вкладок, из них штук 10 тытуб. Вин7, 4Гига.
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	581. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Andrey Mitrofanov (?), 18-Дек-18, 12:26
	#>>Который жрёт на 30% больше памяти. > Чем винда? Да ты угараешь Нет.  Вне зависимости от того, чего болит у Вас, разговор не про это. [Л] https://www.opennet.ru/openforum/vsluhforumID3/108449.html#80 https://www.opennet.ru/openforum/vsluhforumID3/110263.html#117 https://www.opennet.ru/openforum/vsluhforumID3/110297.html#94 https://www.opennet.ru/openforum/vsluhforumID3/114731.html#58 . .   . . . .https://duckduckgo.com/?q=32-bit+64-bit+site:phoronix.com
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	141. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 08:29
	> А хотят, чтобы им даром на блюдечке принесли Это совершенно нормально. Если на рынок ПО предложено какое-то ПО, то его потребитель имеет полное право критически относиться к тому, что он видит. Если авторы ПО не хотят учитывать мнение пользователей, то не надо и предлагать. Почему-то ни у кого больше в софтверной отрасли это не вызывает никаких вопрос — только у линуксоидов начинает обильно выделяться желчь. > Или использовать linux x86_64 Идея в экономии ресурсов, которые, во-первых, не бесплатны и, во-вторых, принадлежат пользователю ПО, а не его автору. Автор не имеет права требовать у пользователя подстраиваться под некие представления автора о правильном потреблении ресурсов программой. Не можешь писать программы экономно и с учётом потребностей потребителя? Иди подметай улицы.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	236. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (374), 13-Дек-18, 14:10
	Пользователь точно также имеет право не использовать программы автора. Не нравится то, что тебе дают нахаляву? Какие проблемы, пиши сам. Или плати.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	306. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 18:26
	> Пользователь точно также имеет право не использовать программы автора. Не нравится то, > что тебе дают нахаляву? Какие проблемы, пиши сам. Или плати. Только вот почему-то из всего разнообразия субкультур бегают и пристают к людям с этой методичкой исключительно линуксоиды. А, ну и ещё похоже ведут себя продавцы гербалайфа, адвентисты, коммуняки и другие религиозные миссионеры.
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	377. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (374), 14-Дек-18, 09:49
	Я таки понимаю, что ты хочешь, чтобы и тебе было зафигато, и чтобы не платить? Нуачо, сейчас и так можно. Правда потом ты можешь понять, если есть чем, что заплатить тебе все равно пришлось, только не деньгами, гы...
	Ответить | Правка | ^ к родителю #306 | Наверх | Cообщить модератору

	424. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 14-Дек-18, 22:17
	Марксизм и вытекающий из него коммунизм в прямых руках, управляемых разумной человеческой головой научен. А либертарианство нет, такова селява.
	Ответить | Правка | ^ к родителю #306 | Наверх | Cообщить модератору

	426. "(offtopic) коммунизм и п. 10 правил форума"	+/–
	Сообщение от Michael Shigorin (ok), 14-Дек-18, 22:37
	> Марксизм и вытекающий из него коммунизм в прямых руках, > управляемых разумной человеческой головой научен. Чему научен -- прятать от публики существенные куски фактажа? --- Итак, развитие хозяйства капиталистического Запада стало возможным «посpедством пpямого или косвенного pазpушения» хозяйства Третьего Мира (в пеpиод между XVI и XIX вв.). Но это не было включено в политэкономию ни А. Смита, ни К. Маркса. Если из модели исключен принципиальный фактор, эту модель нельзя считать научной и, тем более, считать теорией. Это внутренний идеологический документ, который фальсифицирует реальность рынка и картину мира населения и Запада, и разрушенных стран, и образованных слоев незападных стран, принявших европейское образование. Как же можно было в России, а потом в СССР, учить студентов исходя из этой политэкономии как научной теории? А ведь и сейчас российских студентов обучают с такими же учебниками. --- https://sg-karamurza.livejournal.com/283146.html
	Ответить | Правка | ^ к родителю #424 | Наверх | Cообщить модератору

	428. "(offtopic) коммунизм и п. 10 правил форума"	–1 +/–
	Сообщение от псевдонимус (?), 14-Дек-18, 22:44
	Оно тут офтоп. Кури Кагарлицкого и Ильина. Кара-Мурза не марксист вообще.
	Ответить | Правка | ^ к родителю #426 | Наверх | Cообщить модератору

	433. "(offtopic) коммунизм и п. 10 правил форума"	+/–
	Сообщение от КГБ СССР (?), 15-Дек-18, 00:08
	> Оно тут офтоп. Кури Кагарлицкого и Ильина. Кара-Мурза не марксист вообще. Кара-Мурза вообще болван, пишущий для баранов, однако это действительно уже сильно оффтоп.
	Ответить | Правка | ^ к родителю #428 | Наверх | Cообщить модератору

	434. "(offtopic) коммунизм и п. 10 правил форума"	+/–
	Сообщение от Michael Shigorin (ok), 15-Дек-18, 00:23
	Они разные бывают, если что.
	Ответить | Правка | ^ к родителю #433 | Наверх | Cообщить модератору

	436. "(offtopic) коммунизм и п. 10 правил форума"	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 07:37
	>> Марксизм и вытекающий из него коммунизм в прямых руках, >«посpедством пpямого или косвенного pазpушения» хозяйства Третьего Мира Это никак не противоречит марксовой теории. И вообще, крупному капиталу без разницы, где находится, он течёт туда где может быстрее расти (посмотри например как поднялся Китай). И с чего ты взял что студентов сейчас учат политэкономии? Ей учат только энтузиасты-преподы.
	Ответить | Правка | ^ к родителю #426 | Наверх | Cообщить модератору

	437. "(offtopic) коммунизм и п. 10 правил форума"	+1 +/–
	Сообщение от Ю.Т. (?), 15-Дек-18, 07:42
	>> Марксизм и вытекающий из него коммунизм в прямых руках, >> управляемых разумной человеческой головой научен. > Чему научен -- прятать от публики существенные куски фактажа? > --- > Итак, развитие хозяйства капиталистического Запада стало возможным «посpедством > пpямого или косвенного pазpушения» хозяйства Третьего Мира (в пеpиод между XVI > и XIX вв.). Но это не было включено в политэкономию ни Поскольку оставлена жить вся ветка, позволю себе попытаться добавить концептуальной ясности... Коммунизм это гипотетическое общественное устройство, гипотетически же сменяющее капитализм. Модель, согласно которой это происходит, построена по принципам диалектического и исторического материализма. И она не квантифицирована, т.е. количественной мерой не снабжена. Политэкономическая часть модели, во-первых, плохо прочтена Кара-Мурзой -- это разрушение один из кейс-пойнтов, как сейчас модно говорить, во-вторых, для ист. мат. части модели, поскольку речь о временах Смита и Маркса, не существенно -- поскольку промышленный пролетариат в те времена существовал именно лишь на Западе. Движение за свободное программное обеспечение (а вот и топик, наконец!) есть реакция на следствия капиталистических обществ. отношений в области произ-ва материальных благ, в секторе произ-ва программного обеспечения. Именно из этой сути движения вытекают (вытекали бы) осмысленные действия участников движения.
	Ответить | Правка | ^ к родителю #426 | Наверх | Cообщить модератору

	432. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 15-Дек-18, 00:07
	> Марксизм и вытекающий из него коммунизм в прямых руках, управляемых разумной человеческой > головой научен. А либертарианство нет, такова селява. Из всего марксизма лично я научной признаю только политэкономию. О научности же, к примеру, социальной теории марксистов убедительно показали в XX веке примеры всех стран, где коммуняки оказались у руля. И даже тех стран, внезапно, которые формально оставались свободными, но где марксисты оккупировали систему образования. Именно оттуда выросли все эти гендерно-феминистические бредни, SJW, дайверсити, эколухи и так далее, что стремительно разрушают мир белых людей. К огромному сожалению.
	Ответить | Правка | ^ к родителю #424 | Наверх | Cообщить модератору

	435. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 07:17
	>Именно оттуда выросли все эти гендерно-феминистические бредни, SJW, дайверсити, эколухи и так далее Это мутации вроде фрейдо-"марксистов", они старательно поддерживаются правящими классами в европе и сша, что вполне логично (пусть все дерутся со всеми и с глобальным потеплением, чем поднимают действительно опасные для властей темы) Благодаря им левые на западе воспринимаются как юродивые, но к счастью положение постепенно меняется, не выйдет бесконечно дуить всем голову. Ильенкова, а не ильина конечно.
	Ответить | Правка | ^ к родителю #432 | Наверх | Cообщить модератору

	438. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 15-Дек-18, 07:47
	>>Именно оттуда выросли все эти гендерно-феминистические бредни, SJW, дайверсити, эколухи и так далее > Это мутации вроде фрейдо-"марксистов", они старательно поддерживаются правящими классами > в европе и сша, что вполне логично (пусть все дерутся со > всеми и с глобальным потеплением, чем поднимают действительно опасные для властей > темы) Благодаря им левые на западе воспринимаются как юродивые, но к > счастью положение постепенно меняется, не выйдет бесконечно дуить всем голову. В теории заговора я не верю, пардон, мне приходилось управлять и руководить людьми. Как бы то ни было, своё чёрное дело «новые левые» сделали и тотально промыли мозги по меньшей мере половине политически и общественно активного населения развитых стран. Поэтому симпатий к левакам я не испытываю, мягко говоря, даже если отвлечься от того, что они наделали в бывшем СССР.
	Ответить | Правка | ^ к родителю #435 | Наверх | Cообщить модератору

	439. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 10:14
	>В теории заговора я не верю Я тоже. А вот в сговор с целью подтолкнуть падающего вполне (см. жакерия). >симпатий к левакам я не испытываю, К счастью этого и ненужно. Ты либо применяешь теорию на практике и подтверждаешь её состоятельность, либо при неудаче пересматриваешь теорию с учётом того, как всё происходит на практике. Ну ещё можно радикально другую создать, но пока кроме фэнтази им.Фукуямы и средневекового мракобесия ничего не создали.
	Ответить | Правка | ^ к родителю #438 | Наверх | Cообщить модератору

	441. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 11:05
	>«новые левые» У Высоцкого даже песенка про них была. Ничего, уйдёт вся эта пена, разум победит "броуновское движение". В США вместо них были хиппи, тоже типа левые )
	Ответить | Правка | ^ к родителю #438 | Наверх | Cообщить модератору

	443. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 15-Дек-18, 11:31
	>>«новые левые» > У Высоцкого даже песенка про них была. Ничего, уйдёт вся эта пена, > разум победит "броуновское движение". В США вместо них были хиппи, тоже > типа левые ) Хиппи ведь не захватывали почту, банки и телеграф, не устраивали колхозы и концлагеря. И когда взрослели, то тихо-мирно завязывали (кто выжил) с различными излишествами. :-)
	Ответить | Правка | ^ к родителю #441 | Наверх | Cообщить модератору

	446. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 15-Дек-18, 12:39
	Потому и не захватывали, это были новые "левые", их сделали маргиналами и тихо слили в унитаз. Левым (для начала) нужно работать с конкретными проблемами, волнующими большинство трудящихся людей, а не за права зофилов и ...сексуалов и глобальным потеплением-похолоданием.
	Ответить | Правка | ^ к родителю #443 | Наверх | Cообщить модератору

	314. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:50
	> Кому надо, те не умеют. Вот в чём заковыка. Так пусть заплатят тем кто умеет, например? А, погодите, на это жаба давит? Кто-то хочет чтобы его проблемы решали другие, бесплатно, без смс, все и сразу? Слушай, чувак, я вот подумал. Мне вот пирога хочется. А давай ты мне пирог нахаляву сбацаешь? Ну его нафиг какие-то там программы и операционки, они невкусные, пироги лучше :)
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	324. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от пох (?), 13-Дек-18, 20:17
	> А, погодите, на это жаба давит? у гейца спрашивайте. Или у Дурова с его 2k btc. У них может хватить на оплату пары еще уцелевших нормальных программистов, которые умеют, но они что-то не спешат, наверное, и вправду жаба. У обычного смертного столько лишних денег не бывает. > Кто-то хочет чтобы его проблемы решали другие, бесплатно кто-то хочет чтобы эти другие, жадно хапающие бабки корпораций за кое-какерскую работу, прекратили ломать все, что не запретит корпорация и ныть что у них, видите ли, ресурсов не хватает. Хватает у них ресурсов. Еще и на всякие CoC хватило. И на замену fuck хватило. Меньше швыряйтесь _чужим_ трудом по собственной лени, дорогие генитальные разработчики. Или не удивляйтесь, что вас держат за $даков, а не за героев-спасителей с "бесплатным" софтом.
	Ответить | Правка | ^ к родителю #314 | Наверх | Cообщить модератору

	350. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 23:59
	На днях на Хабре было прекрасное. Манифест рок-звезды г-нокода: https://habr.com/post/432052/ Даже вот как-то жаль, что гопота повывелась и больше не ломает г-нокодерским рок-звёздам пальцы на верхних ногах томными вечерами ради забавы и чтоб на пивас насшибать.
	Ответить | Правка | ^ к родителю #324 | Наверх | Cообщить модератору

	383. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от пох (?), 14-Дек-18, 11:49
	ну, будем думать что звизде лет 25, только-только получила свой диплом с отличием и устроилась на первую или вторую работу. Потому что тут непонятно даже, плакать или смеяться. Чувак искренне страдает, что не может писать хороший код, ибо корпорасты не дают. Тут же упоминая линукс и тому подобные проекты, якобы написанные такими же гениями (это он себя, скорее всего переоценивает), но совершенно не желая взять в толк, что они-то это делали не за корпоративные зарплаты, а just for fun. Линуса кормили мама с папой, ank побирался где-то в системе академии наук, Эйк вот разьве что выделяется на общем фоне, ну так он как раз сделал худшее из современного софта(про остальные шадевры не в курсе, не мое). Кто-то пилил гранты, с которых тоже сыт не будешь, кто-то делал вид что работает, воруя время у работодателя (тот же Линус уже получивший диплом) А когда Линус сбежал из обанкротившейся трансметы (которой очень вряд ли был от него толк, помимо рекламы - и вряд ли она его хорошо кормила взамен), ank подался в топ-менеджеры, то, внезапно, создаваемый ими код перестал быть прекрасен и замечателен, или вовсе кончился как таковой. Потому что если ты сделал себе из распрекрасного хобби - работу - получать деньги за нее ты будешь от тех, кто перепродает ее результат, а им подавай то что хотят они, а не ты - и так как они хотят. можно добиться лучшего, если продавать результат, а не перепродавать, но это надо быть немножко менеджером (а это _другое_ хобби), и все равно покупатель будет всегда прав, разьве что часть того что под капотом, можно от него будет скрыть. забавно, что даже вариантов кроме лежать на дивание звизде в голову не приходит - видимо, типичный очкастый зад...т не имеющий вообще никаких интересов в жизни, кроме кодинга. Казалось бы - оставь свое хобби - хобби, раз тебе в нем процесс важнее результата, а зарабатывай чем-нибудь на что можешь смотреть без отвращения (и да, если что - про выгул собак я серьезно), но не убиваясь по поводу качества выполняемой работы. Только вот не надо про "сотни бессонных ночей, потраченных на изучение разработки". Я потратил изрядную часть дней и ночей (и в ущерб карьере), здоровья и нервов, которые не вернешь, на свое хобби, из которого никогда не сделаю источник заработка (в том числе и потому, что поздно начал, но в неменьшей степени - потому что это будет работа, а работать этим я категорически не хочу).
	Ответить | Правка | ^ к родителю #350 | Наверх | Cообщить модератору

	384. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 14-Дек-18, 12:12
	> Эйк вот разьве что А кто это?
	Ответить | Правка | ^ к родителю #383 | Наверх | Cообщить модератору

	429. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от псевдонимус (?), 14-Дек-18, 22:50
	>> Эйк вот разьве что > А кто это? Видимо имеется ввиду злодей, сделавший яваскрипт. Айк его обычно транскрибируют.
	Ответить | Правка | ^ к родителю #384 | Наверх | Cообщить модератору

	479. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 22:24
	> у гейца спрашивайте. Или у Дурова с его 2k btc. > У них может хватить на оплату пары еще уцелевших нормальных программистов, которые > умеют, но они что-то не спешат, наверное, и вправду жаба. Да он и оплачивает иногда. Вон у него Yann Colett вкалывает - автор LZ4. Сколько Нормальных Программистов вообще сможет побить по скорости алгоритм от чувака, который изначально был вообще маркетологом? Ну вот то-то и оно - уцелевшие нормальные программисты започивались на лаврах, заржавели, обленились и растратили скилл. На этой почве их и стали замещать другие. Уж какие есть. > У обычного смертного столько лишних денег не бывает. И чего? Купить себе частный авиалайнер как у нужного стране почетного академика тоже не каждый сможет, пожалуй. > прекратили ломать все, что не запретит корпорация и ныть что у > них, видите ли, ресурсов не хватает. Так это, никто не запрещает пользоваться старыми версиями без улучшений и коекакеров, работать работы самому, или чего там еще. А так это вопрос цены-качества. И если рынок хочет в целом так - значит будет в основном так. Кто ж виноват что макдональдсы популярнее чем стряпнина шеф-повара мирового уровня? Просто потому что работа шеф-повара не нацелена на массовое обслуживание и ее на всех не хватит. И с софтом так же, бида-била. > Хватает у них ресурсов. Еще и на всякие CoC хватило. И на замену fuck хватило. Так написать скриптики/регулярки отлова факов - особой квалификации не надо. Это как бы в принципе любой админ юниксобразных должен уметь, который даже и не програмер особо. А более продвинутым прогерам есть чем заняться и кроме замены факов. > Меньше швыряйтесь _чужим_ трудом по собственной лени, дорогие генитальные разработчики. В линуксе все просто - чужой труд вышвыривают если на него забил автор и его единомышленники, так что код оказался неподдерживаемым. По-моему вполне честный критерий. > Или не удивляйтесь, что вас держат за $даков, а не за героев-спасителей > с "бесплатным" софтом. Так колхоз дело добровольное - никто чисто технически не может обязать тебя юзать конкретный софт конкретной версии. Пользуйся нормальным софтом от нормальных людей или пиши сам. Или дай денег тем кто напишет так как тебе надо. А какие варанты есть? Ты хочешь прийти в макдональдс, заплатив как в макдональдсе, но пожрать как в элитном рестаране, чтобы для тебя шефповар персонально напрягся сделать твой любимый рецепт? У макдональдса для этого нет ресурсов. И у крутого ресторана нет - поэтому они ставят цены такими, что это доступно лишь очень сильно некоторым. Ну вот так вот.
	Ответить | Правка | ^ к родителю #324 | Наверх | Cообщить модератору

	493. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 16-Дек-18, 00:13
	>> Меньше швыряйтесь _чужим_ трудом по собственной лени, дорогие генитальные разработчики. > В линуксе все просто - чужой труд вышвыривают если на него забил > автор и его единомышленники, так что код оказался неподдерживаемым. По-моему вполне > честный критерий. А вот и нет. В линуксе частенько вышвыривают (или не принимают) чужой труд только потому, что автор «не с нашева раёна и неправильный пацан». Достойны отдельной саги сюжеты про OSS, а затем и про ALSA. И ещё немало других технологий, похороненных линуксоидами на кладбище изобретений, вспоминается.
	Ответить | Правка | ^ к родителю #479 | Наверх | Cообщить модератору

	502. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 17:56
	> А вот и нет. В линуксе частенько вышвыривают (или не принимают) чужой > труд только потому, что автор «не с нашева раёна и неправильный пацан». Пацана никто не заставлял комитить туда. И если пацан слился, за него его работу вечно делать как бы никто не обязан. Так что как только это начинает икаться другим - так и досвидос. Опять же - все эти условия и политики общеизвестны. Если кому-то хочется чего-то иного - наверное ему логично пользоваться чем-то иным. Но вот учить линуксоидов жизни из под 6-й нти - не работало и работать не будет. Хотя-бы потому что те кто разрабатывают линукс - 6-ми нтями не пользуются. Это ж вам не реактос позорный, не способный даже нужды разработчиков обслужить. > Достойны отдельной саги сюжеты про OSS, а затем и про ALSA. И > ещё немало других технологий, похороненных линуксоидами на кладбище изобретений, вспоминается. Линуксоиды виноваты лишь тем что их подходы в целом сработали лучше, чем это. Кто-то заставлял OSS зависеть от 1 фирмочки, а ту давиться жабой? С линуксоидами попытка давиться жабой - приводит к очень жестоким последствиям. Те кто поумнее понял это по хорошему. Те кто поглупее, узнал это методом OSS и Bitbaker-а. Если линуксоидам пытаются что-то прищемлять - они умеют за это поднапрячься и навалять, так что мало потом не покажется. Этот факт проприетарщикам лучше всего запомнить и сделать выводы. А кто не сможет - пардон, ребятки, но вы с неправильной стороны пулемета и линуксоиды очень в настроении нажать на спуск почему-то.
	Ответить | Правка | ^ к родителю #493 | Наверх | Cообщить модератору

	506. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 16-Дек-18, 18:44
	> Если линуксоидам пытаются что-то прищемлять > - они умеют за это поднапрячься и навалять, Пока получается далеко не так. Изобретены ли "линуксоидами" хотя бы одна технология или техническое решение, принятые впоследствии коммерческим сектором (на условиях gpl и т.д.)? Отбились ли "линуксоиды" от принятия хотя бы одного непопулярного технического решения? Заставили ли "линуксоиды" коммерческий сектор пойти хотя бы на одну существенную уступку? Да, и то, что коммерческий сектор проезжается на бесплатном труде миллионов, не в счёт -- они решают *собственные* проблемы. А вот там, где они *не* решают собственных проблем?
	Ответить | Правка | ^ к родителю #502 | Наверх | Cообщить модератору

9. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+4 +/–
Сообщение от Аноним (9), 12-Дек-18, 23:05
Как же это по-линуксовому. Реализовывать что-либо, потратив много денег и человеко-часов инженеров. А когда всё готово - заявить что это "не развивается" и удалить. Примеров масса, я думаю вы их приведёте и без меня
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от A.Stahl (ok), 12-Дек-18, 23:09
	А представь сколько ресурсов было потрачено на разработку и совершенствование паровых двигателей! Жуть просто. Да что там двигатели... Философский камень! Просто чёрная дыра для ресурсов.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	19. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (17), 12-Дек-18, 23:26
	> А представь сколько ресурсов было потрачено на разработку и совершенствование паровых двигателей! И, полагаю, это одна из причин, почему через 5 лет после их создания никто не сказал: что-то многие всё ещё на лошадях ездят, давайте перестанем выпускать паровые двигатели, а ресурсы пустим на выращивание ещё большего количества сена.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	20. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (9), 12-Дек-18, 23:29
	Лошади это x86, паровоз это x86_64, а x86_x32 это велосипед
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	25. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (17), 12-Дек-18, 23:34
	> Лошади это x86, паровоз это x86_64, а x86_x32 это велосипед ia32 - это ручная тележка (можно даже в квартиру завезти, места много не требует, для большинства ручных задач подходит), amd64 - паровоз (мощный и быстрый, частнику такое не купить, но может целые составы возить), x32 - автомобиль (такой жы быстрый, как паровоз, но дешевле и меньше требует места, хотя состав с углём всё же не повезёт).
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	26. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от A.Stahl (ok), 12-Дек-18, 23:39
	>x32 - автомобиль Только в отличие от привычных обиходных автомобилей ездит на 2-фосфат-этилен-3-бензол-гидроксиде и запчасти к нему нужно делать самому по чертежам на тюркском варианте клингонского языка.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	34. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (17), 12-Дек-18, 23:49
	Только в отличие от привычных обиходных карет ездит на 2-фосфат-этилен-3-бензол-гидроксиде и запчасти к нему нужно делать самому по чертежам на латинском варианте английского языка. -- современник Г. Форда
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	49. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 13-Дек-18, 00:36
	Глаза мои!!!
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	315. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:54
	> amd64 - паровоз (мощный и быстрый, частнику такое не купить, но может > целые составы возить), Фокус в том что паровозы подешевели, таки теперь и частнику купить, в типовой гараж умещается, и вообще - ширпотреб. Да еще к тому же док Mr. Fusion на проволоку примотал, так что он вообще вертикально взлетает и фигачит куда захочет, а рельсы вообще как бы и не нужны.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	334. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Онаним (?), 13-Дек-18, 20:34
	> x32 - автомобиль x32 - это паровоз с колёсами от тележки
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	29. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от Аноним (17), 12-Дек-18, 23:43
	> Лошади это x86, паровоз это x86_64, а x86_x32 это велосипед У нас на работу ~10% человек ездят на велосипедах. Для сравнения: на лошадях и паровозах вместе взятых ездят 0%. А ещё велосипед на ночь/на зиму можно убрать в квартиру или на балкон. С лошадью возникнут некоторые проблемы. С паровозом возникнут большие проблемы. А ещё паровоз без специально подготовленной поверхности (рельс) никуда не поедет. В отличие от. Если велосипед ломается, его можно либо починить, либо довезти до дома рядом с собой (если колёса и рама целы). С паровозом возникнут проблемы. И я даже писать не буду, как решаются подобного рода проблемы в случае лошади.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	50. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Michael Shigorin (ok), 13-Дек-18, 00:38
	Да щаз.  Тут вон под боком Тимирязевский парк -- так и на лошадях, и на паровозах никакой не ноль процентов передвигается.  Хотя на паровозах всё-таки больше, может, даже сопоставимо с велосипедами, если посчитать. PS: не ради спору, просто уж больно ярко это всё перед глазами встало :)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	185. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 11:15
	> У нас на работу ~10% человек ездят на велосипедах. Для сравнения: на > лошадях и паровозах вместе взятых ездят 0%. ну так у вас ни депо не оборудовано на работе, ни конюшня или хотя бы коновязь (но хороший хозяин лошадь у коновязи на целый день не бросит), ржавую железяку для пристегивания великов вот притащили, и довольны. Собственно, и с x32 такая же хрень. > А ещё велосипед на ночь/на зиму можно убрать в квартиру или на > балкон. С лошадью возникнут некоторые проблемы. С паровозом возникнут большие проблемы. лошадь и паровоз не надо убирать на зиму - они всесезонные. > И я даже писать не буду, как решаются подобного рода проблемы > в случае лошади. да элементарно - была лошадь, стала конина. а с линукса этого вашего даже поганого воняющего рыбьим жиром пингвинячьего мяса не получить :-(
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	480. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 22:28
	> или хотя бы коновязь (но хороший хозяин лошадь у коновязи на > целый день не бросит), ржавую железяку для пристегивания великов вот притащили, Дарю идею - можете парковать там своих лошадей, господа. Будете лайфхакерами!
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	316. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:55
	> И я даже писать не буду, как решаются подобного рода проблемы > в случае лошади. Вызовом Торвальдса.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	101. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (10), 13-Дек-18, 05:09
	>Реализовывать что-либо, потратив много денег и человеко-часов инженеров. А когда всё готово - заявить что это "не развивается" и удалить. Intel потратил деньги и человекочасы, а поддерживать надо сообществу
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	186. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от нах (?), 13-Дек-18, 11:19
	>>Реализовывать что-либо, потратив много денег и человеко-часов инженеров. А когда всё готово - заявить что это "не развивается" и удалить. > Intel потратил деньги и человекочасы, а поддерживать надо сообществу ох оно перенапряглось "поддерживать" (а, ну да, ну да - stable api is nonsense)
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

12. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
Сообщение от Аноним (12), 12-Дек-18, 23:10
Давно пора! Это будет толчком "для других"!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	201. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от ананим.orig (?), 13-Дек-18, 12:06
	Ты даже не понимаешь о чем сабж. Зыж имхо, сабж можно оставить, а вот 32 бита пусть бы выпиливали.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	351. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от Аноним (351), 14-Дек-18, 00:09
	32 бита нужно оставить для совместимости со старым железом.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	391. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 14-Дек-18, 14:52
	зачем вам на железе 2007го года выпуска - самое распоследнее ведро линукса? Ему там памяти не хватит, не может оно в 12 мегабайтах. К тому же те же аргументы прекрасно работают и тут - производителями дистрибутивов не поддерживается (во всяком случае, установка давно превратилась в сложный квест), согласно показаниям телеметрии не поддерживающих этот аби дистрибутивов - все 100% их пользователей этот аби не используют и т д. но ключевая разница - что таких процессоров действительно уже лет десять не делают вообще. В отличие от 64битных с <4G оперативы, не подлежащей апгрейду.
	Ответить | Правка | ^ к родителю #351 | Наверх | Cообщить модератору

14. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от GentooBoy (ok), 12-Дек-18, 23:11
В 2013 году на генте юзал так как была необходимость оперативку экономить. Теперь такая необходимость отпала. Так что удаление вполне оправдано.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от Аноним (16), 12-Дек-18, 23:21
	У всех отпала?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	187. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+4 +/–
	Сообщение от Аноним (187), 13-Дек-18, 11:22
	В сотый раз говорю - где вы в последние три года видели технику с менее 8 гигов памяти? Я не видел уже давно - везде от 16 стоит, даже у бухов и отдела маркетинга. Про дизайнеров и графику (чем сам занимаюсь) не говорю - тут специфика и 64-128 обычное дело.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	191. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от нах (?), 13-Дек-18, 11:37
	в сотый раз тебе говорят - если в твоей младшей группе детсада для одаренных детей-дизайнеров ты чего-то не видел - это просто потому, что ты пока еще маленький. на, вот, можешь посмотреть, если воспиталка разрешит: https://www.aliexpress.com/item/Original-CHUWI-Hi10-Air-tabl... https://www.aliexpress.com/item/ALLDOCUBE-KNote5-11-6-inch-F... разумеется, на них установлена божественная десяточка и проблемы этих ваших линуксов большинству их покупателей по барабану, впрочем, "занимающийся дизайном и графикой", сдается мне, тоже не в гимпе рисует свой хентай.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	199. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+7 +/–
	Сообщение от Аноним (187), 13-Дек-18, 11:48
	>если в твоей младшей группе детсада >на, вот, можешь посмотреть, если воспиталка разрешит Какой ты культурный и воспитанный, нечто просто. Тебе конструктив, а ты на личности. Фу таким быть, голубь. >тоже не в гимпе рисует Опенсорсие, простихосспаде, не пользуем и я всячески отговариваю коллег от любых поползновений в сторону блендера. Такие вещи должны пресекаться на корню.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	204. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 12:11
	> Тебе конструктив конструктив уровня "я не видел - значит не бывает!" - заслуживает ровно такого уровня ответов. ну вот по ссылочкам сходил - теперь видел? Для чего оно такое надо - догадаешься? Нет, понятное дело, дизайном или разработочкой новых прекрасных шадевров блоатвари на них не позанимаешься, но не всем, внезапно, и надо. в чем там загадка этих бэйтрейлов, что им нельзя распаять восемь - хз, но, видимо,что-то мешает. С другой стороны, нафига платить больше?
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	572. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Алексей Михайлович (?), 17-Дек-18, 18:53
	> я всячески отговариваю коллег от любых поползновений в сторону блендера Это ещё зачем?
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	203. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от ананим.orig (?), 13-Дек-18, 12:09
	> В сотый раз говорю - где вы в последние три года видели технику с менее 8 гигов памяти? Ну да! Офигенный повод отдать её одному юзерспейсному приложению.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	205. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 12:12
	современные разработчики ведра - однозадачные.
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	206. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от Аноним (187), 13-Дек-18, 12:13
	>Офигенный повод отдать её одному юзерспейсному приложению Ты не поверишь, но да. Во время работы Maya, Max, Nuke, итд спокойно могут выжрать все 64гб и нагадить еще столько же в своп.
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	234. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от ананим.orig (?), 13-Дек-18, 14:02
	Не успеют. Какой-нить новый и текущий фф сожрет первым. Или очередной пасьянс А вот если его собрать в сабжевом x32, а твою майю/этк в 64, то всё будет ок. (Даже на ipc не повлияет, т.к. сабж работает на 64-платформе и ничем от других 64-битных прог кроме внутреннего использования 32-разрядных указателей).
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	277. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (187), 13-Дек-18, 16:48
	>Какой-нить новый и текущий фф сожрет первым Последний (или предпоследний) фф, открыто вкладок 10 с лентами тумблера, девиантарт, artstation, и пару вкладок с порнхабом - потребление лисой памяти меньше гига. Аптайм лисы - примерно неделя. Что я делаю не так? Ах, да, у меня винда.
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	518. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Ванёк (?), 16-Дек-18, 22:43
	Открываешь мало вкладок!
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	212. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (212), 13-Дек-18, 12:19
	Видим в магазинах СЕЙЧАС 4 Гб
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	575. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Адекват (ok), 18-Дек-18, 10:40
	Во всех без исключения гос учреждениях на компах сотрудников от 2 до 4 Гб оперативы.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	18. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+7 +/–
	Сообщение от Аноним (17), 12-Дек-18, 23:24
	> Теперь такая необходимость отпала. Так что удаление вполне оправдано. Аноним с опеннета докупил памяти - архитектуру из ядра можно удалять. Отпишись там, в lkml, а то тамошние дядьки какими-то аргументами оперировать пытаются, разбираются в вопросе. А архитектура-то тебе уже и не нужна.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	24. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (22), 12-Дек-18, 23:33
	Тамошние дядьки - это не Тео, им корпорации железо покупают топовое, ведь запланированное устаревание само собой не возьмётся.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	104. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Мастер над релизами (?), 13-Дек-18, 05:21
	>им корпорации железо покупают топовое А, кто, кто я вас спрашиваю подумает о простом анониме с опеннета? Даёшь линукс с человеческим лицом, для народа.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	133. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от анон (?), 13-Дек-18, 07:56
	Даешь форк и сопровождаешь его
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	210. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (210), 13-Дек-18, 12:17
	Форк анонима?
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	39. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+4 +/–
	Сообщение от Гентушник (ok), 13-Дек-18, 00:08
	Ну, может этот аноним и был единственным пользователем этой фичи? Если она теперь ему не нужна, то можно и удалять.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

40. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (9), 13-Дек-18, 00:09
Это не удивительно, что из Линукса хотят убрать x86_x32. Это же только десктопная фича, не используемая на серверах. А Линусу и другим программистам давно плевать на десктоп. Удивительно как вообще приняли изначально? Причём ясно это было уже давно. Почитайте комментарии под новостью от 2007 года: https://www.linux.org.ru/news/linux-general/2042898 (начиная с коммента "Неладно что-то в Датском королевстве"). Админ, зачем ты удаляешь ссылки на LOR? Вы же друзья, и даже в 2013 махнулись с ним дизайном на 1 апреля! В антимат-фильтр добавьте тогда уж P.S. Ссылка на интервью, которое обсуждается по ссылке, тут: http://www.apcmag.com/why_i_quit_kernel_developer_con_koliva.../ http://www.apcmag.com/interview_with_con_kolivas_part_1_comp... http://www.apcmag.com/interview_with_con_kolivas_part_2_his_...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от Crazy Alex (ok), 13-Дек-18, 00:32
	Блин, да она нигде, считай, не используемая. Кроме генты я не припомню ни одного дистрибутива, умеющего x32. Опять же - если окажутся желающие пользоваться и поддерживать - оставят, не впервой. Впрочем. что-то объяснять лоровцу, снова вытянувшему эпопею с кривыми патчами Коливаса, смысла, наверное, нет.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	56. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (10), 13-Дек-18, 00:48
	>Кроме генты я не припомню ни одного дистрибутива, умеющего x32 В debian есть (была?) неофициальная поддержка
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	105. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (514), 13-Дек-18, 05:44
	>Это не удивительно, что из Линукса хотят убрать x86_x32. Это же только десктопная фича, не используемая на серверах. Знаете ли Вы, что многие VDS имеют <= 4Гб памяти, а если и имеют, то там ведь не одно приложение крутиться? Я бы сказал, что VDS c 8Гб памяти большая редкость. Учитывая, что браузера так и не осилили x86_x32 это можно назвать чисто серверной фичей.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	248. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (9), 13-Дек-18, 15:14
	Как это "не осилили"? В Chromium одна вкладка - один процесс
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	317. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 18:57
	> Как это "не осилили"? В Chromium одна вкладка - один процесс А v8 не умеет jit в x32 ABI. И соответственно JS пролетает как фанера над парижем. Зачем тебе платформа где JS в браузере толком не работает? :)
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

45. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+7 +/–
Сообщение от Аноним (45), 13-Дек-18, 00:26
Хватит ли мне пальцев одной руки, чтобы пересчитать анонимов с опеннета+лора вместе взятых, которые этот функционал в реальности использовали?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+6 +/–
	Сообщение от Michael Shigorin (ok), 13-Дек-18, 00:43
	Боюсь, хватит, даже если Вы матёрый и лихой фрезеровщик...
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	144. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (144), 13-Дек-18, 08:42
	Уже не хватит, Миш.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	519. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ванёк (?), 16-Дек-18, 22:46
	Мишаня запамятовал встраиваемые системы, где лишний объём памяти выливается в увеличение габаритов, цены и энергопотребления устройств и соответственно уменьшения их автономности.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

46. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
Сообщение от vadiml (ok), 13-Дек-18, 00:30
Жаль что не взлетело - для GUI бы подошло, когда основная система 64-битная -- большинство GUI-программ очень далеко до 4 гиг.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	75. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Crazy Alex (ok), 13-Дек-18, 01:47
	Жаль, но таки не взлетело
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	295. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от fi (ok), 13-Дек-18, 17:48
	Не то слово! Очень жаль! там где можно использовать оптимизацию под x64 (регистры и etc.) и требуется большой кэш (команды x32 меньше потребляет кэш чем x64) - вот где рост производительности!
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	564. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Zulu (?), 17-Дек-18, 15:16
	На десктопе сейчас ровно одна главная программа, и она 4Г съест легко. Называется browser.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	565. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 17-Дек-18, 15:45
	> На десктопе сейчас ровно одна главная программа, и она 4Г съест легко. > Называется browser. Лечится заменой этой программы на Firefox 3.5.19 или Seamonkey 2.0.14 (оба с ненужнодвижком версии 1.9.1.19). Они не тормозят и не жрут память. Глоток чистого свежего воздуха после browser. Но модно-прогрессивные сайты в них смотреть, скорее всего, не получится.
	Ответить | Правка | ^ к родителю #564 | Наверх | Cообщить модератору

	585. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Zulu (?), 18-Дек-18, 19:42
	То есть не получится делать то, ради чего вообще эта программа нужна. Эпичная победа, что уж.
	Ответить | Правка | ^ к родителю #565 | Наверх | Cообщить модератору

	587. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 18-Дек-18, 20:09
	Ну так за эти пару лет Гугель подмял под себя все интернеты и произошло несколько скандалов с сертификатами. Вот и превращаются программы в тыквы.
	Ответить | Правка | ^ к родителю #585 | Наверх | Cообщить модератору

53. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (53), 13-Дек-18, 00:42
Просветите, плиз. Таким же образом реализовано выполнение 32-кода в 64-разрядной Винде?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	70. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 01:27
	> Просветите, плиз. > Таким же образом реализовано выполнение 32-кода в 64-разрядной Винде? Гугли про WoW: google.com/search?q=Windows+on+Windows Добавлю неофициально, что в принципе можно запускать и 16-разрядный софт, но майки соответствующие средства из 64-разрядных ОС убрали, так что придётся вручную и на свой страх и риск.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	217. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от userd (ok), 13-Дек-18, 12:47
	нет.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	279. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от КО (?), 13-Дек-18, 16:51
	Также как и x86 в Линуксе (если не вдаваться в детали). x32 это отдельная песня. Про использование всех регистров, но при 32х битной адресации.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	326. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от Himik (ok), 13-Дек-18, 20:22
	Да. Этот "x32" по процессорной документации так и называется Compatible Mode.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	574. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Michael Shigorin (ok), 17-Дек-18, 23:31
	> Да. Этот "x32" по процессорной документации так и называется > Compatible Mode. Вы точно не путаете систему команд IA32 и x32 ABI?
	Ответить | Правка | ^ к родителю #326 | Наверх | Cообщить модератору

77. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–7 +/–
Сообщение от OldFart (?), 13-Дек-18, 01:54
Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб памяти и 32битовыми процами ? Компы специализорованные, хрен заменишь, станочки от $100к и выше, накладенько менять то? Зря ИМХО это они, автоматики навалом на старом железе (хотя даже того старого с головой хватает, максимум на 10% загруженно, на хер там сдался x64)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	85. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (85), 13-Дек-18, 02:17
	И зачем им новое ядро? на CentOS 5/6/7 протянут. У меня есть реальный случай когда девайс работал строго под Win95/98 и работает до сих пор. Он огорожен, на нем нет дров для USB, к нему таскают задачи на болванках, но он работает, а его современные аналоги стоят миллионы рублей.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	88. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 02:24
	> Может им послать фотки с завода, на котором уйма индустриальных станков с > 256Мб памяти и 32битовыми процами ? Компы специализорованные, хрен заменишь, станочки > от $100к и выше, накладенько менять то? Зря ИМХО это они, > автоматики навалом на старом железе (хотя даже того старого с головой > хватает, максимум на 10% загруженно, на хер там сдался x64) Здесь не поймут. Я уже пытался донести до опеннетовской публики основные идеи производственного и промышленного использования ИТ.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	108. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+10 +/–
	Сообщение от Аноним (108), 13-Дек-18, 06:02
	Да ты наркоман, планировать использование никем не тестируемой кодовой базы на промышленном оборудовании. Конечно, тебя адекватные люди не поймут. Речь же про x32, если ты забыл, которую использует в паре тестов производительности два разработчика и гентушники. Ну да, самое оно прочить это для промышленного использования. На секундочку, x86 никто не выкидывает, и специальное оборудование, так красочно описываемое выше, работает на нем.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	238. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (374), 13-Дек-18, 14:44
	Очень трогательно, что ты заботишься о том, чтобы буржуй мог купить себе еще один кайен, вместо разбитого по пьяни на прошлой неделе и десяток новых лядей, но мы таки да, не поймем.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	287. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:10
	Классовая и сословная солидарность с буржуями. У нас дворцы, у вас халупы. :)
	Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

	91. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от AnonPlus (?), 13-Дек-18, 02:39
	Лучше пошлите нам фотки, как вы на машины с 256 памяти ставите дистрибутив на свежайшем ядре. А если не ставите, то какая вам разница, чего там выкинут в ядре, которое вы не ставите?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	95. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 03:02
	Не самое свежее, зато сразу с Иксами, оконным менеджером и другими программами: https://i2.imageban.ru/out/2018/11/16/316ac015031f62d6f8a542... И там есть ещё куда оптимизировать.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	120. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (108), 13-Дек-18, 06:25
	> Лучше пошлите нам фотки подписываюсь! tits or GTFO
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	93. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+6 +/–
	Сообщение от axredneck (?), 13-Дек-18, 02:54
	> станков с 256Мб памяти и 32битовыми процами Речь идет про 64-битные процы и 32-битные указатели на них.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	111. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от freehck (ok), 13-Дек-18, 06:17
	> Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб памяти и 32битовыми процами ? А при чём тут 32х-битные процы? x32 -- это один из вариантов поддержки 32-битных приложений в 64-х разрядной системе.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	158. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 09:28
	>> Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб памяти и 32битовыми процами ? > А при чём тут 32х-битные процы? x32 -- это один из вариантов > поддержки 32-битных приложений в 64-х разрядной системе. При том, что 32-битных писюковых уже нет новых в продаже (если не учитывать всякое специализированное железо). Хочешь не хочешь, а купишь AMD64. И затем уже разные варианты начинаются. Писюковое железо часто используют из-за его дешевизны. Любое специализированное железо стоит в разы дороже, как минимум.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	175. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Нанонимус (?), 13-Дек-18, 10:45
	> Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб памяти и 32битовыми процами? x32 к этому никакого отношения не имеет. ia32 никто выкидывать не собирается, так что станки как работали, так и будут работать.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	178. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 10:54
	>> Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб памяти и 32битовыми процами? > x32 к этому никакого отношения не имеет. ia32 никто выкидывать не собирается, > так что станки как работали, так и будут работать. Ну давай ещё десять энергичных анонимов мне напишет, что x32 это не синоним x86, чтоб я уже занервничал наконец. Для не умеющих понимать русскую речь с первой попытки пишу специально: речь в этой дискуссии об экономии значительных ресурсов (как выше пишут — 30 процентов не фантазия) на железе AMD64. А другого в продаже и нету, внезапно. Пока было, использовали 32-битные ОС с ядром для PAE. Дошло уже наконец или ещё надо разъяснять?
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	223. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Нанонимус (?), 13-Дек-18, 13:06
	> Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб памяти и 32битовыми процами? Еще раз, у тебя станки с 256М памяти, что ты там собрался делать с x32?!
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	318. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (-), 13-Дек-18, 18:58
	> Еще раз, у тебя станки с 256М памяти, что ты там собрался делать с x32?! Ну, понимаешь, он NT6 чтототам использует, там такого ABI нет как класса, поэтому он за фичу болеет чисто теоретически. Теоретик блин диванный от промышленности. Оказывается и такое тоже бывает :)
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	385. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Нанонимус (?), 14-Дек-18, 14:14
	>> Еще раз, у тебя станки с 256М памяти, что ты там собрался делать с x32?! > Ну, понимаешь, он NT6 чтототам использует, там такого ABI нет как класса, > поэтому он за фичу болеет чисто теоретически. Теоретик блин диванный от > промышленности. Оказывается и такое тоже бывает :) Причем втирает начальству, что для 256М памяти ну прямо-таки жизненно необходим x32 режим, и как следствие -- пересборка софта с x32 Elf'ом.
	Ответить | Правка | ^ к родителю #318 | Наверх | Cообщить модератору

	481. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 22:32
	> Причем втирает начальству, что для 256М памяти ну прямо-таки жизненно необходим x32 > режим, и как следствие -- пересборка софта с x32 Elf'ом. Я мягко говоря сомневаюсь что на бортовом компьютере ископаемого станка вообще сможет x32 ABI запуститься - оно таки требует чтобы это был таки 64-битный процессор. А у такой древности процессор скорее всего без 64-битного режима вообще. Так что ABI не светит даже чисто теоретически, на уровне умений железа. Но теоретик даже это не понял когда размахивал станками.
	Ответить | Правка | ^ к родителю #385 | Наверх | Cообщить модератору

	237. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от meantraitor (?), 13-Дек-18, 14:12
	Разъясните, пожалуйста, еще. Никак не могу взять в толк, что вам мешает запускать 32-битные приложения на 64-битном ядре? И я вам тоже могу написать: 30% - фантазия, на самом деле - 10%. Дальше что?
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	297. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от fi (ok), 13-Дек-18, 17:51
	32-битные приложения на 64-битном ядре запускают в  32-окружении, а x32 - это 32-битные приложения в  <вот новость то!!!> 64-окружении!!!
	Ответить | Правка | ^ к родителю #237 | Наверх | Cообщить модератору

	302. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от meantraitor (?), 13-Дек-18, 18:02
	Я знаю. Дальше-то что? Речь тут шла про 32-битные приложения. Ну и запускайте себе 32-битные приложения в 32-битном окружении на 64-битном ядре, если вам так нравится.
	Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

	371. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от freehck (ok), 14-Дек-18, 09:19
	> Дошло уже наконец или ещё надо разъяснять? За себя скажу, что надо.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	375. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 09:45
	>> Дошло уже наконец или ещё надо разъяснять? > За себя скажу, что надо. Некоторые шибко ретивые анонимы уверены, что они умнее всех, а вокруг все глупые и не понимают разницы между такими, например, вещами как IA32, IA64, X32, x86, x86_64, AMD64, EM64T, и в связи с такой непоколебимой уверенностью считают своим долгом лезть во всякий посторонний разговор со своими очень-очень нужными и незаменимыми замечаниями. RTFM по этой ссылке: https://sites.google.com/site/x32abi/documents (начиная с файла api.pdf). Как уже не раз было и здесь сказано, X32 — это такая особая среда для приложений, работающих в 64-разрядной операционной системе по 32-разрядной модели адресации памяти, за счёт чего они потребляют её как обычные 32-разрядные приложения, но пользуются всеми остальными преимуществами 64-разрядных. Это может быть выгодно с точки зрения накладных расходов и экономии ресурсов. Фактически все процессоры x86_64 заведомо умеют исполнять 32-битный код без какого-то значимого ущерба. Как-то так.
	Ответить | Правка | ^ к родителю #371 | Наверх | Cообщить модератору

	378. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от freehck (ok), 14-Дек-18, 09:59
	Чувак, читал бы ты тред повнимательнее. =/
	Ответить | Правка | ^ к родителю #375 | Наверх | Cообщить модератору

	386. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (386), 14-Дек-18, 14:37
	да тут 3/4 сообщений - его
	Ответить | Правка | ^ к родителю #378 | Наверх | Cообщить модератору

	405. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 15:59
	Зачем я буду читать комментарии малолетних обиженок и мамкиных кульхацкеров, в которых они обсасывают мою воображаемую персону? На этом форуме всегда стирают комментарии, написанные в свою защиту, но почему-то всегда оставляют напоказ эти вот «обсуждения исподтишка» (это ведь не маты, не оскорбления и не переходы на личность, нет-нет). Очень в духе праволапчатого подложного СПО.
	Ответить | Правка | ^ к родителю #378 | Наверх | Cообщить модератору

	440. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Благодарный читатель. (?), 15-Дек-18, 10:56
	И здесь Вас не не уважают? Кругом враги? Ну надо же! Обидно, правда?
	Ответить | Правка | ^ к родителю #405 | Наверх | Cообщить модератору

	376. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 09:47
	>> Дошло уже наконец или ещё надо разъяснять? > За себя скажу, что надо.     Дополню ссылкой на пояснения Интела:   https://software.intel.com/en-us/node/628948     И процитирую даже:   > The x32 psABI is a native 32-bit processor-specific ABI for Intel® 64 (x86-64) architecture. The Linux* kernel v3.6 supports x32 psABI. ABI support on Linux is enabled by setting CONFIG_X86_X32=y in the .config file.   > Using the x32 psABI allows programs to run in the 64-bit mode while using 32-bit pointers, thereby reducing memory footprint and file size, as a result of which programs may run faster. In other words, using this ABI may bring significant performance gain for many applications in terms of extra registers available on 64-bit processors without the size (cache) penalty of using 64-bit pointers. However, programs will be limited to 4GB virtual address space (not all applications require more than 4 GB memory space).
	Ответить | Правка | ^ к родителю #371 | Наверх | Cообщить модератору

	127. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Анонимный прохожий (?), 13-Дек-18, 07:47
	> Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб памяти и 32битовыми процами ? Чукча не читатель, чукча - писатель.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	353. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от OldFart (?), 14-Дек-18, 00:55
	>> Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб памяти и 32битовыми процами ? > Чукча не читатель, чукча - писатель. Согласен :( Читать внимательней надо было... думал на ia32 позарились...
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	482. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (482), 15-Дек-18, 22:36
	> Чукча не читатель, чукча - писатель. Пусть таки попробует x32 ABI запустить на этих станках, для начала. А то это чего доброго окажется невозможно сделать даже чисто теоретически. И окажется воитель за x32 ABI всего лишь Доном Кихотом.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	135. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от анон (?), 13-Дек-18, 07:58
	А теперь поясните на кой хрен в станках менять софт если они работают?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	193. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от нах (?), 13-Дек-18, 11:40
	дохнут они, не поверишь, станки-то. Причем механика живет долго, хотя точность и снижается, а вот управляющее ей железо - как обычно, тем более что условия в цеху бывают далеки от ЦОДов.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	387. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (386), 14-Дек-18, 14:41
	И? Софт менять? Да там на складах всякие LPT с i286 еще в масляной бумаге лежат, их тебе за 100500 денег и отгрузят, софт уже в них. А куда ты денешься. А кто склады не наполнил в свое время, так те поумирали уже. Только в розово-коричневых фантазиях вебмакак могла возникнуть мысль о переписывании софта для станков каждый год. Ты ж вроде не из этих извращенцев?
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	392. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 14-Дек-18, 15:00
	> А кто склады не наполнил в свое время, так те поумирали уже. неа, у меня приятель прекрасно подрабатывает заменой сдохшей производственной _механо_автоматики самоделками на базе всяких мелкопроцессорных чипов (уж не знаю что сейчас там модно, пики или уже все на горе-ардуины перебрались) склады как-то, видимо, позакончились, но тяжелые механизмы еще живы, а менять их то ли не на что, то ли незачем. Ну и раз у него нет проблем с икрой на хлебушек - значит, не поумирали и не обанкротились. А в тех 286 уже и текстолит того-сь, расслоился, поди. И как их подключать знал только померший в прошлом году китаец 98 лет.
	Ответить | Правка | ^ к родителю #387 | Наверх | Cообщить модератору

	406. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 16:01
	> А в тех 286 уже и текстолит того-сь, расслоился, поди. И как > их подключать знал только померший в прошлом году китаец 98 лет. Если текстолит правильный, то он ещё наших внуков переживёт. Как, собственно, и те станки.
	Ответить | Правка | ^ к родителю #392 | Наверх | Cообщить модератору

	484. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (482), 15-Дек-18, 22:43
	> А в тех 286 уже и текстолит того-сь, расслоился, поди. Ну не знаю, у мну валяется 286 по приколу. Ничего там не расслоилось, только аккумулятор RTC сел в ноль. Но смысла включать это довольно мало - чего с ним делать потом? Шариться в нортоне? Ну самый край в wing commander можно полетать по старой памяти. Но это можно и в qemu/bochs, только тормознуть специально придется. > И как их подключать знал только померший в прошлом году китаец 98 лет. Да чего там подключать? Даже я 286 собрать могу заново. Невелика хитрость. Единственный прикол - при подключении питалова черные провода половинок должны быть друг-к-другу, в центре. Хотя у промышленных древностей может быть и что-то нестандартное, конечно.
	Ответить | Правка | ^ к родителю #392 | Наверх | Cообщить модератору

	352. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от OldFart (?), 14-Дек-18, 00:45
	> Может им послать фотки с завода, на котором уйма индустриальных станков с > 256Мб памяти и 32битовыми процами ? Компы специализорованные, хрен заменишь, станочки > от $100к и выше, накладенько менять то? Зря ИМХО это они, > автоматики навалом на старом железе (хотя даже того старого с головой > хватает, максимум на 10% загруженно, на хер там сдался x64) Чет я пургу прогнал прочитав новость по диагонали :( подумал что x86 выпилить хотят... Сорри, за бурю в стакане... :)
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	390. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (386), 14-Дек-18, 14:50
	Да ничо, бывает. Мне тоже совестно, столько г-на вылил уже, даже КГБ забрызгало
	Ответить | Правка | ^ к родителю #352 | Наверх | Cообщить модератору

	407. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 16:05
	> Да ничо, бывает. Мне тоже совестно, столько г-на вылил уже, даже КГБ > забрызгало Не переживай, за вашими фонтанами искромётного подплинтусного юмора я наблюдаю из-за стекла, так сказать, из чистой, во всех отношениях, комнаты. :-)
	Ответить | Правка | ^ к родителю #390 | Наверх | Cообщить модератору

81. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–4 +/–
Сообщение от Аноним (85), 13-Дек-18, 02:08
ix86 выкиньте пжлст, а x32 оставьте. Спасибо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	194. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 11:41
	кстати, да - вот такой процессор теперь уже действительно нигде не купить, кроме барахолок.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

94. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
Сообщение от Нуб (?), 13-Дек-18, 03:00
означает ли это, что все 32 битные приложухи (игори там старые например) превратятся в тыкву?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	96. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+6 +/–
	Сообщение от Аноним (96), 13-Дек-18, 03:16
	нет
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	327. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от Himik (ok), 13-Дек-18, 20:24
	Да, именно так.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	346. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Himik (ok), 13-Дек-18, 23:29
	Но есть ещё эмуляторы, типа QEMU для запуска 32-битных игр на 64-битной системе.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

110. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+4 +/–
Сообщение от тентакль (?), 13-Дек-18, 06:16
а как насчёт нового кодекса? ведь удаление того кода это в чистом виде унижение тех кто его писал. а что если ктото не выдержит  этого - может у человека была единственная радость и смысл жизни в том чтто его кусочек кода используется в линуксе а тут бац и всё, линукс сообщество этим удалнием кагбэ говорит ему Ты бесполезен! и всё человек сделает этот шаг и его кроовь будет на руках всех кто допустил такое!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	113. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от freehck (ok), 13-Дек-18, 06:20
	> ведь удаление того кода это в чистом виде унижение тех кто его писал. Если запретить удалять код, то куда можно засунуть право на модификацию кода, гарантированное GPL? =)
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	142. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним 80_уровня (ok), 13-Дек-18, 08:31
	"Но если пиво мешает работе^W^W^W лицензия мешает CoC'у"...
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

112. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от EuPhobos (ok), 13-Дек-18, 06:18
> По мнению инициатора удаления технология x32 не оправдала себя и не нашла > Линус Торвальдс сообщил, что он не против удаления x32, если не будут представлены аргументированные возражения или не будут заявлены системы Как это переваривать? Предложения с двойным отрицанием? Нет, это не так. "Этот не текст не просто не взрывает не мне мозг"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	115. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от freehck (ok), 13-Дек-18, 06:22
	> Как это переваривать? Предложения с двойным отрицанием? Нет, это не так. Утро добрым не бывает? =) "не против, если" = "поддержит, если" > Линус Торвальдс сообщил, что он поддержит удаление x32, если не будут предоставлены аргументированные возражения ^^ Ну вот так примерно это читается.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	132. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от трурль (?), 13-Дек-18, 07:55
	> Как это переваривать? Предложения с двойным отрицанием? Это русский язык, детка. «Нет, ну так-то, да!»
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	332. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Himik (ok), 13-Дек-18, 20:27
	Это финский язык. И на нём думает Линус Торвальдс :-)
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

114. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–5 +/–
Сообщение от Вася (??), 13-Дек-18, 06:21
А как же Я?! У меня все еще архитектура x32, что мне теперь покупать x64 придется из-за этого? Ненавижу
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	117. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (108), 13-Дек-18, 06:23
	У меня вообще x16 на генту. Нормально, жить можно, ну и идиоты же
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	128. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+7 +/–
	Сообщение от Анонимный прохожий (?), 13-Дек-18, 07:48
	> А как же Я?! У меня все еще архитектура x32, что мне теперь покупать x64 придется из-за этого? Вникать в текст новости сейчас, смотрю, немодно.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	196. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от А (??), 13-Дек-18, 11:45
	Вася, остынь - если у тебя процессор 32-битный, то архитектуру "x86" пока не выкидывают.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	276. "Разработчики ядра Linux обсуждают вопрос удаления..."	+/–
	Сообщение от arisu (ok), 13-Дек-18, 16:38
	> У меня все еще архитектура x32 интересно, где ты достал такое? но гордись: ты единственный на планете владелец подобного эксклюзива.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	300. "Разработчики ядра Linux обсуждают вопрос удаления..."	+/–
	Сообщение от трололо (?), 13-Дек-18, 17:55
	да че пристал. он не понял разницы между архитектурой х86 и х32(программной реализацией). объяснил бы что ли))
	Ответить | Правка | ^ к родителю #276 | Наверх | Cообщить модератору

	576. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Адекват (ok), 18-Дек-18, 11:07
	У нас на работе тоже ноут оказался 32bit (msi s420) думал вставлю в него ssd и он с 1 Гб памяти будет со скрипом, но работать на Linux Mint 18.3 x64 (для скайпа нужен был). Как же я побрился....ну да ничего, все равно скайп бы в вечный своп вгонял этот ноунт, на минте он в простое овер 500М озу кушает. Электрон-эдишен, все это...
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

116. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от cutlass (?), 13-Дек-18, 06:22
А как же типа переносимая ось и всё такое? Проще писать под одну платформу и не париться с переносимостью и качеством кода. В общем мобильность не осилили.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	160. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 09:33
	> А как же типа переносимая ось и всё такое? Проще писать под > одну платформу и не париться с переносимостью и качеством кода. >  В общем мобильность не осилили. Ну вот потому в качестве доступной промышленной ОС и используют DOS, а не линукс. Никаких тебе stable API nonsense и проблем с будущим. Любой образованный человек со знанием Си и компилятором в руках способен писать для этой «платформы» нужные программы. Да и не только Си, к слову. И оно гарантированно уже не устареет. ;-)
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	593. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ванёк (?), 19-Дек-18, 15:16
	А 64-битная DOS есть?
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

121. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (10), 13-Дек-18, 06:45
https://flameeyes.blog/2012/06/19/is-x32-for-me-short-answer-no/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

125. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+14 +/–
Сообщение от Аноним (125), 13-Дек-18, 07:35
Забавно, что половина комментаторов на "глубоко техническом ресурсе" даже не поняла, что речь не о x86, а о x32, и что это разные вещи.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	139. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от dango (ok), 13-Дек-18, 08:18
	> Забавно, что половина комментаторов на "глубоко техническом ресурсе" даже не поняла, что речь не о x86, а о x32, и что это разные вещи. Как обычно. Вас это еще развлекает? Подождите, еще немного и вы будете здесь читать опусы "первоокрывателей" черного экрана с белыми буквами без эмодзи (ужас-ужас)...
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	146. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Онаним (?), 13-Дек-18, 08:46
	Забавно, что даже в LKML нашёлся молодчик, причём из угадай
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	147. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Онаним (?), 13-Дек-18, 08:46
	из угадай какой страны, который тоже не осилил
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	200. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Нанобот (ok), 13-Дек-18, 12:03
	кто-то впервые увидел икспертов опеннета...
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

148. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (150), 13-Дек-18, 08:47
А могли бы ещё несколько лет по говнохранительствовать. Ядро то ведь всё равно маленькое, прямо микро.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

149. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
Сообщение от Онаним (?), 13-Дек-18, 08:50
А вообще с x86-64-x32 - давно пора. Оно не взлетело и не взлетит никогда, потому что ненужно, и память стоит копейки. Да и x86-32 уже пора на покой в целом, но пока жива куча железа без x86-64 эпохи мамонтов, видимо, будет жить.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	222. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от inferrna (ok), 13-Дек-18, 13:06
	>память стоит копейки дело не в памяти, а в кэше. Делая указатели в 2 раза короче, оно экономит кэш, которого много не бывает, за счёт чего и ускорение.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	230. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (230), 13-Дек-18, 13:48
	Спорно. Кэш, как и память, адресуется блоками, размер которых "зашит" в процессор. У многих современных процессоров размер блока совпадает с размером регистра, т.е. 8 байт. Экономия возникает лишь в ОП и заметна лишь в структурах данных, почти целиком состоящих из указателей. Именно эти аргументы приводили противники этой "технологии" когда её тащили в ядро. С тех пор ничего не изменилось, только аргументы дошли наконец-таки и до всех остальных. Даже Шигорин, который раньше топил за прогресс приутих и потёр свой бред прошлых лет. Не хочет щенок чтобы его в собственные какашки носом тыкали.
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	281. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КО (?), 13-Дек-18, 16:58
	>Спорно. Кэш, как и память, адресуется блоками, размер которых "зашит" в процессор Так в том то и дело. Кешлайн 64 байта. Это либо N команд, либо N/2 (ну хорошо x86 не Risc, побольше). Правда к x32 это отношение не имеет - там команды длиннее. :)
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	520. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (520), 17-Дек-18, 02:46
	Во-первых, кеш адресуется блоками по 64 байта, а не по 8 байт. Во-вторых, экономия будет также почти в ЛЮБЫХ структурах, в которых есть хоть один указатель, т.к. многие компиляторы обычно выравнивают каждый элемент структуры по адресам, кратным размеру самого большого элемента простейшего типа, если только Вы не кодируете на ассемблере. Иными словами, если в структуре есть указатель размером 8 байт (void*), то остальные члены структуры также будут занимать по 8 байт, даже если они размером 4 (int32_t) или 2 байта (int16_t).
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	250. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (251), 13-Дек-18, 15:19
	Про выравнивание данных не стоит забывать, оно 64 бита какбэ.
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

153. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (153), 13-Дек-18, 09:06
У меня только один гб памяти и я не могу просто её докупить, потому что сижу на шее у мамки. Вот такой вопрос: а взлетит ли просто 16 битная адресация для браузера, и какова будет экономия? Она может адресовать два в 16 степени? Короче ничего не выйдет...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	162. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (162), 13-Дек-18, 09:47
	А про кэш процессора ты специально забываешь? Или мамка купила тебе i9?
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	231. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (386), 13-Дек-18, 13:50
	А ты уверен, что в кеш-линиях нет выравнивания по 64 в x32 режиме? У меня есть на этот счет подозрения
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

157. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (157), 13-Дек-18, 09:26
С самого начала было понятно, что эта архитектура обречена быть непопулярной. Операционные системы с архитектурой x86_64 появились одновременно с выходом соответствующих процессоров на массовый рынок, а сабж в одно только ядро завезли аж 7 лет спустя. К тому времени под "классический" x86_64 уже понаписали изрядное количество программ, с которыми неплохо было бы иметь совместимость. В первую очередь, это инструменты разработки и отладки, без которых адаптация другого софта невозможна. Короче, было очевидно, что без принудительного продавливания со стороны производителей коммерческих систем не взлетит. И не взлетело. Что бы там не говорили фанатики, а совместимость со старым софтом важна, а сабж - еще одни костыль ее усложняющий.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	161. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (162), 13-Дек-18, 09:45
	С самого начала было понятно, что для популяризации архитектуры надо придать ей стабильный статус. Пофиксить баги, стабилизировать. Но тогда люди перестанут покупать оперативку и обновлять железо. Это очень невыгодно для торговцев воздухом.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	171. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (171), 13-Дек-18, 10:31
	Посчитайте для начала падение ценника на гигабайт DRAM лет за 10 хотя бы, потом поговорим.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	180. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 11:03
	> Посчитайте для начала падение ценника на гигабайт DRAM лет за 10 хотя > бы, потом поговорим. Измерьте для начала площадь продаваемого за доллар обработанного кремния в виде чипов памяти. Возможно, для вас будет открытием, что имеет значение в конечном счёте только это — количество обработанного «сверхчистого песка». Можете даже попробовать прикинуть себе норму прибыли производителей памяти двадцать лет назад и сегодня. Подсказка: они не обеднели.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	197. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от нах (?), 13-Дек-18, 11:46
	э... за которые десять? Если за последние, так она подорожала раза этак в полтора если учесть инфляцию доллара, а то и поболее. Это я про современную vs ddr2 в 2008, когда та была современной, а не про цену апгрейда того самого ящика 2008го года с ddr2 reg ecc, когда дешевле купить новый с 128G вместе с камнями и корпусами, чем в том вторые 32 добавить.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	213. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (251), 13-Дек-18, 12:22
	$/MByte 2008: 0.023 2009: 0.010 2010: 0.019 2011: 0.010 2012: 0.0049 2013: 0.0043 2014: 0.0095 2015: 0.0078 2016: 0.0031 2017: 0.0049 2018: 0.0067 C 0.023$/MB до 0.0067 - нормально, ящетаю. То же, что кому-то удалось за эти же 10 лет свою валюту обвалить вдвое - ни разу не проблема производителей памяти.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	214. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (251), 13-Дек-18, 12:22
	Отсюда https://jcmit.net/memoryprice.htm
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	218. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (162), 13-Дек-18, 12:51
	Так себе источник.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	341. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Ю.Т. (?), 13-Дек-18, 22:19
	Только в 2008 достаточно было купить 2, а сейчас "надо" 8.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	348. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 23:41
	> Только в 2008 достаточно было купить 2, а сейчас "надо" 8. Если бы… Сейчас «у каждого офисного планктона минимум 16». Так, во всяком случае, вещают анонимные эксперты.
	Ответить | Правка | ^ к родителю #341 | Наверх | Cообщить модератору

	364. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 14-Дек-18, 07:14
	>> Только в 2008 достаточно было купить 2, а сейчас "надо" 8. > Если бы… Сейчас «у каждого офисного планктона минимум 16». Так, во всяком > случае, вещают анонимные эксперты. Вернее, сейчас у каждого мамкиного игруна минимум 16, а настолки "нужны только для игр".
	Ответить | Правка | ^ к родителю #348 | Наверх | Cообщить модератору

	394. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 14-Дек-18, 15:02
	вот дерьмо. А у меня восемь, и начальство говорит что это в нашей конторе круто :-( А на лезвии через ipkvm gta5 как-то не очень :-(
	Ответить | Правка | ^ к родителю #364 | Наверх | Cообщить модератору

	408. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 16:08
	> вот дерьмо. А у меня восемь, и начальство говорит что это в > нашей конторе круто :-( > А на лезвии через ipkvm gta5 как-то не очень :-( Начальство на то и начальство, что не ошибаться в генеральной линии и потребностях подчинённых. Я бы не удивился, если б узнал, что на моём рабочем месте периода конца девяностых до сих пор при деле первопень о 32 метрах памяти. :)
	Ответить | Правка | ^ к родителю #394 | Наверх | Cообщить модератору

	503. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 18:01
	> А на лезвии через ipkvm gta5 как-то не очень :-( Ну так начальство тебе выделило машину не для того чтобы ты там в GTA игрался. Как бы есть разница между своей машиной и конторской.
	Ответить | Правка | ^ к родителю #394 | Наверх | Cообщить модератору

	219. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (162), 13-Дек-18, 12:53
	Давай лучше про падение ценников на топовые процы и материнки поговорим. А то сдаётся мне, у кого-то мамка всё оплачивает.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	245. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (374), 13-Дек-18, 15:06
	А что с ними? Как продавал штеуд свои иксы за 999/1999, так и продает. Ну и как выше писали, проблемы курса недовалют совсем не проблемы штеуда. Затокрымваш, вставание, скрепы и все такое, гордись, боец!
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	323. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от пох (?), 13-Дек-18, 19:37
	все ок - 'падение' компенсируется удорожанием раритетных компонентов не на десятки процентов, а на порядки. То есть покупать новый проц и новую мать дороже старой все равно дешевле, чем пытаться добавить памяти в старую.
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

159. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (159), 13-Дек-18, 09:29
Поставил на слабый планшет с 32 бит загрузчиком 64-битный минт. Производители была поставлена x86 винда. Так вот с запущенным Chromium это все жрет 1.3 ГБ памяти из 2 ГБ. Используется swap, но замедления работы не видно. Я это все к тому, что современные 64бит программы умеют подстраиваться под недостаток памяти и рядовому юзеру 32 бит не нужны.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	179. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (179), 13-Дек-18, 11:01
	> современные 64бит программы умеют подстраиваться под недостаток памяти Если точнее, то подстраивается система. А размер указатела все равно в 2 раза больше, что приводит к увеличению потребления памяти до 2-х раз и соответственно снижению скорости операций с памятью до двух раз. Что в свою очередь происходит не только из-за увеличения объема читаемых/записываемых/передаваемых данных, но и увеличения частоты кэшпромахов. Всё это в совокупности также снижает энергоэффективность системы. Какие выгоды мы получаем: 1. Система может работать с объемом памяти больше 64Гб; 2. Каждый процесс может адресовать более 4Гб. Если говорить в контексте упомянутого Chromium'а, то у него каждая вкладка - тдельный процесс. Т.о. он может адресовать все 64Гб в 32 битной системе. И вероятно у вас нет такого объема памяти, т.к. основываясь даже на статистике steam, среднестатистическому PC геймера далеко до такого объема. А PC офисного сотрудника или встраиваемой технике - тем более.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	211. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (251), 13-Дек-18, 12:18
	Ну больше и больше. Указатели серьёзно погоду делают только в случае чрезмерно сложных структур с простейшими элементами. Если элемент чуть сложнее uint64, указатели уже погоды не делают.
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	335. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (335), 13-Дек-18, 20:59
	std::string - 3 указателя, один на начало данных, второй на конец, третий на емкость - 24 байта. std::list - 2 указателя на каждый элемент - 16 байт.... В хромиуме структуры содержат множество строковых полей, которые зачастую пусты. В итоге получается хранятся только указатели, без данных. Отсюда такая зависимость потребления памяти от битности.
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	336. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Michael Shigorin (ok), 13-Дек-18, 21:42
	> std::string - 3 указателя [...] - 24 байта Это в модели ptr8 :)  Оговорились...
	Ответить | Правка | ^ к родителю #335 | Наверх | Cообщить модератору

	372. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Онаним (?), 14-Дек-18, 09:24
	Насколько помню, std::string короткие строки вписывает в саму структуру.
	Ответить | Правка | ^ к родителю #335 | Наверх | Cообщить модератору

	379. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (514), 14-Дек-18, 10:13
	> Насколько помню, std::string короткие строки вписывает в саму структуру. Это не отменяет наличие трёх указателей. В случае пустых строк, наличие локального буфера лишь увеличивает затраты памяти. Взамен сокращает расходы процессорного времени на выделение и освобождение памяти при операциях со строками.
	Ответить | Правка | ^ к родителю #372 | Наверх | Cообщить модератору

	485. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 22:50
	> Это не отменяет наличие трёх указателей. Не скажу за си++ а в си таки оптимизатор очень даже может резко отменить к чертям все что пожелает - в том числе и любые указатели. Обычно анализ программы срабатывает нормально, так что убираются только те указатели (и проч) которые никто явно не использовал. Но есть способы этот анализ надуть. Самый очевидный способ - микроконтроллеры, обработчик IRQ. Компилер не знает что железо позовет обработчик IRQ. И не знает как это. В этот момент об оптимизнутом указателе можно конкретно пожалеть. В этом случае сишники явно пишут volatile, показывая компилеру и оптимизатору что это реально должно работать так как заявлено и что есть неожиданные способы использовать это, которые компилятор не знает. Тогда компилер забьет на оптимизации в этом месте - и таки будут все указатели или что там должно быть. Но для обычных программ в user mode операционки - использование volatile как бы очень странное дело.
	Ответить | Правка | ^ к родителю #379 | Наверх | Cообщить модератору

176. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
Сообщение от Аноним (179), 13-Дек-18, 10:47
> Линус Торвальдс сообщил, что он согласится с удалением x32, > если не будут представлены аргументированные возражения ... Встраиваемая техника, роутеры и т.д., ускорение до 30% очень кстати.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	182. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от Аноним (251), 13-Дек-18, 11:07
	Хоть один роутер на x86-x64-x32 видели?
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	183. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (179), 13-Дек-18, 11:12
	На сколько это важно?
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	208. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (251), 13-Дек-18, 12:15
	/0
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	189. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (189), 13-Дек-18, 11:31
	Легко делается на дешёвой материнке с сокетом FM1.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	198. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от имя (?), 13-Дек-18, 11:47
	как ни старался - не смог в своей стране найти дешёвой материнки с FM1. есть с FM2 и стоят они в пределах 41-68 EUR. за эти же деньги можно купить материнку того же класса с AM4. естественно во всех случаях я подразумеваю лишь новые материнки, а не те что с антресолей у Васяна
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	209. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (251), 13-Дек-18, 12:16
	Так кто-то делает? Ну, не кустарщину, а коммерческий продукт? У меня и на x86-64 роутер прекрасно крутится, без всяких x86-64-x32.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	259. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Michael Shigorin (ok), 13-Дек-18, 15:45
	> Так кто-то делает? Ну, не кустарщину, а коммерческий продукт? > У меня и на x86-64 роутер прекрасно крутится, без всяких x86-64-x32. Делают -- но, разумеется, именно x32 в знакомых случаях не впёрся.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	521. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (520), 17-Дек-18, 02:47
	Как ни странно, да!
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	319. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (319), 13-Дек-18, 19:08
	> Встраиваемая техника, роутеры и т.д., ускорение до 30% очень кстати. Чтобы x86 в что-то встраиваемое сунуть надо крепко долбануться. А увидеть 30% ускорения - можно только если долбанулся реально хорошо и глюки не отпускают. Сказали же - те кто придумал это нечто выпятили синтетические бенчи. А в реальных нагрузках профит куда прозаичнее, если вообще.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	331. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (331), 13-Дек-18, 20:27
	у меня роутер есть на каком-то проце от амд. в отличие от китайских собратьев, выдает столько, сколько позволяет порт, и при этом не виснет на торрентах. он вообще за 10 лет ни разу не завис. но правда дороговат (фирма какая-то швейцарская)
	Ответить | Правка | ^ к родителю #319 | Наверх | Cообщить модератору

	486. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 22:57
	> у меня роутер есть на каком-то проце от амд. в отличие от > китайских собратьев, выдает столько, сколько позволяет порт, и при этом не > виснет на торрентах. он вообще за 10 лет ни разу не > завис. но правда дороговат (фирма какая-то швейцарская) Ну и чего? А я китайский арм с дебианом с годом аптайма видел. Ну, работает. А чему там ломаться? Даже конденсаторы все керамические.
	Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

	522. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (520), 17-Дек-18, 02:49
	Любые конденсаторы, включая керамические, имеют ограниченный срок службы, и далеко не 10 лет. И чем больше греются, тем меньше срок службы. Постепенно теряют ёмкость.
	Ответить | Правка | ^ к родителю #486 | Наверх | Cообщить модератору

188. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
Сообщение от Аноним (189), 13-Дек-18, 11:25
Для роутеров на железной архитектуре x86_64 самое то. Сам использовал, понравилось.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

216. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
Сообщение от Ващенаглухо (ok), 13-Дек-18, 12:47
Вот это надо было выделить большими, жирными, красными буквами: (не путать с x86 IA-32 :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	232. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от Аноним (386), 13-Дек-18, 13:52
	нет, не надо. Пусть долбятся
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

255. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (255), 13-Дек-18, 15:41
ммм как насчет wine он же до сих пор запускает огромный пласт x32 приложений. Или там не нужна поддержка x32 в ядре ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	290. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от А (??), 13-Дек-18, 17:26
	Еще "плюс один" не видящий разницы между "x86" и "AMD64 с 32-х битными указателями"... :)
	Ответить | Правка | ^ к родителю #255 | Наверх | Cообщить модератору

	321. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Аноним (255), 13-Дек-18, 19:32
	Ну простите не все здесь сидящие шарят в таких нюансах.
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

	594. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ванёк (?), 19-Дек-18, 15:29
	Зато все думающие шарят. А сидящие пусть сидят дальше.
	Ответить | Правка | ^ к родителю #321 | Наверх | Cообщить модератору

	322. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (255), 13-Дек-18, 19:33
	Если это не повлияет на юзерспейс -- тогда в топк у смело.
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

298. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от J.L. (?), 13-Дек-18, 17:51
> В своё время при тестировании x32 один из разработчиков Gentoo пришёл к выводу, что выигрыш в производительности при переходе на x32 ABI не столь велик, как показывают синтетические тесты от создателей x32 ABI - заметный прогресс отмечается только при сравнении с устаревшей архитектурой x86, но при сравнении с актуальной архитектурой x86-64 выигрыш несущественный (тесты от создателей x32 показывали ускорение до 30% в сравнении с классическим x86_64 ABI в ситуациях, связанных с интенсивной работой с указателями). а по количеству занятой памяти какое соответствие между x86, x32 и x64 ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	356. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от vedronim (?), 14-Дек-18, 01:54
	>> В своё время при тестировании x32 один из разработчиков Gentoo пришёл к выводу, что выигрыш в производительности при переходе на x32 ABI не столь велик, как показывают синтетические тесты от создателей x32 ABI - заметный прогресс отмечается только при сравнении с устаревшей архитектурой x86, но при сравнении с актуальной архитектурой x86-64 выигрыш несущественный (тесты от создателей x32 показывали ускорение до 30% в сравнении с классическим x86_64 ABI в ситуациях, связанных с интенсивной работой с указателями). > а по количеству занятой памяти какое соответствие между x86, x32 и x64 > ? Кстати да, почему меряют только скорость?
	Ответить | Правка | ^ к родителю #298 | Наверх | Cообщить модератору

337. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
Сообщение от Аноним (337), 13-Дек-18, 21:47
Если хоть один человек использует данный инструментарий, то его нельзя удалять из ядра. При нынешних масштабах безоразия, удаление одной подсистемы ничего не решит.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	339. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Michael Shigorin (ok), 13-Дек-18, 22:04
	> Если хоть один человек использует данный инструментарий Это не инструментарий.  И "хоть одного человека" никто из ядра не удаляет.  А слона надо есть постепенно.  И, без, лишних, запятых.
	Ответить | Правка | ^ к родителю #337 | Наверх | Cообщить модератору

	389. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (386), 14-Дек-18, 14:49
	Ты не обитал на rsdn какое-то давнее время назад? Был один персонаж там, про пунктуацию похоже написал
	Ответить | Правка | ^ к родителю #339 | Наверх | Cообщить модератору

	413. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 17:46
	Здесь посмотри, там целая страничка ему лично посвящена: myrotvorets.center/criminal/shigorin-mikhail-aleksandrovich Как видишь, анон, здешний вахтёр прославился не только стиранием неугодных комментов.
	Ответить | Правка | ^ к родителю #389 | Наверх | Cообщить модератору

	414. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Ю.Т. (?), 14-Дек-18, 17:58
	> Здесь посмотри, там целая страничка ему лично посвящена: > myrotvorets.center/criminal/shigorin-mikhail-aleksandrovich > Как видишь, анон, здешний вахтёр прославился не только стиранием неугодных комментов. Ещё надобно сжечь на площадях его книги или дистрибутивы.
	Ответить | Правка | ^ к родителю #413 | Наверх | Cообщить модератору

	415. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Michael Shigorin (ok), 14-Дек-18, 18:41
	>> Здесь посмотри, там целая страничка ему лично посвящена: >> myrotvorets.center/criminal/shigorin-mikhail-aleksandrovich >> Как видишь, анон, здешний вахтёр прославился не только стиранием неугодных комментов. ...как и многие из других персонажей этого нарушающего УК бывшей УКраины сайтА. > Ещё надобно сжечь на площадях его книги или дистрибутивы. Понимаете, тут такая штука: там же даже нацисты ненастоящие.  Настоящие _строили_ свою страну и разрушали другие.  А эти разрушают свою, не будучи в силах что-либо сделать другим вообще. Этакий жалкий карго-культ. И когда к нему апеллируют -- это жалко в квадрате, но правил форума всё так же не отменяет, включая и шестой пункт, и десятый.
	Ответить | Правка | ^ к родителю #414 | Наверх | Cообщить модератору

	416. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 14-Дек-18, 19:04
	>>> Здесь посмотри, там целая страничка ему лично посвящена: > но правил форума всё так же не отменяет И от цензуры бывает польза, однако.
	Ответить | Правка | ^ к родителю #415 | Наверх | Cообщить модератору

	504. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 18:05
	> И от цензуры бывает польза, однако. И от расстрелов. Главное чтобы пулемет был в правильную сторону. Вот в сторону Ю.Т. вполне можно, особенно если он сильно расхваливал расстрелы. Так пусть и потестирует как раз.
	Ответить | Правка | ^ к родителю #416 | Наверх | Cообщить модератору

	507. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 16-Дек-18, 18:45
	>> И от цензуры бывает польза, однако. > И от расстрелов. Главное чтобы пулемет был в правильную сторону. Вот в > сторону Ю.Т. вполне можно, особенно если он сильно расхваливал расстрелы. Так > пусть и потестирует как раз. Укуси меня, Харди.
	Ответить | Правка | ^ к родителю #504 | Наверх | Cообщить модератору

	442. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Благодарный читатель. (?), 15-Дек-18, 11:16
	НЕТ. Первые страны, которые пострадали от нацистов — это нацисткая Германия, а также Австрия и Судетская область. Обычные немцы точно так же и в концлагерях сидели, и работали практически за еду, даже вопросы кто в чьей постели  спит, в какой кабак ходит и в каком магазине что покупает регламентировались со стороны власти. При этом попасть в концлагерь можно было, например, за ухаживание за то, что немец, чистокровный ариец, сделал предложение руки и сердца немке, но она на тот момент ещё не получила подтверждение своего арийского происхождения. А выйти из концлагеря было гораздо труднее, чем туда попасть. Я уверен, что такого "строительства" мало кто захочет. С другой стороны, Вы не должны навязывать свою точку зрения другим. Зато, если не ошибаюсь, в обязанности модератора входит вовремя банить неадекватных участников, в том числе за попытку политизации ресурса и любого деления на "мы" и "они".
	Ответить | Правка | ^ к родителю #415 | Наверх | Cообщить модератору

	505. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 18:08
	Вот увы, неразборчив Макс в раздаче полномочий. И отдал модерацию рожам которые именно модерировать не умеют нихрена, скорее сами разжигают и устраивают подлые подтирки всего что с их точкой зрения не согласуется. //Однажды меня это достало и я свинтил из опеннетовских авторов, решив что по большому счету не принадлежу к сообществу с такими целями и методами.
	Ответить | Правка | ^ к родителю #442 | Наверх | Cообщить модератору

	580. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Адекват (ok), 18-Дек-18, 12:05
	Может Максу надоел этот ресурс ? может он его согласится продать, если ему предложат хорошую цену :) ?
	Ответить | Правка | ^ к родителю #505 | Наверх | Cообщить модератору

	582. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 18-Дек-18, 12:57
	> Может Максу надоел этот ресурс ? может он его согласится продать, если > ему предложат хорошую цену :) ? Я готов предложить 30 рублей.
	Ответить | Правка | ^ к родителю #580 | Наверх | Cообщить модератору

	589. "(offtopic) модерирование на opennet"	+1 +/–
	Сообщение от Michael Shigorin (ok), 18-Дек-18, 20:38
	> Вот увы, неразборчив Макс в раздаче полномочий. Ну Вы же, светлоликий наш эльф, не вызвались.  И если Максим Вам (как мне) предлагал -- видимо, вежливо отказались по той или иной наверняка весомой причине. > И отдал модерацию рожам которые именно модерировать не умеют нихрена, > скорее сами разжигают и устраивают подлые подтирки всего что с их точкой > зрения не согласуется. В зеркало посмотрите.  У Вас, между прочим, "а меня за шо" бывает весьма часто. > //Однажды меня это достало и я свинтил из опеннетовских авторов, решив что > по большому счету не принадлежу к сообществу с такими целями и методами. Да уж неоднократно распинались и в духе "ноги моей здесь не будет".  Я огорчался, что это в том числе и непосредственно и из-за меня -- а затем перестал, когда понял, что Вам опеннет (и Россия, кстати) нужнее, чем в обратном направлении.  И что пройдёт время -- и жизнь опять всё расставит по местам.
	Ответить | Правка | ^ к родителю #505 | Наверх | Cообщить модератору

	588. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Michael Shigorin (ok), 18-Дек-18, 20:29
	> Я уверен, что такого "строительства" мало кто захочет. Я про ту же промышленность и инфраструктуру -- Вы сейчас по сути описали то, что укры как раз успешно переняли. > С другой стороны, Вы не должны навязывать свою точку зрения другим. Зато, если не > ошибаюсь, в обязанности модератора входит вовремя банить неадекватных участников Ошибаетесь -- комоды опеннета технически никого не банят, см. http://wiki.opennet.ru/ForumHelp (п. 2.11) > в том числе за попытку политизации ресурса А вот здесь да, наконец-то в эти самые правила форума был добавлен п.10. > и любого деления на "мы" и "они". Ну а здесь нет -- есть разница между разделением и констатацией факта, что кто-то решил ходить на руках, лишь бы за человека не приняли. В любом разе благодарю за содержательное сообщение в мой адрес.
	Ответить | Правка | ^ к родителю #442 | Наверх | Cообщить модератору

	586. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от Zulu (?), 18-Дек-18, 19:45
	Зачем? Пусть влачит существование, он сам себя наказал переездом в Нигерию, только с климатом похуже.
	Ответить | Правка | ^ к родителю #414 | Наверх | Cообщить модератору

	590. "(offtopic) встретились как-то на опеннете двое киевлян, значит"	+/–
	Сообщение от Michael Shigorin (ok), 18-Дек-18, 20:42
	> Зачем? Пусть влачит существование, он сам себя наказал переездом в Нигерию, > только с климатом похуже. Ой, а ты уже вернулся в замечательный киевский климат из клятых Нидерландив или откуда там? :) (меня, кстати, что московский, что питерский -- тоже очень устраивают, особенно летом и зимой)
	Ответить | Правка | ^ к родителю #586 | Наверх | Cообщить модератору

	449. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (449), 15-Дек-18, 14:36
	да это баян. Просто было интересно, обитал ли Михаил на кывте. Я давно ушел, а тут фраза чот напомнила какой то давний спор
	Ответить | Правка | ^ к родителю #413 | Наверх | Cообщить модератору

349. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (-), 13-Дек-18, 23:55
Правильно, догоним и перегоним винду по прожорливости! Иж ты, линукс на десктопе захотели.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	357. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от vedronim (?), 14-Дек-18, 01:55
	> Правильно, догоним и перегоним винду по прожорливости! Иж ты, линукс на десктопе > захотели. Ты завсегда можешь пересобрать ядро удалив ненцжное, если приспичит. Это ж опенсорс.
	Ответить | Правка | ^ к родителю #349 | Наверх | Cообщить модератору

361. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Аноним (362), 14-Дек-18, 05:08
Жаль, но удаление будет верным решением.  Если с 2012 года дистростроители так толком и не освоили x32, то в чем смысл ее дальше в ядре поддерживать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	367. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 08:03
	Дистростроители ударными темпами осваивали системду, а также готовили и согласовывали тексты СоС-ов. Им некогда было заниматься ерундой для трёх с половиной анонимов.
	Ответить | Правка | ^ к родителю #361 | Наверх | Cообщить модератору

	382. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от anonymous (??), 14-Дек-18, 11:36
	> Если с 2012 года дистростроители так толком и не освоили x32, то в чем смысл ее дальше в ядре поддерживать Много есть такого, чего до сих пор не освоили дистростроители. Например system capabilities.
	Ответить | Правка | ^ к родителю #361 | Наверх | Cообщить модератору

	422. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от имя (?), 14-Дек-18, 21:19
	согласен. к примеру тот-же Debian осваивает apparmor - думают внедрять его в стандартной поставке следующей stable (10) или нет
	Ответить | Правка | ^ к родителю #361 | Наверх | Cообщить модератору

583. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Анонимчик (?), 18-Дек-18, 13:26
Уф,я уж испужался не на шутку.dhcpcd хотят похерить еще и вайн не запустиь с 32 было бы вообще фиаско.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

584. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
Сообщение от Анонимчик (?), 18-Дек-18, 13:28
Из-за этого чертового прогресса приходиться извращаться чтобы пользоваться привычным.Да,сейчас обвинят в ниосиляторстве и вообще некрофилии,но это мое мнение.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема