The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Разработчики ядра Linux обсуждают вопрос удаления субархитек..., opennews (?), 12-Дек-18, (0) [смотреть все]

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


4. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  –3 +/
Сообщение от КГБ СССР (?), 12-Дек-18, 22:55 
> Ограничением ABI X32 является невозможность адресации из приложения более 4 Гб памяти.

Ведь всем известно, что типичному приложению жизненно необходимо адресовать более 4 гигов памяти. Что? Экономия? Пусть мясные докупят ещё оперативной памяти и новый процессор!

Да и более важные дела есть — например, борьба за равенство и против харазмента и гендерного шовинизма. Не верите? Прочтите интервью с доченькой Линуса: https://opensource.com/life/15/8/patricia-torvalds-interview . Юное дарование выросло во всех смыслах Товальдс 2.0, таки да.

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

С тем, что Америка губит таланты, я согласиться не могу.

Но, действительно, некоторые детишки явно не те таланты унаследовали от родителей. :)

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Даже как-то по-человечески жаль стало Линуса.

Ответить | Правка | Наверх | Cообщить модератору

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

257. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +1 +/
Сообщение от КГБ СССР (?), 13-Дек-18, 15:43 
> Это скорее тебя несколько жаль. В таком возрасте можно было бы и
> начать догадываться чем прожектменеджер отличается от ломового кодера. Но увы -
> как известно, "иногда старость приходит одна".

http://lurkmore.to/Мне_вас_жаль

Возвращайся к пакованию эмбедовки с Али, 294-й, а то купить доширак будет не на что.

Ответить | Правка | Наверх | Cообщить модератору

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

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

280. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +1 +/
Сообщение от Аноним (-), 13-Дек-18, 16:56 
> Судя по тому, что ты пишешь, к промышленной эмбедовке ты никакого отношения не
> имеешь, а просто в розницу торгуешь ардуинками с Али. Нет? Я ошибаюсь? :-)

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

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

Как пример: штука прикидывается с одной стороны античной железкой. Хватает по 232 данные, отвечает как будто это железка, так что то к чему оно прицеплено не замечает никакого лабеана. С другой стороны оно пробрасывает награбленое по сети, к черту на рога. Оригинал так ессно не умел и в проекте, его радиус действия был жестко ограничен 232-м. Level shifter 3.3V UART проца <-> обычный 232 ессно я организовал. И таки привет ветеранюниксадминам, если прога окучивавшая UART умрет - меня с гуано таки замесят. А это таки не сетевой сервис, так что monit таки пролетает. В этом месте я и вспоминаю SD'шный вачдог апи добрым словом. Потому что техническая необходимость.

Ответить | Правка | Наверх | Cообщить модератору

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

395. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 14-Дек-18, 15:03 
> А здесь на опеннете кому ты это пытаешься продать? :-)

А здесь на опеннете я ничего не пытаюсь продать. Такому клиенту как ты что-то продавать - себе дороже, скажем прямо. Заплатишь рубль, а мозг склюешь на миллиард. Поэтому народ уже давно усвоил что с некоторыми клиентами дел лучше не иметь вообще совсем. И вот опеннет - это очень плохое место для поиска клиентов :)

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

450. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  –1 +/
Сообщение от Аноним (-), 15-Дек-18, 15:12 
> Смотря каких клиентов и для чего ты ищешь.

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

> Парочке местных персонажей не мешало бы переломать ноги и пальцы на руках при тёплой
> дружеской встрече.

Такой виш куда-нибудь к гопникам уместнее.

Ответить | Правка | Наверх | Cообщить модератору

591. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Ванёк (?), 19-Дек-18, 15:10 
А если их при встрече окажется сильно не двое :)
Ответить | Правка | Наверх | 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-й нти как этот гражданин :)

Ответить | Правка | Наверх | 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 даром никому не, компаниям проще дать денег финскому студню или амеровскому пройдохе, и что так что сяк для них работает намного лучше.

Кстати в Майкрософт политика отсутствия дискриминации по всему чему угодно работала хрен знает сколько. Это их стандартная внутренняя политика со времен царя гороха. В общем то это обычная практика для западного корпоратив. И между нами, это создает хорошую, комфортную деловую атмосферу. Когда люди работают над решением задачи, а не набивают себе цену путем обсирака других. За вот такое поведение - из западной компании можно вылететь с присвистом. И, честно, это делает работу комфортнее.

Ответить | Правка | Наверх | Cообщить модератору

514. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (514), 16-Дек-18, 21:55 
> Кстати в Майкрософт политика отсутствия дискриминации по всему чему угодно работала хрен знает сколько

Это делается не ради толерантности, а ради создания естественного отбора. В чём конкурирует СПО? В упрямости авторов? Или в том, кому более щедрый спонсор попадётся? Хуже всего, когда выживает самый демократичный.

Ответить | Правка | Наверх | Cообщить модератору

527. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от псевдонимус (?), 17-Дек-18, 06:50 
>Когда окружение разнообразное, в нем представлено больше разных точек зрения и интересных идей

Это зависит от черномазости, белозадости или половых перверсий? Да вы расист, батенька.

> когда какие-то академики что-то там себе навоображали

Хорошо показывают твою позицию "свиньи под дубом". Благодаря каким-то там акадэмикам ты можешь ковыряться в своих "кампутерах с кредитку" и даже впаривать их людям за деньги.

>Кстати в Майкрософт политика отсутствия дискриминации по всему чему угодно работала хрен знает сколько

Вот и результат -вин10, жрущая память, насилующая диск и барабанящая на братву, попутно радующая ломающими обновлениями.

> В общем то это обычная практика для западного корпоратив. И между нами, это создает хорошую, комфортную деловую атмосфер

Копротивная "культура" не может создавать здоровую атмосферу. Это косвенно подтверждает количество самоубийств в Японии, её родине.

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

Ответить | Правка | К родителю #511 | Наверх | Cообщить модератору

535. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Ю.Т. (?), 17-Дек-18, 08:47 
> Ну и по существу ты не ответил, чем линусова дочурка занимается, к
> чему стремится? Из интервью это не ясно.

"Если не ясно, в чём дело, то дело в деньгах". Народная польская пословица.
Ну чем может заниматься человек без чётко выраженной квалификации?
Диверсити защищает, гранты пилит. Тяжёлого не поднимает, работа в тепле.

Ответить | Правка | Наверх | Cообщить модератору

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

Но это же скучно, разве нет?

Ответить | Правка | Наверх | Cообщить модератору

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

Думаю, им (тяжело) работать скучно. ))

Ответить | Правка | Наверх | Cообщить модератору

542. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от псевдонимус (?), 17-Дек-18, 09:34 
>>>Диверсити защищает, гранты пилит. Тяжёлого не поднимает, работа в тепле.
>> Но это же скучно, разве нет?
> Думаю, им (тяжело) работать скучно. ))

Похоже им вообще работать скучно. Неохипаны. Сметёт  жизнь людей, называющих себя хипстерами, "Экологами", "феменистками" вместе с их показными добротой и отзывчивостью, которыми они прикрывают свой крайний гедонизм. "Мне удобна!.." и губки сложить в куриную гузку. Лет через 50 и следа не останется.


Ответить | Правка | Наверх | Cообщить модератору

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

...
> Лет через 50 и следа не останется.

Новые появятся. ))

Ответить | Правка | Наверх | Cообщить модератору

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

Зачем сразу матом?


Ответить | Правка | Наверх | Cообщить модератору

396. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 14-Дек-18, 15:06 
> Зачем сразу матом?

Ну вот поскольку для тебя это мат - твое айти и находится в состоянии "насколько лет отстала", если кто не понял ;). Без вот таких вот чувачков - ничего не получается. Если на такой роли окажется головотяп, проект будет слит даже с толпой лучших программистов и отличным финансированием.

Ответить | Правка | Наверх | Cообщить модератору

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

Зато, с другой стороны, усилиями таких прогрессоров, как ты, скоро останется 1 (прописью: одна) операционная система, не испорченная прогрессом в интересах одноклеточных девляпсов. Тебе интересно узнать её имя? Называю: OpenBSD. Нет, ты не сможешь её исправить и улучшить, к счастью.

Ответить | Правка | Наверх | Cообщить модератору

451. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 15-Дек-18, 15:19 
> Зато, с другой стороны, усилиями таких прогрессоров, как ты, скоро останется 1
> (прописью: одна) операционная система, не испорченная прогрессом в интересах одноклеточных

Я себя одноклеточным не считаю, однако некоторые мои цели, интересы и задачи, внезапно, могут быть и не ортогональны задачам хомяков. Ну вот например, FullHD видео без тиринга я с удовольствием посмотрю, имхо. И мелкие компьютеры с полкредитки - мне нравятся. Но все это не про Тео и его операционку. А умничать о правильных концепциях из NT6 - мне обломно, да.

> девляпсов. Тебе интересно узнать её имя? Называю: OpenBSD. Нет, ты не
> сможешь её исправить и улучшить, к счастью.

Да я и не рвусь особо. Чего я там забыл? Но понимаешь в чем отличие? Я то еще и жру свое г@вно сам. А вот ты - расхваливаешь опенбсд, сидючи под NT6-что-то-там. Таки уже основательно испорченной под одноклеточных.

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

Ответить | Правка | Наверх | Cообщить модератору

461. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от псевдонимус (?), 15-Дек-18, 19:25 
>>
> -EPERM в кармане.

Это не карман, снова ты карман со своим задом перепутал.

> Я то еще и жру свое г@вно сам.

То, что ты его ешь было заметно и раньше, 294-й. Теперь и других накормить пытаешься

>Вместе с его концепциями и вэями

Естественно у людей вроде тебя ни концепции, ни "вэя". Нет пути в общем.


Ответить | Правка | Наверх | Cообщить модератору

464. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (464), 15-Дек-18, 20:24 
> Это не карман, снова ты карман со своим задом перепутал.

Какой-то непредусмотрительный тип попался. С запахом адресату будет доходчивее, спору нет ;)

> других накормить пытаешься

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

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

> Естественно у людей вроде тебя ни концепции, ни "вэя". Нет пути в общем.

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

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

Ответить | Правка | Наверх | Cообщить модератору

470. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от псевдонимус (?), 15-Дек-18, 21:01 
>А решать фактические проблем

Ты их решаешь на минутку, а создаёшь на час.

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

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

>И теперь появилось много других применений компьютеров.

Не появилось.

>майнфрейм

Вот это было правильно. Но дорого.

Ответить | Правка | Наверх | Cообщить модератору

512. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (512), 16-Дек-18, 20:55 
> Ты их решаешь на минутку, а создаёшь на час.

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

Но вообще-то в моих интересах - чтобы клиенту было сухо и комфортно и чтобы он меня потом отрекламил сарафанным радио. Поэтому на самом деле клиент может расчитвать на best effort по избежанию таких ситуаций.

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

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

> Не появилось.

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

> Вот это было правильно. Но дорого.

Ну так кому правильно - тому и карты в руки. А мне вот нравятся штуки с половину кредитки. С ними у меня получается прикольная системная магия, которая нравится моим клиентам.

Ответить | Правка | Наверх | Cообщить модератору

528. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от псевдонимус (?), 17-Дек-18, 07:14 
>А вот тут уже клиент решает. Если по его мнению это так - мы не находим общий язык и он идет платить денег другому.

Психология не творца, но мелкого барыги проявилась ещё ярче.

Клиент может быть не компетентен( ну я понимаю, что тебе ...)

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

Опенсорс именно корпоративно-коммерческая (в отличие от фрисофтвар) идея. Важно, чтобы винтик не знал, что он винтик. И ножки тимбыдлинга оттуда же растут.

>Я с этим не согласен - майнфреймообразные применения компьютеров меня так например вообще совсем не интересуют.

Ты лучше не мейнфреймы критикуй, а примеры "новых задач для компьютеров" приведи.

>прикольная системная магия,
>магия

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

545. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от псевдонимус (?), 17-Дек-18, 09:55 
>почему это для меня хорошо работает

Для тебя. Не приходило в голову, что "для меня" и "для всех" несколько разные понятия? Хотя о чём я спрашиваю,для тебя есть только Великий 294-й и покупатели. А, ещё есть ненавистные старпёры, мешающие "прогрессу".

Ответить | Правка | Наверх | Cообщить модератору

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

Стабильность признак мастерства (не помню кто). Парень мастер по демагогии.


Ответить | Правка | К родителю #472 | Наверх | Cообщить модератору

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

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

427. "(offtopic) проекты, манагеры, обёртки -- и опять же п.10"  –1 +/
Сообщение от Michael Shigorinemail (ok), 14-Дек-18, 22:42 
> Обосновывай важность проституции и жульничества.

Дорогой Ильич (по большей части про первого сейчас, конечно) был проституткой, жуликом или всё-таки и тем и другим?  А внедрявшая метод проектов мадам Крупская кем была?..

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

550. "(offtopic) проекты, манагеры, обёртки -- и опять же п.10"  +/
Сообщение от пох (?), 17-Дек-18, 11:10 
> Дорогой Ильич (по большей части про первого сейчас, конечно) был проституткой, жуликом
> или всё-таки и тем и другим?  А внедрявшая метод проектов
> мадам Крупская кем была?..

мадам, похоже, по всплывшим недавно данным, подделала пресловутое "письмо к съезду", и не только его.
Что сразу же объясняет некоторые кажущиеся несуразности их семейного бытия и ставит мадам на совсем другой уровень и претензий, и возможностей. Недооценили в свое время Наденьку, видимо.


Ответить | Правка | К родителю #427 | Наверх | Cообщить модератору

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

Неплохо бы ссылку или ключевую фразу для гуглежа. А так Ленин гений. Добрый гений. Чем они там с Крупской занимались не представляет научного интереса.


Ответить | Правка | Наверх | Cообщить модератору

452. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 15-Дек-18, 15:26 
> Продолжай утешать себя. Обосновывай важность проституции и жульничества.

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

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

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

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

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

Ответить | Правка | К родителю #425 | Наверх | Cообщить модератору

460. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от псевдонимус (?), 15-Дек-18, 19:00 
>PM-ы как таковые - привносят в проект сбалансированное видение, позволяя решить практически значимые задачи с ограниченными ресурсами в разумные сроки.

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

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

Ты прямо целую плеяду руками водителей описал, PM только малая их часть. Как же надоели чудаки на другую букву, "знающие теорию управления". Они правда считают, что могут управлять чем угодно.

Ответить | Правка | Наверх | Cообщить модератору

465. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 15-Дек-18, 20:34 
> Это в технике называется генеральный конструктор или ведущий инженер.

Вот ВЫ и пользуйтесь техникой от "ведущих инженеров" и "генеральных конструкторов" как по мне. Особенно - компьютерами. А я как-нибудь пешком постою и буду учиться у PMов. Это для меня лучше работает.

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

А я тут каким боком? Я не министр обороны, да и вообще, не фанат Урфина Джюса и его деревянных. Так что если у них будут разработки сделанные Генеральными Конструкторами - да и хрен с ними, они привычные. Им скажут таскать этот хлам - пойдут таскать этот хлам.

> Ты прямо целую плеяду руками водителей описал, PM только малая их часть.

PMы это характерный подвид, встречающийся в софтварной и теперь слегка в хардварной отрасли. Но это вообще другой уровень инженерии.

> Как же надоели чудаки на другую букву, "знающие теорию управления". Они
> правда считают, что могут управлять чем угодно.

Ну я для начала учусь более или менее управлять самим собой. Поскольку с голода не помер - значит более или менее получается.

Ответить | Правка | Наверх | Cообщить модератору

473. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  –1 +/
Сообщение от псевдонимус (?), 15-Дек-18, 21:29 
>> Это в технике называется генеральный конструктор или ведущий инженер.
>  А я как-нибудь пешком постою и
> буду учиться у PMов. Это для меня лучше работает.

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

>> И он должен шарить. Не надо гражданских министров обороны, до назначения даже плац видевших
>> только по телику, зато имеющих "экономическое образование".
> А я тут каким боком? Я не министр обороны, да и вообще,
> не фанат Урфина Джюса и его деревянных. Так что если у
> них будут разработки сделанные Генеральными Конструкторами - да и хрен с
> ними, они привычные. Им скажут таскать этот хлам - пойдут таскать
> этот хлам.

Поражает глубина твоих познаний.

>> Ты прямо целую плеяду руками водителей описал, PM только малая их часть.
> теперь слегка в хардварной

Вот это действительно грозит катастрофой.


>> Как же надоели чудаки на другую букву, "знающие теорию управления". Они
>> правда считают, что могут управлять чем угодно.
> Ну я для начала учусь более или менее управлять самим собой. Поскольку
> с голода не помер - значит более или менее получается.

Это тебе к буддистам.


Ответить | Правка | Наверх | Cообщить модератору

516. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 16-Дек-18, 22:15 
> Тебе не нужно,

Я не маркетолог, так что нужно.

> ты уже научился в уши дуть и делать презентации.

"Когда человек не может объяснить чем он занимается домохозяйке - он и сам не знает чем он занимается". Резерфорд, чтоли. Так что совсем уж без этого не катит. Иначе получается толпа страдальцев фигней, забывших за что им деньги платят.

> Поражает глубина твоих познаний.

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

> Вот это действительно грозит катастрофой.

О да, это катастрофа. Для ископаемых, которые станут столь же "нужны" как СССРовские токари цатого разряда, вместе с глупыми станками. Мир изменится. Уже изменяется. Этот процесс не остановится, он начался еще в 80х прошлого века, его путь лежит в бесконечность возможностей.

> Это тебе к буддистам.

У каждого свой путь. У меня чуть иной путь чем у буддистов.

Ответить | Правка | Наверх | Cообщить модератору

529. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от псевдонимус (?), 17-Дек-18, 07:24 
>у меня в детстве любимые книжки специфичные были

Ну так можно уже было перерасти их.

>"Когда человек не может объяснить чем он занимается домохозяйке - он и сам не знает чем он занимается".

Почему же ты не хочешь объяснить, чем занимаешься?

>токари цатого разряда,

Открой газету с вакансиями.

> Мир изменится. Уже изменяется.

Видимо поэтому уровень автоматизации практически не растёт, а ведь заводами-автоматами грезили ещё в 50-х...

Ответить | Правка | Наверх | Cообщить модератору

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

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

И он кстати достаточно высок. Плюсанул ему.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Результаты проведенного тестирования товарища аналитика как всегда искать в гугле или он соизволить свой пук в лужу аргументировать?

Ответить | Правка | Наверх | Cообщить модератору

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

244. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (243), 13-Дек-18, 15:05 
> Не, не соизволитъ. Он просто немного рассказал о том, что он там
> использует. Думая, что это кому-то интересно.

Так и пусть себе использует. И майнтайнит свой зоопарк сам, если других желающих это делать не найдется. У меня вот последних лет 10 - насквозь 64-битная система на основных комапх. Зато программы могут mmap()-ать любые файлы, а графический редактор не упадет по глупой причине если я открою там даже огроменную картинку. И это все же хорошо.

Ответить | Правка | Наверх | Cообщить модератору

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

А что не 16-разрядный?  Будет ещё экономичнее и быстрее.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

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

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

155. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  –1 +/
Сообщение от КГБ СССР (?), 13-Дек-18, 09:15 
> Вернёмся к этому вопросу в 38-ом году.

Что должно произойти в 38 году? «Часы сломаются»? Это не страшно. И это на самом деле не зависит от адресации памяти. Можно «новую эпоху» открывать хоть каждые десять лет. Просто для удобства выбирают какие-то отправные даты и затем «ради обратной совместимости» морочат себе и людям головы. Это на самом деле не проблема.

Открою, кстати, маленькую большую тайну: 64-битная архитектура x86 на самом деле не использует 64-разрядную адресацию. Вот и стоило затевать всю эту канитель? Польза ведь только для Большого Железа.

Ответить | Правка | Наверх | Cообщить модератору

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

263. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  –1 +/
Сообщение от КГБ СССР (?), 13-Дек-18, 15:56 
> Поскольку вгрузить в оперативу более 4 гигз одним чихом и работсть с
> этим можно - стоило. А то что 640 кило хватит всем
> - вот кому хватит, тот пусть и пользуется 640 кило.

Вгрузить в оперативку более 4 гигов одним чихом можно было и раньше — при помощи PAE. Открою тебе страшную тайну: и больше можно было, если ещё увеличить разрядность адресации. Сколько угодно много можно, если на то пошло. Ограничение в 4 гига — это ограничение для _одной программы_. Его обойти в 32-битной архитектуре не получится, да. А надо? А точно-точно надо? Ты не сумеешь обосновать необходимость этого, поскольку в реальности не существует рациональной аргументации за это. Нет, жирные регистры можно и без всеобъемлющего перехода на 64 бита (более того, можно удвоить и учетверить жирность их, если очень надо). Да, адресовать много памяти можно и без всеобъемлющего перехода на 64 бита. Смысл 64 битов только в общем адресном пространстве для архитектуры, и более ни в чём. Ну и в типа согласовании. Внутри себя это смесь «разноразрядных» устройств и технологий. И даже та AMD64, которую ты здесь нахваливаешь, не понимая, что она есть такое, имеет на самом деле меньшую (внезапно!) разрядность адресации памяти. Просто потому, что не надо никому так много памяти в настоящее время. Чтоб ты лучше понял суть сказанного, AMD64 — это такая PAE наоборот, когда отсчитывают от большего, а не от меньшего. Ну и плюс несколько новых 64-битных плюшек. Маркетинг и разводилово в лучшем виде.

Ответить | Правка | Наверх | Cообщить модератору

271. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +2 +/
Сообщение от Аноним (-), 13-Дек-18, 16:22 
> Вгрузить в оперативку более 4 гигов одним чихом можно было и раньше — при
> помощи PAE.

Вот знаешь что, давай ты такой умный этим и пользуйся. А я таки буду использовать линейные моделди адресных пространств в стиле фон-неймана. Потому что это удобно, и ниипет. И поэтому вон тот редактор графики (любой!) спокойно сожрет даже какой-нибудь скан A0 в диком разрешении не поперхнувшись. Если в системе в принципе есть достаточно оперативы. И наверное это - хорошо и правильно.

А у тебя с твоими разглагольствованиями редактор тупо грохнется когда ему адресного пространства не хватит. И таки вгрузить картинку в память и что-то сделать с ее пикселями - это таки самый простой и логичный способ. Все остальное намного сложнее, медленнее и требует нефиговый объем нетривиального кода, который по сути попытается изобрести нечто типа свопфайлов, только через задний проход и без явной поддержки железом. Потому что в железо программы ща вообще не пускают и именно в настоящий HW-assisted paging подпертый MMU они еще и не вклинятся. Во избежание поимения всей системы.

> Открою тебе страшную тайну: и больше можно было, если ещё увеличить разрядность адресации.

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

> Ограничение в 4 гига — это ограничение для _одной программы_. Его обойти
> в 32-битной архитектуре не получится, да. А надо?

Да, надо. А почему, собственно, я не должен иметь возможность открыть БОЛЬШУЮ картинку в редакторе, например? Или еще что-то большое в память загнать целиком и поработать с этим со скоростью RAM, а не винча? Это как бы на несколько порядков разница по производительности. И мне видится очень тупым что я не могу адресовать всю оперативку одним линейным куском. Доступным одним куском а не лоскутным одеялом в куче процессов, если так удобнее и результативнее.

> Ты не сумеешь обосновать необходимость этого, поскольку в реальности не существует
> рациональной аргументации за это.

Уже обосновал. А все эти PAE как по мне должны сдохнуть жестокой смертью, как самые извращенские костыли которые я когда либо видел. Это просто е...й стыд системной архитектуры. Впрочем у интеля в IA32 такого вообще есть.

> имеет на самом деле меньшую (внезапно!) разрядность адресации памяти.

Она имеет достаточную адресацию памяти для того чтобы отдать мне ВСЮ установленную в компе оперативу одним куском в моей программе, если мне что-то такое вдруг надо.

Ответить | Правка | Наверх | Cообщить модератору

282. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  –1 +/
Сообщение от КГБ СССР (?), 13-Дек-18, 17:02 
> Вот знаешь что, давай ты такой умный этим и пользуйся. А я таки буду использовать линейные моделди адресных пространств в стиле фон-неймана. Потому что это удобно, и ниипет. И поэтому вон тот редактор графики (любой!) спокойно сожрет даже какой-нибудь скан A0 в диком разрешении не поперхнувшись. Если в системе в принципе есть достаточно оперативы. И наверное это - хорошо и правильно.

Я с год назад, кажется, приводил на этом форуме в пример сравнительно успешную работу старинного Фотошопа версии 5.5 с громадной картинкой размером 20000 х 20000 точек. Полноценной работой это, конечно, не назовешь, но тут дело принципа. 32-битный графический редактор способен схарчить и переварить такое файло. На большее в него захардкодили ограничения, ЕМНИП.

Да, и я бы предпочел в качестве ПК компьютер Гарвардской архитектуры. Не делают-с, увы.


> А у тебя с твоими разглагольствованиями редактор тупо грохнется когда ему адресного пространства не хватит. И таки вгрузить картинку в память и что-то сделать с ее пикселями - это таки самый простой и логичный способ. Все остальное намного сложнее, медленнее и требует нефиговый объем нетривиального кода, который по сути попытается изобрести нечто типа свопфайлов, только через задний проход и без явной поддержки железом. Потому что в железо программы ща вообще не пускают и именно в настоящий HW-assisted paging подпертый MMU они еще и не вклинятся. Во избежание поимения всей системы.

Обходить ограничения научились ещё в допотопные времена работой с памятью через окошко (потому-то людям с прямыми руками и не требуются на самом деле колоссальные объёмы памяти и большая разрядность адресации). Ты что, до сих пор не в курсе? Чувак, я потрясён! :)


> Это напоминает мне ту городскую легенду, где чувак посмотрел что можно выжать из его древнего драндулета, если стырить пороховой ускоритель...

Загугли же наконец про то, что такое виртуальная память.


> Да, надо. А почему, собственно, я не должен иметь возможность открыть БОЛЬШУЮ картинку в редакторе, например? Или еще что-то большое в память загнать целиком и поработать с этим со скоростью RAM, а не винча? Это как бы на несколько порядков разница по производительности. И мне видится очень тупым что я не могу адресовать всю оперативку одним линейным куском. Доступным одним куском а не лоскутным одеялом в куче процессов, если так удобнее и результативнее.

Если руки не из нижней части спины, то это всё не обязательно.

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


> Уже обосновал. А все эти PAE как по мне должны сдохнуть жестокой смертью, как самые извращенские костыли которые я когда либо видел. Это просто е...й стыд системной архитектуры. Впрочем у интеля в IA32 такого вообще есть.

То есть ты не осознаёшь, что AMD64 + EM64T — это тоже набор костылей, «расширенный и улучшенный»? Ну и замечательно, только с этого и надо было начинать, я бы не тратил своё время на чтение твоих графоманских простыней. :)

Ответить | Правка | Наверх | 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-бит эпохи.

Ответить | Правка | Наверх | Cообщить модератору

355. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от КГБ СССР (?), 14-Дек-18, 01:51 
Ещё о Фотошопах.

Photoshop 7 позволяет создать картинку размером 30000 на 30000 точек, то есть 900 мегапукселей. Её пустой стартовый вес — 2,51 ГБ.

Photoshop CS позволяет создать картинку размером 300000 на 300000 точек, то есть 90000 мегапикселей. Стартовый вес пустого файла обещают нам аж в 251,5 ГБ.

Достаточно или надо ещё? ;-) Дальнейших изысканий с последующими версиями я не проводил, ибо мне таки достаточно.

Обращаю внимание твоё и всех адептов прогрессивной математики, что это 32-разрядные программы.

Ответить | Правка | Наверх | 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
Ответить | Правка | Наверх | Cообщить модератору

571. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Алексей Михайловичemail (?), 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, если
> к тому моменту это еще будет работать и будет кому-то надо.
> Потому что х...во когда железка внезапно взглюкивает по такой причине.

С этим соображением я согласен. Если часы железные, то придётся менять железо. А оно вполне может быть живо к году Г, и даже незаменимо, если прикручено к какой-нибудь домне или станку за десять миллионов зелени или к чему похуже.

Но наших серверов и персоналок этой всё не касается.

Ответить | Правка | Наверх | Cообщить модератору

299. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 13-Дек-18, 17:55 
> С этим соображением я согласен. Если часы железные, то придётся менять железо.

Часы железные. Но - время из них я перегружаю лишь эпизодически, в основном при старте после ресета и все такое. А на самом деле оно живет в 64-бит переменной которая "никогда не переполнится" (по крайней мере, я до этого не доживу, и железяка тоже). Оно апдейтится по IRQ от RTC, но софт не видит 32-бит счетчик. Он ворочает 64-бит переменную. Это удобнее и безопаснее по математике и к тому же доступ к тому 32-бит счетчику специфичный, так что 64 бита в RAM как-то менее проблемны в целом, и иметь дело с ними может оказаться еще и быстрее.

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

Ну вот я не знаю заранее куда этот код и потомки этих железок будут в 2038 году прикручены и мне бы не хотелось чтобы меня вспомнили нелестным словом за такую отложенную по времени свинью. Поэтому в новых проектах этот момент я стараюсь учитывать. А хотя-бы и поступившись немного эффективностью кода. Потому что 64 бита на 32-битном ядре таки требуют больше кода. Так что с точки зрения только эффективности - меня можно за это и замесить.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Да и линукс с ним, я уже устал от этой дискуссии. :)

Ответить | Правка | Наверх | Cообщить модератору

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

Мой браузер, после того, как откроет все окна и вкладки, которыми я пользуюсь, потребляет существенно больше, чем 4Гб памяти. Так что идите вы со своими 32 битами на маршрут по умолчанию.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

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

Твой браузер умеет работать в несколько процессов при необходимости. Проблемы могут быть только если одна вкладка выжрет 4ГиБ памяти.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ну вот с некоторых пор даже в ИТ многие люди не понимают столь банальных основополагающих вещей.

Ответить | Правка | Наверх | 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 гигабайта, лишь бы у тебя было столько виртуальной памяти.
Ответить | Правка | Наверх | Cообщить модератору

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

294-й не понимает, что такое виртуальная память и её адресация. И в кучу к нему этого не понимают, судя по таким дискуссиям, 2/3 анонимов опеннета.

Ответить | Правка | Наверх | Cообщить модератору

274. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 13-Дек-18, 16:31 
Тот анонимус таки не 294 :P. Но общую идею вроде уловил и вещает нормально.

Как там у стругацких было? Слепил дубля, отправил его на работу. Дубль получился туповатый... как-то так, да :)

Ответить | Правка | Наверх | 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 +/
Сообщение от Nuzhnyemail (?), 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-х разрядных программ и ОС есть и свои отрицательные моменты - как минимум вдвое большее потребление памяти при сохранении восстановлении контекста как задачи так и функций, просто их, как я понимаю, нивелирует кэш.

Ответить | Правка | Наверх | Cообщить модератору

247. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (243), 13-Дек-18, 15:11 
> нет, не поэтому. В архитектуре x86_64 банально вдвое больше регистров общего назначения,
> так-что хотя-бы за счёт этого - гораздо больше можно провести вычислений
> не производя чтение/запись из/в память.

И еще гарантированный SSE2, так что можно и пачку SSE2 регистров еще приплюсовать.

> 4G адресного пространства. Плюс, конечно, ОС должна знать и не выделять
> память сверх этого лимита.

Выделить более 4 гигз при 32 битах - еще ухитриться надо. Потому что вся математика к этому очень недружелюбна.

> Кстати у 64-х разрядных программ и ОС есть и свои отрицательные моменты
> - как минимум вдвое большее потребление памяти при сохранении восстановлении контекста
> как задачи так и функций, просто их, как я понимаю, нивелирует кэш.

Реально потребление растет процентов на 15-30. Вот никто и не хочет возиться. Тем более что юзерам будет периодически падать на бошку внезапный рояль с 20 этажа, в виде например падающего граф. редактора и проч, совершенно независимо от того сколько памяти воткнуто в комп.

Ответить | Правка | Наверх | Cообщить модератору

260. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Q2Wemail (?), 13-Дек-18, 15:45 
У меня на 32-х битах всё работает быстро, а на 64-х свопится при трёх вкладках с джирой.
Вот это вот факт.

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

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

289. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +1 +/
Сообщение от Аноним (289), 13-Дек-18, 17:23 
http://lurkmore.to/УМВР
Ответить | Правка | Наверх | 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 Shigorinemail (ok), 13-Дек-18, 00:34 
Да, мы тоже посмотрели (и glebfm@ попримеривался) -- в итоге решили, что оно того не стоит даже с учётом вагона контейнеров прям у себя.
Ответить | Правка | Наверх | Cообщить модератору

455. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 15-Дек-18, 15:49 
> Да, мы тоже посмотрели (и glebfm@ попримеривался) -- в итоге решили, что
> оно того не стоит даже с учётом вагона контейнеров прям у себя.

И правильно сделали. С нехваткой ресурсов как у альта на куда более прозаичные и базовые вещи, ввязаться в такую войну с ветряными мельницами было бы форменным донкихотством. За которое отдуются например, ваши пользователи.

Ответить | Правка | Наверх | 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".

Ответить | Правка | Наверх | Cообщить модератору

177. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  –1 +/
Сообщение от КГБ СССР (?), 13-Дек-18, 10:47 
> P.S. "даже бд", ага. Как раз БД-то пишут профессионалы (или хотя бы
> когда-то писали) а не гуанокодеры, и иногда их даже принято оптимизировать,
> а не "шлите еще денег, мы что-то перестали влезать в 64
> бита, даешь 128".

А вот пишут про будни профессионалов и даже немного в тему: https://vitus-wagner.dreamwidth.org/2041653.html

Ответить | Правка | Наверх | Cообщить модератору

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

249. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 13-Дек-18, 15:18 
> собрать один раз как тебе надо минимальный дистрибутив в котором ты хотя
> бы умеешь собирать пакеты и дальше его ставить там где нужен - не, не по силам?

Ну как бы готовый дебиан раскатать - на порядки менее трудозатратно и куда как предсказуемее. Даже с debootstrap'ом и кастомизацией.

А в своем минимальном дистре придется быть самому себе билдером, тестером, майнтайнером, QA, спецом по секурити и чем там еще. В общем такой себе человек-оркестр. И очень быстро окажется что объем работ - реально на целый оркестр.

А так можно не мелочиться и вообще, написать свою операционку с нуля. И проги. Можно даже на ассемблере, чтобы еще эффективнее. Суперманьяки даже так пробовали, так появился колибри ОС. Но они уже подвыдохлись, устав от ассемблера, особенно когда с 32 на 64 захотелось. И что-то у них там уже какой-то c-- чтоли. Ща они еще сравнят с оптимизатором кода современного gcc, офигеют, и чего доброго проект задвинут совсем. Или на питоне с досады перепишут, так по крайней мере не надо 10 лет камасутрой заниматься, а результат однофигственный.

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

Вот лично ты сколько коммерческих применений на открытом софте запилил, мистер эксперт?

Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

294. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от пох (?), 13-Дек-18, 17:43 
> А в своем минимальном дистре придется быть самому себе билдером, тестером, майнтайнером, QA,
> спецом по секурити и чем там еще.

для пересборки чужих готовых пакетов - ничего из этого не требуется.

А я себе в любом дистре - билдер, тестер и майнтейнер, потому что наверняка что-то отсутствует, что-то сделано не так и не там как мне хочется. Но, конечно, проще ждать ебилдов. Ждите, чо.

> Вот лично ты сколько коммерческих применений на открытом софте запилил, мистер эксперт?

что такое "коммерческое применение" ?

и с чего вдруг мы перескочили от сборки для себя, любимого, дистрибутива с приглянувшейся архитектурой, к каким-то коммерческим применениям?

Ответить | Правка | Наверх | Cообщить модератору

303. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 13-Дек-18, 18:03 
> для пересборки чужих готовых пакетов - ничего из этого не требуется.

Ну как бы если воспроизвести конфигу 1 в 1 как у популярного дистра - зачем тогда эта камасутра? Выигрыш в чем? А если конфига другая - ну тогда все новые заскоки ты и будешь сам разруливать. Поляна получится не вытоптанной, и соответственно плясать на ней станет сложнее. Это ради чего?

> А я себе в любом дистре - билдер, тестер и майнтейнер, потому
> что наверняка что-то отсутствует, что-то сделано не так и не там
> как мне хочется. Но, конечно, проще ждать ебилдов. Ждите, чо.

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

> что такое "коммерческое применение" ?

Наверное, применение которое принесло бабки своим внедрением. Или хотя-бы сэкономило.

> и с чего вдруг мы перескочили от сборки для себя, любимого, дистрибутива
> с приглянувшейся архитектурой, к каким-то коммерческим применениям?

Хм, а что, зарабатывать тем что нравится деньги уже стало чем-то зазорным? А мне так это дело почему-то очень нравится :). Без всяких десяточек с бэкдорами. Такое мне западло и самому использовать и клиентам давать. Не мой стиль!

Ответить | Правка | Наверх | Cообщить модератору

330. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от пох (?), 13-Дек-18, 20:27 
> Ну как бы если воспроизвести конфигу 1 в 1 как у популярного дистра - зачем тогда эта
> камасутра? Выигрыш в чем?

так я что-то не понял - тебе нужна неподдерживаемая популярным дистром архитектура или нет?

конфига другая в мелочах, большя часть содержимого /bin все еще собирается autoconf'ом, который используется там по назначению, а не модным meson'ом, поэтому очень многое чудесным образом соберется само, правильно определив архитектуру. Чему-то удастся помочь, найдя вопрос на stackoverflow (может даже и ответ). v8 починить - вероятно, не в силах человеческих.

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

> Однако билдить так весь дистр

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

> Наверное, применение которое принесло бабки своим внедрением. Или хотя-бы сэкономило.

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

> Хм, а что, зарабатывать тем что нравится деньги уже стало чем-то зазорным?

подмена темы "не могу сделать" на "зарабатывать" безусловно является зазорным.

"не хочу делать потому что мне за это не заплатят ни копейки" - ну так с этого можно было начать.

Ответить | Правка | Наверх | 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 гигз опачки).

И вот заметь, гражданин КГБ вещает про то как надо. Но сам заниматься этим все-таки не хочет почему-то :)

Ответить | Правка | Наверх | Cообщить модератору

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

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

Как ни горько, но вероятнее всего именно так. Ведь то, что изделие переусложнилось и перетяжелилось, там отлично видят (причём первыми).

Ответить | Правка | Наверх | 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. Если я вижу тенденцию замены в сообществе людей обезьянами, а хоть как-то приемлемых технологий булшитом, то пусть оно там в булшитном обезьяньем мирке и варится, а у меня достаточно приятных и полезных занятий в моей жизни. :-)

Ответить | Правка | Наверх | 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 в результате.

Ответить | Правка | Наверх | 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 гига - как-то глупо, чтоли, стало.

> ну потому что не в той области у него квалификация, и возраст уже тоже не тот.

А значит хакеры должны переться с перспектив обслуживания старческих чудачеств, вместо того чтобы заняться тем что им интересно, гы :)

> У меня на необычные околокомпьютерные хобби сил и времени уже нет, и
> не будет - я предпочитаю теперь собак.

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

462. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (-), 15-Дек-18, 20:09 
> Очень недальновидное отношение, даже глупое.

Как по мне, плясать бесплатно под чужую дудку, делая то что мне самому не надо - удовольствие ниже среднего. И на что-то такое я готов только эпизодически и при хорошей компенсации. Как еще понятнее это объяснить? :)

> не наследственные владельцы того же линукс-ядра, и не они с нуля
> и до верху всё там сделали.

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

...но типы с опеннета с своими вэйностями ко всему этому - отношения не имеют.

Ответить | Правка | Наверх | 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 кто-то делал.

Ответить | Правка | Наверх | 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-индустрии.

Ну как бы готовность оплачивать работу - зависит от нужности работы. И если в целом люди решат что такой работинг им не надо - будет тяжко. Хотя при очень сильном желании ты можешь до сих пор устроиться хоть инструктором верховой езды. Но желание потребуется сильное, и это скорее всего будет не в соседнем квартале. Возможно даже придется сменить место обитания. Но тем кому очень принципиально - таки решают вопрос. Другое дело что это весьма немассово и в целом общество ставит некий фильтр, потому что в целом потребность в такой работе крайне низкая. Так что среднего пошиба конюху средних веков - ничего не светит.

> выгул собак, пожалуй, выглядит пока максимально перспективно.

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

Ответить | Правка | Наверх | 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, прекрасный древний артефакт

Ответить | Правка | Наверх | 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билизмов накопилось за годы.

Ответить | Правка | Наверх | 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, например.
Ответить | Правка | Наверх | Cообщить модератору

338. "Разработчики ядра Linux обсуждают вопрос удаления..."  –1 +/
Сообщение от Аноним (-), 13-Дек-18, 21:47 
> как там с FSF? полмиллиона на фуршеты и буклеты. Вместо того,

Как бы фуршеты и буклеты тоже нужны - для продвижения FSF и их идей.

> чтобы доделать Hurd, например.

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

Ответить | Правка | Наверх | Cообщить модератору

354. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."  +/
Сообщение от Аноним (354), 14-Дек-18, 01:09 
> борьба за равенство и против харазмента и гендерного шовинизма.

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

Представь, ты должен на отлично написать курсовую на тему "как я победю харасмент и гендерный шовинизм в моей семье/компании/стране" - обратного пути уже не будет - вокруг враги и несправедливость!

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

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

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

Все претензии к разработчикам дистрибутивов. Разработчики ядра поддерживали x32 несколько лет, и если бы за это время дистрибутивы начали ее полноценно использовать, удаление бы сейчас обсуждалось.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

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

* не обсуждалось

Ответить | Правка | Наверх | 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 видней, конечно, за линукс...
Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру