нет никакого amd64. Это вшивые иудомаркетологи добавилинемножко регистров и операций адресации 64 битными указателями

А больше ничего и не надо.

VP, Technology Division, Goldman Sachs

Сперва добейся.

Только он все равно мудак.

VP, Technology Division, Goldman Sachs

Вот и пора перестать уже играть в программиста.

только вот он сделал для линукса больше всего лора вместе взятого. Так что не надо раскидываться оскорблениями.

нет никакого amd64. Это вшивые иудомаркетологи добавилинемножко регистров и операций адресации 64 битными указателями и самое главное, новое торговое название с цифрой 64.

В итаниуме хоть что-то новое предложили...

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

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

4.2. Спроектирован он неплохо вроде.

Я привел простейший пример. Или он тоже «пук» проектирования?

Какой хлам? И он занимается загрузкой сервисов, и хорошо занимается.

Это sysvinit занимается стартом сервисов. А systemd еще всякой фигней.

Вы таки объясните зачем там нужен LimitDATA или какой-нибудь IOSchedulingClass - если крутилок этих было/есть/станет до черта, и все их и без того можно покрутить в каком-нибудь ExecStartPre?

у меня есть итаники в продакшене (в этом треде уже отметились еще пару человек). Такие новости совсем не радуют, с поддержкой софта и так масса проблем.

Их «оптимизированный» шелл быстрее на жалкие проценты (которые съедаются накладными расходами).

Вы таки объясните зачем там нужен LimitDATA или какой-нибудь IOSchedulingClass

Чтобы задавать соответствующие аттрибуты процесса, КО.

все их и без того можно покрутить в каком-нибудь ExecStartPre

И изобрести еще одно подобие шелла с запуском кучи внешних процессов на каждый чих.

Ну, слава Богу, что есть. А то я уже хотел написать, что пора IA64 выпиливать.

с поддержкой софта и так масса проблем.

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

Например, мне вот интересно у NV / ATI все еще есть актуальные дрова для своих профи-карт под IA64?

google://ulrich+drepper

Там уже на первой странице вылезают интересные/забавные вещи наподобие:

• альтернативной расшифровки аббревиатуры «FUD»;
• дрепперского говносайта с фразой на титульной странице «Если у вас проблемы с этим сайтом, выкиньте ваш браузер» (перевод не дословный, если что :) );
• написанного им в 2001-м письма (см. ближе к концу текста) в выливанием тонны помоев на RMS за якобы предпринятую последним попытку отобрать у Ульриха игрушку^Wglibc: «people will hopefully realize what a control freak and raging manic Stallman is. Don't trust him. As soon as something isn't in line with his view he'll stab you in the back.» — s/Stallman/Drepper/ и Дреппер словно про себя писал, а процитированный кусок отлично подходит к теме обсуждаемой новости.

А если про возраст — на вид ему где-то в районе тридцатки.

68-го года он

Чтобы задавать соответствующие аттрибуты процесса, КО.

Это можно сделать и в ExecStartPre, без дубового INI c ДебильнойОпциейХренВспомнишьКакойНаКаждыйЧих = «все равно настраивать придется и маны читать».

И изобрести еще одно подобие шелла с запуском кучи внешних процессов на каждый чих.

Зачем изобретать? Шелл *уже* есть. Вам эта «куча процессов» сильно мешает?

Так я не спорю, что трушно. Но как это относится к трушности/нетрушности systemd?

Очень просто. Люди решили не выковыривать из носу революции - а сделать полезную работу, ничего при этом не ломая.

Автор как раз последовал всем стандартам. И именно поэтому и нельзя отдельный /usr

Это какие такие «стандарты» запрещают отдельный /usr в юникс?

Это можно сделать и в ExecStartPre

Ну, сделай. Без вызова внешней программы.

без дубового INI

По сравнение с shell-скриптами — образец удобства.

все равно настраивать придется и маны читать

Насильно заставляют использовать все возможные опции? Сочувствую.

Вам эта «куча процессов» сильно мешает?

Она мешает быстрой загрузке.

And programs which don't handle multiple addresses are simply broken and must be fixed anyway. Stop defending broken code.

ППКС.

Воинствующий красноглазый онанист детектед)

Вам эта «куча процессов» сильно мешает?

Она мешает быстрой загрузке.

Глупости. Никто не показал убедительно, что они мешают. Загрузка параллельным ускоряется запуском сервисов и их запуском по требованию.

Это можно сделать и в ExecStartPre

Ну, сделай. Без вызова внешней программы.

Что за страшный жупел такой «вызов внешней программы»? Отродясь такого в unix не боялись - а теперь превозносят чудо енженерной мысли, которое расширять свой функционал только за счет нагромождения тридевяти новых опций способно.

По сравнение с shell-скриптами — образец удобства.

Болезный, и зачем ты с виста слез? :)

Насильно заставляют использовать все возможные опции? Сочувствую.

Да нет. Просто утверждения о продуманном дизайне systemd после этого выглядят смешно.

Она мешает быстрой загрузке.

Что за зверь такой «быстрая загрузка»? Это сколько? И чем именно вам помешали процессы?

Никто не показал убедительно, что они мешают

А что тут показывать? Вызов функции из sys/whatever.h быстрее, чем создание процесса + вызов этой же функции. Я согласен, что по сравнению с паралельным запуском и запуском по требованию, это мелочи. Но пусть будет, карман не тянет.

Никто не показал убедительно, что они мешают

А что тут показывать?

Время.

Я согласен, что по сравнению с паралельным запуском и запуском по требованию, это мелочи

Ну вот.

Но пусть будет, карман не тянет.

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

без понятия. я в курсе, что на ИА64 производились в том числе рабочие станции, но реально их никогда не видел, только серверы.

Лучшая шутка недели. amd64 по возможности распараллеливает задачи средствами процессора

Круто. А еще можно сказать, что «amd64 по возможности распараллеливает задачи средствами» своего вентилятора. И ни разу не погрешить против истины. Маркетологи школоте окончательно моск засрали...

а титаниум во избежание тормозов требует специальные коплиляторы с распараллеливанием и для десктопа молопригоден:

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

Это правда. Смешно же наблюдать, как фантом, мутный дефект эмульсии на фотографии разумногй жизни выдают за осмысленный шаг человечества.

А что тут показывать?

Цифры. Разница должна критичной.

Вызов функции из sys/whatever.h быстрее, чем создание процесса + вызов этой же функции.

Все что меньше 0.1 сек - для вас «мгновенно». Хоть такие вещи понятны?

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

Карман тянет. Т.к. «бесплатно» получаем нового монстра, вместо прозрачной программы с ясной целью.

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

Да ты либо тролль, либо идиот.

systemd требует libdbus, который по FHS должен лежать в /usr/lib. Ты (как и дистростроители) свободен поместить его в /lib и тогда systemd будет работать и с отдельным /usr. Здесь не systemd виноват, а дистростроители и FHS.

Круто! Ты сам понял, что сказал? Если либу положить по стандарту, то поделка Леннарта перестает работать и тут - барабанная дробь - сразу же во всём виноват стандарт...

Те, что хранят свои файлики в своей папочке, да. А новые «аккуратно» разбросаны по ~/.config, ~/.cache, ~/.local и прочим.

Мусорка — это, как ни странно, все файлики в своей папочке. Но постигается это только, когда $HOME расшарен по NFS между разными архитектурами в дополнение с синхронизацией с домашним компьютером, а сам $HOME держится на каком-нибудь NetApp с веселой квотой.

AptGet> Это и протоколы, и функциональность.

То есть ты хочешь сказать, что PulseAudio может выполнять функции X-сервера, если написать для него плагин?

AptGet> А я не жалуюсь. И не создаю 100500 топиков о том, как плох PA.

Так и я не создаю. Я просто удаляю это порождение больной мысли нафиг.

Тогда glibc точно RIP. Без поддержки ARM оно нафиг никому не нужно.

Обоснования будут или это так, исключительно ради засорения БД?

franchukroman> Какой хлам? И он занимается загрузкой сервисов, и хорошо занимается.

Он на практике хуже, чем другие иниты - факт. Почему - указано выше.

Официальная причина объединения корня и /usr - не в systemd: http://fedoraproject.org/wiki/Features/UsrMove

Ну да, а официальная причина смерти трупа с 17 ножевыми ранениями - самоубиство

franchukroman> Твоя характеристика чисто субъективна. Да и ESD требовал поддержки со стороны софта, ЕМНИП. А PulseAudio отлично работает и с альсософтом, и с эсдософтом, и с осссофтом. И задержки дает намного меньше, чем ESD. Так зачем он нужен, когда по всем характеристикам хуже пульса?

Твоя характеристика - ещё субъективнее. Я пускал тот же Transfusion. Что-то не припоминаю, чтобы там поддержка ESD была.
А ESD лучше тем, что это именно сервер, предназначенный для передачи звука по сети. PulseAudio же - это Windows Way с костлями.

franchukroman> Эта делает несколько неотделимых друг от друга задач, и делает это хорошо.

1. Задачи как раз отделимые. С каких пор сетевые возможности и звук неотделимы? Или может микширование и вывод звука тоже неотделимы? Ты бредишь.
2. Если бы это недоразумение решало задачи хорошо - не пришлось бы удалять его ради того, чтобы звук работал нормально.

То есть ты хочешь сказать, что PulseAudio может выполнять функции X-сервера, если написать для него плагин?

Нет, я хочу сказать, что если такая функциональность, как эквалайзер, поддержка ladspa плагинов или сетевая прозрачность не нужна, то можно не загружать соответствующий модуль. И да, при чем здесь X-сервер?

franchukroman> Он мудак только потому, что его systemd использует libdbus?

К офтальмологу, быстро! Он мудак потому, что написал быдлокод, который противоречит стандартам, и хочет стандарт сломать исключительно ради того, чтобы быдлокод не менять.

franchukroman> Автор как раз последовал всем стандартам. И именно поэтому и нельзя отдельный /usr

Отсыпь, а?

Автор как раз последовал всем стандартам. И именно поэтому и нельзя отдельный /usr

Мда... стандарт-то, батенька, вы даже краем уха не видели...

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

AptGet> если такая функциональность, как эквалайзер, поддержка ladspa плагинов или сетевая прозрачность не нужна, то...

...достаточно использовать системную звуковую систему (ALSA, кстати, не мешало бы обрезать).

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

AptGet> И да, при чем здесь X-сервер?

К слову о функциональности же.

...достаточно использовать системную звуковую систему (ALSA, кстати, не мешало бы обрезать).

И снова получаем ситуацию, когда приложение должно поддерживать десяток популярных звуковых систем. А если в какой-нибудь антикварной OSS нет софтверного микшера, а в карте нет аппаратного - добро пожаловать в каменный век. А если вдруг внезапно нужна сетевая прозрачность, а аппликуха умеет только alsa - новый виток танцев с костылями.

Ты не о том вообще твердишь.

А о чем? PA - модульный. Что нужно еще перенести в модули чтобы было «о том»?

ALSA, кстати, не мешало бы обрезать

Внезапно согласен.

Круто. А еще можно сказать, что «amd64 по возможности распараллеливает задачи средствами» своего вентилятора. И ни разу не погрешить против истины. Маркетологи школоте окончательно моск засрали...

С разморозкой, дядя. Современные процы пытаются распараллеливать даже один поток. И не забывай про такую штуку как обмен данными между потоками, внутри камня это делать более прогрессивно чем гонять тонны данных по внешней шине. Но у штеуда ведь самые крутые станки для печати микросхем, так что им изобретать велосипед не нужно - быстрое железо выполнит дурную работу быстрее изобретательных конкурентов. А тут обломчик вышел: без чужих идей железо дурь не потянуло, можешь поплакать над неудачной железякой.

И конечно, опять этот полумифический «десктоп», которому все у нас малопригодно...

В случае с данной архитектурой действительно полумифический, большие фотки на нём не обрабатывают, в тяжёлые игры не играют.

VP, Technology Division, Goldman Sachs

Вот и пора перестать уже играть в программиста.

Вобщем-то Goldman Sachs скорее претендует на властелина мира (по-крайней мере доят они не только штаты). Вот и Ульрих в корпоративную политику втягивается... Выкинуть живую архитектуру из glibc это шаг не совсем программиста.

Выкинуть живую архитектуру из glibc это шаг не совсем программиста.

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

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

Эй, чувак, семки есть? Погугли фотки Ульриха. У него похоже единственная стратегия по жизни - прожим называется.

Пользователи десктопов ничего от потери такой архитектуры не потеряют

Моя хата с краю - я ниче не знаю. Моего десктопа это не коснется - значит мне пофиг.

Ульрих решил прессануть HP исходя из своих собственных побуждений, намекая на то, что если ему отвалят бабла, то он может передумать. А в результате репутация Linux как операционки из которой по выкидывают живую архитектуру упадет (нивапрос, твоего десктопа это не коснется, только линкуса в целом). GNU тоже такой шаг не добавит популярности (glibc все же на G начинается). Да и на всем опенсорсе такая непредсказуемость скажется не лучшим образом.

Кстати, Linux больше на серверы ориентирован, чем на десктопы. И в будущем, скорее для серверов будет свое железо и свой софт (в том числе и OC), а для десктопа свое. И у какой-нибудь Хайку гораздо больше шансов попасть на десктоп, чем у линукс.

Дреппер дроппер

Oracle

Alpha, например,

потому что Ораклу она уже не конкурент

семки

Погугли фотки Ульриха

в зеркало посмотрись сперва счам прежде чем постить ерунду

немножко регистров и операций адресации 64 битными указателями

нефига себе немножко!?
тогда и i386 - всего лишь немного расширенный i286.
а epic fail итаника был не в этом. кстати, ЕМНИП, его архитектура так и называлась - EPIC, что как бы намекает.;-)
и да, VLIW - не фига не новое слово техники. я это «новое слово» - в институте изучал, вариации на тему широко использовались, в частности, в СМ-1420 AKA PDP-11 (напомнить, какого оно года?)
И да, угадай, на базе чего было это сделано? та-да!
СБИС серии 1804 AKA AMD 29xx. VLIW там до 256 бит на команду ЕМНИП.