The OpenNET Project / Index page

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



"Ядро Linux 5.8 станет самым крупным по числу изменений"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Ядро Linux 5.8 станет самым крупным по числу изменений" +/
Сообщение от Sw00p aka Jerom (?), 17-Июн-20, 01:13 
> Всегда есть вероятность что по факту окажутся какие-то (ж-до)масоны, орден подпольных брадобреев,
> элонмаск, зеленые человечки, рептилоиды или AI решивший постебаться.

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

> Никакие законы природы
> не запрещают это. А поскольку я лично не стоял за каждым
> комитящим строчки кода - откуда я знаю наверняка какая у них
> (само)идентификация была?! :)

А никаких других законов и нет.

> Еще в моем определении подразумевается что програмер способен алгоритмы понимать и писать.

Написать может и макака, если она поймет.

>[оверквотинг удален]
> понять что упомянутый подход катит не всегда и не везде. То
> что вы в результате хотите проектировать только центр коттеджного поселка -
> а что делать если те рожи хотят именно мегаполис на цать
> миллионов?! Вы обречены откатиться к итеративному подходу и решать проблемы по
> мере поступления. И если народ требует брадобрея вот тут - значит,
> он должен быть в этом доме. Даже если это идет вразрез
> с грандпланом мега-архитекта, это значит что наступило поменять гранд-план. И в
> этом месте будет брадобрей, а не то что вы там себе
> возомнили. Потому что жизня показала что это должно быть вот так.
> Даже если вы это не предусмотрели.

Если стоит передо мной такая задача - почему бы и нет? Мне нравиться знать все с чем я работаю до мелочей, ибо в мелочах кроется тот дьявол который вас так пугает неопределенным (не продуманным, не предвиденным) поведением. Кстати, есть хороший фильм такой Демон Лапласа (2017) :)

> Лично я не знаю на этом глобусе никого способного предусмотреть ВСЕ в
> штуке масштаба САБЖА. Так же как я не знаю никого кто
> мог бы спроектировать с ноля "Нью-Йорк, только лучше" на одном дыхании.

Ну смотря на ключ по ТЗ, или с поддержкой :) Писать с нуля свою ОС, ЯП - не нужно, а проектировать второй Нью-Йорк - нужно?

> О, вы еще и в вопросах качества не шарите? Хочу вас расстроить:
> 1) Ставлю на то что с таким подходом вы не релизнете софт
> такого масштаба НИКОГДА.

Ну выше вы про Нью-Йорк будущего говорили, а теперь попахивает хотелками заказчика? Сами же в курсе, если удовлетворять все хотелки заказчика, вы не релизните софт никогда. Вот сама жизнь как софт с хотелками заказчика, она релизнится? Как говорят, мертворожденный продукт? Так что, вы противоречите самому себе.

> 2) Я готов поспорить что если вы все же удумаете заявить что
> в софте такого масштаба нет багов, я легко докажу обратное.

Буду иметь ввиду, о цене договоримся думаю.

> И даже найду дюжину багов, чтобы уж вы макнулись от души, с
> головой.

Буду только благодарен, как говорят японцы - спасибо за работу :)

> 3) И таки вы абсолютно не рубите в больших проектах и подходах.

Ну как правило во всех комментариях одно и тоже, ну сварите вы уже кашу из топора, где рецепт я так хочу его увидеть. Сначала про подходы, ну как у Декарта в Рассуждении о методе, а потом про проекты как Маска (батут). Буду только благодарен, как говорят японцы - спасибо за работу :)


> В нормальном курсе событий статистика порядка 50/50 или 40/60 для удалено/добавлено совершенно
> нормальна для типового софтварного проекта крупного масштаба который относительно устаканился.
> Если добавлено сильно больше - это значит что навернули каких-то новых
> фич. В данном случае видимо новые драйверы, это неизбежно двигает картину
> в сторону добавлено.

эту тему выше в комментариях я описал.

> Это может говорить например о том что прогер посмотрел на алгоритма, почесал
> репу, придумал вариант лучше и перекроил сие. Или ему не понравился
> общий вид и он отрефакторил в что-то более удобоваримое. А может
> быть еще и ставшее полезное "вон тем трем чувакам, хотевшим похожего",
> так что _их_ почти-дубль фичи был вытерт, а вот это чутка
> адаптировано еще и для них. А может он нашел какой-то баг.
> Или мало ли чего там еще. Для ответа на конкретный вопрос
> в конкретном случае есть git log (-p), дающий весьма конкретный ответ.

Ничего нового я не узнал увы. Спасибо за работу.

> А можно и не весь. А можно улучшить. А можно отрефакторить. Програмеры
> довольно сложные существа, равно как и их программы. Если не считать
> совсем уж вебмакак и б-длокодеров.

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


> Факин лол. Ну вот смотри, фигачил ты два дня, будучи уверенным что
> все ЗБС. И все вроде было ЗБС. Но вот всплыл некий
> Фатальный Недостаток, о которым ты даже не подумал сперва. При том
> ты изначально в душе не е...шь что его вызывает. Вопрос: где
> ты его посадил в этом интервале? И как сие починить? Кроме
> как профакать 2 дня вджоба целиком и вернуть все как было?
> А то просто профакать 2 дня впустую - обидно, да? :)

Ну "факин лол", ну наконец-то долгожданный ответ :) История нас учит не совершать ошибок. Хотя тут один момент с "будучи уверенным что все ЗБС" - читаем первый абзац данного комментария. Есть еще один момент, если у нас всего один коммит в истории и мы допустили тот самый "некий Фатальный Недостаток", каков алгоритм действия в этом случае по отлову недостатка?

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

ясно.

> ...а чего делаешь в таком раскладе ты? :))). Даже если забыть про
> то что тот ноутпад жестко мультиплеерный и еще надо подумать как
> все это агрегировать с вон той тыщенки человек. Если б ты
> был PM тимы о тыще чел, ты бы этим озаботился, но
> это явно не твой уровень.

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

> Для хранения истории изменений. Это отличный рабочий инструмент для програмера. Упомянутое
> лишь весьма частный пример использования истории изменений.

согласен отличный, выше в комментариях писал уже.

> В случае Arian V это почти так и было :). И я
> готов поспорить что они после этого малость поменяли алгоритм, хе-хе. Я
> бы удивился если бы это было не так.

что мешает уточнить?


> С реалистичной точки зрения это катит только для очень небольших масштабов. И
> даже там порой "тойота" случается.

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

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

Оглавление
Ядро Linux 5.8 станет самым крупным по числу изменений, opennews, 15-Июн-20, 12:21  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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