The OpenNET Project / Index page

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



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

Оглавление

Изучение изменения размера кодовой базы Ext4, Btrfs и XFS, opennews (??), 23-Июн-11, (0) [смотреть все]

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


1. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +2 +/
Сообщение от Аноним (-), 23-Июн-11, 12:28 
> В отличие от XFS, файловые системы Ext4 и Btrfs идут по пути постоянного усложнения.

Проблема только в том что у XFS строк уже больше, а у btrfs фичность как-то поболее будет :)))

> комментарии составляют примерно 39% от всего размера кода.

Суровые парни. Этак скоро маны будут прямо в сорцы копипастить :)

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

4. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +10 +/
Сообщение от klalafuda (?), 23-Июн-11, 12:41 
> Суровые парни. Этак скоро маны будут прямо в сорцы копипастить :)

Ну вообще то генерация документации в т.ч. манов на основании соотв. образом представленных комментариев - это мягко говоря давно не новость. Doxygen & K в руки как пример. Скорее, вопрос в первую очередь в алаберности или же безалаберности кодеров что все это ваяют. Станут ли они писать вменяемую документацию к своим творениям или нет. Конечная же форма изъявления мыслей не особо принципиальна.

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

14. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  –1 +/
Сообщение от Аноним (-), 23-Июн-11, 14:10 
> Ну вообще то генерация документации в т.ч. манов на основании соотв. образом
> представленных комментариев - это мягко говоря давно не новость.

Правда вот такие мануалы обычно стойко навевают воспоминания о анекдоте "моя скорость печати - 1200 знаков в минуту! Правда такая фигня получается..."

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

46. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 23-Июн-11, 17:01 
неа. а вот такие коментари уж точно навевают мысли о быдлокодере.
признайся сразу что ты не кодер вообще. так будет всем лучше. :D

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

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

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

50. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  –1 +/
Сообщение от fr0ster (ok), 23-Июн-11, 17:12 
> я бы даже сказал что это суровая необходимость.
> И если бы ей следовали все, то как проще бы жилось чесслово.

А тут надо помнить, что административные проблемы не решаются техническими средствами.
Надо до начала проекта решить >>все<< вопросы, не только какой язык программирования, какой фреймворк, какую архитектуру использовать, но и как комментировать код, как именовать объекты, как писать документацию, как проверять код на соответствие принятым на проекте стандартам. В общем скажете это азы, будете правы, скажете КО, опять будете правы, но 90% проблем это именно из за игнорирования мелочей на проектах даже не самых мелких. И это не только в СПО, в СПО еще ничего, а вот код писанный в коммерческих конторах...

ЗЫ Да я знаю, что когда говорят код нужен "на вчера" только святой удержится от написания наколеночного кода, лишь бы работало здесь и сейчас.


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

54. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  –1 +/
Сообщение от ананим (?), 23-Июн-11, 17:19 
>А тут надо помнить, что административные проблемы не решаются техническими средствами.

Э-э-э-э... О чём Вы?
Комментарии к коду - не административная проблема, а техническая.
когда это начинают понимать (порой поздно), то прекрасно решают её административными средствами.
Вот только какие же административные средства в джаст4фан? :D

>ЗЫ Да я знаю, что когда говорят код нужен "на вчера" только святой удержится от написания наколеночного кода, лишь бы работало здесь и сейчас.

привычка - вторая натура.
даже быдло-код производится с теми же сроками и с тем же количеством комментов.
ЭТО не вопрос. :D

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

58. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +1 +/
Сообщение от ананим (?), 23-Июн-11, 17:26 
зыж
>>ЗЫ Да я знаю, что когда говорят код нужен "на вчера" только святой удержится от написания наколеночного кода, лишь бы работало здесь и сейчас.
>привычка - вторая натура.
>даже быдло-код производится с теми же сроками и с тем же количеством комментов.

айзен жабадок снизу уже привёл в качестве "доказательства".
А я даже добавлю - все современно-модные ИДЕ генерируют шаблоны классов/процедур/фу... вместе с этим "жабадоком".
при этом порой любезно сворачивая эти "доки" в одну строчку. чтоб не мешали так сказать быдлокодить. :D
но если серьёзно, то однажды появившаяся привычка оставлять комментарии (при чём не для дяди, а для себя любимого. Ибо через день уже "забываешь" чё там накодил Вчера в пылу "озарения") очень сильно помогает в дальнейшем.

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

62. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от fr0ster (ok), 23-Июн-11, 17:32 
> но если серьёзно, то однажды появившаяся привычка оставлять комментарии (при чём не
> для дяди, а для себя любимого. Ибо через день уже "забываешь"
> чё там накодил Вчера в пылу "озарения") очень сильно помогает в
> дальнейшем.

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

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

102. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  –2 +/
Сообщение от anonymous (??), 23-Июн-11, 22:21 
если каментить надо каждый чих — то это быдлокод: нормальный код отлично читается без каментов. надо писать каменты только там, где используются неочевидные хаки; а это очень мизерное количество кода. если хаки раскиданы везде… ну, лучше всего пейсателей расстрелять, а потом уволить.
Ответить | Правка | Наверх | Cообщить модератору

59. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от fr0ster (ok), 23-Июн-11, 17:26 
>>А тут надо помнить, что административные проблемы не решаются техническими средствами.
> Э-э-э-э... О чём Вы?
> Комментарии к коду - не административная проблема, а техническая.
> когда это начинают понимать (порой поздно), то прекрасно решают её административными средствами.

Техническая это использовать Доксиген или еще чтото для документирования, а требование комментить код под угрозой непринятия кода это административное средство.

> Вот только какие же административные средства в джаст4фан? :D

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

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

Привычка тут ни причем.

> даже быдло-код производится с теми же сроками и с тем же количеством
> комментов.

Кто комментирует код, когда уверен, что он на один раз, выполнить и выбросить?

> ЭТО не вопрос. :D

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

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

65. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 23-Июн-11, 17:40 
>Техническая это использовать Доксиген или еще чтото для документирования, а требование комментить код под угрозой непринятия кода это административное средство.

ну дык и я о чём?
Важно не путать проблемы со средствами.
хорошо документированный код - это техническая проблема. Хотя её "техничность" проявляется только со временем.
Решается как правило административно.
Был даже опытЪ в одной конторе - требование на 4-5 строчек кода должна быть 1 строчка комментария. Во народ изгалялся! :D

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

74. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от fr0ster (ok), 23-Июн-11, 18:01 
>>Техническая это использовать Доксиген или еще чтото для документирования, а требование комментить код под угрозой непринятия кода это административное средство.
> ну дык и я о чём?
> Важно не путать проблемы со средствами.
> хорошо документированный код - это техническая проблема. Хотя её "техничность" проявляется
> только со временем.

Хорошо документированный код это вообще не проблема.
Плохое документирование техническая проблема, только если ваши технические средства (ИДЕ, редактор и тп) не дают вам комментить ясно и понятно, но это абсурд, нет таких редакторов, которые бы не давали вам писать коммент больше одной строки.
Так что хреновое комментирование и документирование это административная проблема.

> Решается как правило административно.

Естественно, проблема административная и решается административно.
Техническая проблема решаемая административно это бросание персонала "грудью на амбразуру" под угрозой премирования :)

> Был даже опытЪ в одной конторе - требование на 4-5 строчек кода
> должна быть 1 строчка комментария. Во народ изгалялся! :D

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

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

81. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 23-Июн-11, 18:32 
>Так что хреновое комментирование и документирование это административная проблема.

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

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

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

99. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  –1 +/
Сообщение от fr0steremail (ok), 23-Июн-11, 21:43 
>>Так что хреновое комментирование и документирование это административная проблема.
> фиг там.
> Административная она до тех пор, пока кода мало, а тот кто его
> написал ещё не уволился.

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

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

Новый сервер это техническое решение, административное это реорганизация, найм сотрудников.

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

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

> интеграторы точно знают о чём я сейчас говорю. Легаси-код, сырцы на который
> давно утеряны и полное отсутствие документации очень часто приводят к тому,
> что приходится всё "сломать" и сделать по другому вместо поэтапного внедрения
> и с соответствующими расходами.

Каковы причины появления легаси-кода и утери сырцов? Исключительно административные.

> При этом код точно был. Когда-то и где-то, но никто не знает
> где. :D

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

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

134. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 24-Июн-11, 03:33 
>Это всегда административная проблема. Если руководитель допустил завязанность проекта на одного человека и он стал невзаимозаменяемым, это сугубо административная проблема.

эх, молодо-зелено...
Через дцать лет любой проект завязан на "одного" человека. Да и руководителей уже дцать на пенсию проводили.
>Каковы причины появления легаси-кода и утери сырцов? Исключительно административные.

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

Ну всё, закрываем контору и уходим на пенсию. :D
А поскольку контора градообразующая, то всем городом.
Ну а чё, сами виноваты. Не предусмотрели ни винду, ни линух, как написали на кларионе/бтриве/парадоксе, так и работают. блин гейс, сцуко не сказал, что эти перспективные технологии загнутся. :D

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

157. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 24-Июн-11, 11:02 
какие в попу сейчас госконторы?
тут вон Путин возмущался что в приморье таможню уже в аренду берут, а вы говорите...
Госконторы - это не пенсионный фонд случаем? А там уже счёты на калькуляторы заменили? О-о-о! :D
Нет. просто крупные предприятия. причем поголовно. от мясокомбинатов, до станкостроительных заводов и банков (да-да!!! банков)
отсюда вывод, который вы и сами наметили - если старшие говорят что мы живём в опе, то вы только можете догадываться в какой по объёму.
При этом все мелкие конторы сейчас пишут под себя точно так же. И если они через дцать лет и станут крупными, то тоже будут в том же анусе что и все.
Ответить | Правка | Наверх | Cообщить модератору

56. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 23-Июн-11, 17:22 
> признайся сразу что ты не кодер вообще. так будет всем лучше. :D

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

> я бы даже сказал что это суровая необходимость.

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

> И если бы ей следовали все, то как проще бы жилось чесслово.

А уж если бы люди писали бы нормальную документацию и руками, а не гребаными автогенераторами - и подавно.

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

61. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 23-Июн-11, 17:31 
http://wiki.lustre.org/lid/subsystem-map/subsystem-map.html

вот документация которая генерится из исходников.
Автоматически.

Считаете это "на отвали" ?


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

75. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 23-Июн-11, 18:05 
> Считаете это "на отвали" ?

Да как сказать? Фифти-фифти. Врубиться по этой доке в принципе можно. Но читать нормально написанные доки, без странных заглушек (половина которых видимо принадлежит перу Капитана Очевидности) - приятнее и результативнее.

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

77. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от fr0ster (ok), 23-Июн-11, 18:11 
> Да как сказать? Фифти-фифти. Врубиться по этой доке в принципе можно. Но
> читать нормально написанные доки, без странных заглушек (половина которых видимо принадлежит
> перу Капитана Очевидности) - приятнее и результативнее.

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

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

126. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 01:21 
> Вообще говоря дока автоматом сгенерированная из нормально написанных комментариев в коде
> ничем не хуже нормально написанной документации.

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

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

128. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 24-Июн-11, 01:28 
> Проблема только в том что полноценной документацией это ни разу не является.

авторы Qt удивлены.

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

165. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 12:19 
> авторы Qt удивлены.

Они не умеют использовать grep? :)

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

98. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +2 +/
Сообщение от PereresusNeVlezaetBuggyemail (ok), 23-Июн-11, 21:33 
> http://wiki.lustre.org/lid/subsystem-map/subsystem-map.html
> вот документация которая генерится из исходников.
> Автоматически.
> Считаете это "на отвали" ?

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

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

Касаемо примера выше — да, большая часть там, к сожалению, бесполезна.

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

63. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 23-Июн-11, 17:34 
>Признаюсь в том что автоматически сгенеренная документация - как правило такой же бред как автоматически сгенеренные стихи.

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

угу.
Это когда только изучаешь эту технологию. А когда ты в ней уже "живёшь", то лишний раз лезть в доки ОЧЕНЬ не хочется. А когда код соотвественно комментирован, со ссылками, мыслями, rfc, то как приятно с ним работать.
>А уж если бы люди писали бы нормальную документацию и руками, а не гребаными автогенераторами - и подавно.

что порой думаешь - да лучшеб сцуко не писали!! Смотришь так мсдан - должно работать, а на практике - фиг. Ну должен переменными блоками читать из компорта, ан нет... Только с левого форума узнаёшь - читай побайтово и будет тебе щастье.
"Прелести" проприетарной разработки многие кодеры уже считают нормой. Что враньё.

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

79. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 23-Июн-11, 18:23 
> верно. Но так же верно, что вставить в нужное место свой коммент
> "забывают" уж очень сильно "быдло" из кодеров.

Да не только быдло, вон там человек в общем то по делу подпинывает btrfs'ников за скудные коменты. Именно при их функционале документироать свои потуги надо бы побогаче. А XFS - 40% кода являющегося коментами все-таки перебор. Авторам в пору книгу написать - архитектура XFS. И вынести половину из коментов в нее.

> Это когда только изучаешь эту технологию. А когда ты в ней уже
> "живёшь", то лишний раз лезть в доки ОЧЕНЬ не хочется.

Когда ты в ней уже живешь, 40% портянок вместо полезного постоянно скроллить и лицезреть должно бы подзаколебывать слегка :)

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

Если вы уже живете этим кодом, 40% коментов в нем для вас явно избыточны по идее. Никто не говорит что коментить не надо, но когда почти полсырца - комент, это как-то злобно.

> - должно работать, а на практике - фиг.

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

> Ну должен переменными блоками читать из компорта, ан нет...

О, уарты... это в позиксах вообще довольно брейнфакерская тема. Сам с ними бодаюсь, при том по документации одно, в линях другое, макосях - третье. Да блин! А как кроссплатформенно позырить сколько в буфере байтов лежит?! А как кроссплатформенно скорость выше 115200 отхватить? Впрочем и 115200 то не везде гарантируют (чорт, неужели нельзя принять свежий позикс и зафиксировать эти моменты законодательно, чтобя я не пыжился с пачкой ifdef?). Какие-то извраты с ремапом скорости 38400. Вообще адЪ. Правда, надо сказать что в виндозе с ними все тоже довольно горбато :)

> Только с левого форума узнаёшь - читай побайтово и будет тебе щастье.

Дык побайтно - медленно и печально, однако. Оверхед на системные вызовы большой получается, нагрузка на систему большая а скорость работы может просесть. Кстати читать блоками при non-blocking I/O вроде более-менее получается. Правда как-то странновато, но в принципе - работает. Хоть и пришлось слепить свою функцию-враппер которая делает read() в том виде котором хотелось бы и раскинуть там энное количество костыликов.

> "Прелести" проприетарной разработки многие кодеры уже считают нормой. Что враньё.

Не вижу никаких особых прелестей, тем более что в виндозе с уартами тоже все довольно криво, я бы сказал. Если в *никсах хотя-бы прикладывают мордой об стол если baud не поддерживается оборудованием, то в винде вам нагло врут "зашибись!" и ... работают на старом бауде. Видали мы такие прелести!

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

83. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 23-Июн-11, 18:43 
>Да не только быдло, вон там человек в общем то по делу подпинывает btrfs'ников за скудные коменты.

оставлю это на его совести. :D
>А XFS - 40% кода являющегося коментами все-таки перебор. Авторам в пору книгу написать - архитектура XFS. И вынести половину из коментов в нее.

а нахрена? Разрабам ФС на это покласть, а от "новичков" кто её купит тоже ничего хорошего - устаревшие знания из такой книги нифига не догонят даже той доки (кстати очень не плохой) на вики http://xfs.org/index.php/XFS_Status_Updates и текста в комментариях
>Если вы уже живете этим кодом, 40% коментов в нем для вас явно избыточны по идее. Никто не говорит что коментить не надо, но когда почти полсырца - комент, это как-то злобно.

современным ИДЕ прыгать по клику мышки не привыкать. Что на 100 страницах A4, что на 60 - один клик. и мне не надо лесть чёрте куда, чтобы узнать что там за значения сможет принять вон та переменная из вон той структуры.
ну а то что в доке это ещё будет и устаревшим - это к бабке не ходить.

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

189. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 23:28 
> оставлю это на его совести. :D

Думаю у него совесть чиста - он в вопросе разбирается.

> а нахрена? Разрабам ФС на это покласть, а от "новичков" кто её
> купит тоже ничего хорошего - устаревшие знания из такой книги нифига
> не догонят даже той доки (кстати очень не плохой) на вики
> http://xfs.org/index.php/XFS_Status_Updates и текста в комментариях

Нафига? Чтобы был ман дающий обзор общей концепции на общем уровне + наводки какие части где и как реализованы и чего смотреть. И зачем и почему реализовано именно так (на это очень редко дают ответ коменты и сгенеренные доки, но это важно для понимания как оно на самом деле должно работать). Актуальным курсом дел это не будет, но общее понимание алгоритмов и задумок - даст. А вот более тонкую синхронизацию с интересующим исходником уже естественно придется делать вкуривая оный. Только когда у вас гора манов и автогенеренный бред - концепция и вообще задумки авторов целиком как-то не очень хорошо складываются в единую стройную картину. У именно XFSников с этим еще более-менее ничего.

> современным ИДЕ прыгать по клику мышки не привыкать. Что на 100 страницах
> A4, что на 60 - один клик.

И тем не менее, сорцы пухнут, время компила растет, сорц захламляется.

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

Именно такая информация в структуре как комент - да, удобно.

> ну а то что в доке это ещё будет и устаревшим - это к бабке не ходить.

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

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

218. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Michael Shigorinemail (ok), 26-Июн-11, 21:25 
> время компила растет

За счёт комментариев?  Строго говоря, Вы правы, но самому не смешно ли?

>> ну а то что в доке это ещё будет и устаревшим -
> Да и хрен с ним

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

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

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

84. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от iZEN (ok), 23-Июн-11, 19:03 
> Когда ты в ней уже живешь, 40% портянок вместо полезного постоянно скроллить
> и лицезреть должно бы подзаколебывать слегка :)

Открой для себя нормальные IDE со сворачиваемым фолдингом участков комментариев.

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

127. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 01:27 
> Открой для себя нормальные IDE со сворачиваемым фолдингом участков комментариев.

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

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

130. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  –1 +/
Сообщение от iZEN (ok), 24-Июн-11, 01:38 
>> Открой для себя нормальные IDE со сворачиваемым фолдингом участков комментариев.
> О, как это в стиле жабистов: сначала создать себе проблем, а потом
> их героически решать. Ты и про профайлеры ту же песенку пел.
> Конечно, можно тормознуть себя в 4 раза неэффективным рантаймом, а потом
> упираться для компенсации этого факта в профайлере, как ты регулярно всем
> советуешь. А можно просто выбросить тормозную яву и не иметь этого
> головняка.

Преждевременные оптимизации вредны. Сначала пишем код — потом оптимизируем, разве трудно понять эту простую вещь?

Примерно каждые три года удваивается объём ОЗУ среднестатистического компьютера. Так что пока ты будешь кодить на "эффективном" маложрущем C++, который не имеет бесплатных и простых инструментов профилирования, тебя удавят заказчики за несданый проект.

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

131. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +2 +/
Сообщение от anonymous (??), 24-Июн-11, 01:42 
> Примерно каждые три года удваивается объём ОЗУ среднестатистического компьютера.

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

> пока ты будешь кодить на "эффективном" маложрущем C++, который не имеет
> бесплатных и простых инструментов профилирования

жабообезьянка прочитала статью про C++ от 80-х годов прошлого века и думает, что с тех пор ничего не поменялось.

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

139. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от kshetragiaemail (ok), 24-Июн-11, 05:46 
> это был пример рассуждений типичного быдлокодера. "ну и что, что у вас
> техника быстрее стала? нам не проблема тормознуть даже технику в пийсят
> раз быстрее!"

К сожалению писать качественный код стало экономически не выгодно. Зачастую проще докупить железа.

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

Для С++? Ничего-таки не поменялось. Как был УГ так и остался.


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

140. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 24-Июн-11, 08:15 
> Для С++? Ничего-таки не поменялось. Как был УГ так и остался.

как язык — да. а вот по поводу инструментария — не согласен: его понаделали всякого.

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

158. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 24-Июн-11, 11:07 
>Для С++? Ничего-таки не поменялось. Как был УГ так и остался.

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

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

190. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 23:29 
> К сожалению писать качественный код стало экономически не выгодно.

LSE с вами не согласны :)

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

216. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Michael Shigorinemail (ok), 26-Июн-11, 19:04 
> К сожалению писать качественный код стало экономически не выгодно.

Ит'с эн оверстэйтмент, мэн.

http://lwn.net/Articles/443775/

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

166. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 12:29 
> Сначала пишем код — потом оптимизируем, разве трудно понять эту простую вещь?

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

Я только одно не понимаю: неужели кого-то прикалывает работать заведомо на мусорный бак?

> Примерно каждые три года удваивается объём ОЗУ среднестатистического компьютера. Так что
> пока ты будешь кодить на "эффективном" маложрущем C++, который не имеет
> бесплатных и простых инструментов профилирования, тебя удавят заказчики за несданый проект.

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

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

179. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 24-Июн-11, 13:25 
> Как это не имеет? Ты не в состоянии найти в пакетах целый
> выводок профайлеров? :)

он даже про valgrind не знает, потому что для его жабы оно бесполезно. а если в гуголь и сходит, то наверняка заметит из всего валгринда только memcheck и будет улюлюкать про то, что «у вас даже GC нет!»

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

191. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 23:35 
> всего валгринда только memcheck и будет улюлюкать про то, что «у
> вас даже GC нет!»

У него наверное даже ума собрать статистику сисколов strace'ом не хватит - такие только и могут что уповать на то что умный рантайм за них, дебилушек, подумает. Какой продукт получается в результате - нетрудно догадаться. О чем разумеется в курсе все кроме самого автора. Свое - не пахнет, да, iZEN :)

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

138. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от kshetragiaemail (ok), 24-Июн-11, 05:42 
Для нормального кода IDE не нужен. Он должен быть интуитивно понятен. Где непонятен - пара строк комментариев, которые не портят читабельность. Даже больше скажу. IDE могут быть вредны, т.к. скрыввают/смазывают представление о том как реально выглядит код и как он расположен на файловой системе.
Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

141. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 24-Июн-11, 08:19 
> как реально выглядит код и как он расположен на файловой системе.

это совершенно не важно. да и — что значит «как реально выглядит»? вон в Обероне в коде могут быть картинки, фильмы и вообще любой объект системы. и как там код «реально выглядеть» будет?

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

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

167. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 12:30 
> вон в Обероне в коде могут быть картинки, фильмы и вообще любой объект системы.

Смешались в кучу кони, люди... и получилась хрень на блюде.

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

176. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 24-Июн-11, 13:15 
>> вон в Обероне в коде могут быть картинки, фильмы и вообще любой объект системы.
> Смешались в кучу кони, люди... и получилась хрень на блюде.

сразу видно Анонимного Эксперта, который не по наслышке знаком с системой Оберон.

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

203. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 25-Июн-11, 18:37 
> сразу видно Анонимного Эксперта, который не по наслышке знаком с системой Оберон.

Судя по повсеместному распостранению Оберона не так уж эксперт и неправ...


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

227. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от kshetragiaemail (ok), 27-Июн-11, 07:07 
>>> вон в Обероне в коде могут быть картинки, фильмы и вообще любой объект системы.
>> Смешались в кучу кони, люди... и получилась хрень на блюде.
> сразу видно Анонимного Эксперта, который не по наслышке знаком с системой Оберон.

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

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

229. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 27-Июн-11, 07:22 
> Система отличная, но малораспространенная. Пока же приходится смотреть на реализации некоторых
> идей в других языках и пускать слюни.

в принципе, BlackBox Component Builder открыт. вроде как даже уже есть порт ядра и линкера в пингвинус. осталась мелочь (улыбается): отвязать её от винды и привинтить заместо какой-нибуть тулкит (нененене, только не GTK, пожалуйста, что угодно, только не GTK! %-).

я под винду когда-то достаточно активно на BCB писал — было очень приятно.

правда, там закавыка: вроде как лицензия не позволяет делать коммерческий софт.

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

235. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от kshetragiaemail (ok), 27-Июн-11, 14:24 
действительно мелочь.
Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

237. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 27-Июн-11, 16:13 
> действительно мелочь.

на крайний случай есть winelib. (убегает, увёртываясь от булыжников)

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

226. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от kshetragiaemail (ok), 27-Июн-11, 07:06 
> кстати, советую попробовать Оберон с хорошо обработаным редактором. хотя... нет, не надо.
> потом остальные будут ужасно раздражать тем, что так и не вылезли
> до сих пор с уровня 70-х.

Как только появится свободная реализация в исходниках под Unix. И не Оберона, а Компонентного Паскаля, тогда конечно.

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

230. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 27-Июн-11, 07:25 
> Как только появится свободная реализация в исходниках под Unix. И не Оберона,
> а Компонентного Паскаля, тогда конечно.

BlackBox Component Builder. я, кстати, после открытия кода отрывал компилятор от остальной системы и даже обучал его читать обычные текстовые файлы. керналь и линкер для эльфов там тоже есть. в принципе, переписать низкоуровневый UI-код, чуть почистить — и вполне богло бы взлететь на *nix. разговоров об этом в своё время было много, но увы…

правда, насчёт «свободной» не уверен: кажется, коммерческий софт на нём писать нельзя.

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

228. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от kshetragiaemail (ok), 27-Июн-11, 07:15 
>> как реально выглядит код и как он расположен на файловой системе.
> это совершенно не важно. да и — что значит «как реально выглядит»?

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

> вон в Обероне в коде могут быть картинки, фильмы и вообще
> любой объект системы. и как там код «реально выглядеть» будет?

За картинки в коде вообще нужно бить по рукам. Тем более Оберонщиков. По идее как раз у вас в крови должно быть не мешать интерфейсы с реализацией и уж тем более с данными.


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

231. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 27-Июн-11, 07:30 
> Это значит, что я должен быть в состоянии прочитать код без IDE
> костылей. И его размещение на файлухе является дополнительным способом структурирования
> кода. _Очень_ странный вопрос для Оберонщика.

у оберона вообще с понятием «файл» некоторая напряжёнка. они, вроде бы, и есть, но в принципе — нафиг не нужны. и «без IDE» в обероне тупо не бывает.

> За картинки в коде вообще нужно бить по рукам. Тем более Оберонщиков.
> По идее как раз у вас в крови должно быть не
> мешать интерфейсы с реализацией и уж тем более с данными.

отчего? вполне удобно пихнуть пару диаграмок в код и спрятать в фолд. надо — открыл фолд и посмотрел. не надо — скрыл и не мешает. при передаче кому-то deep copy вполне себе всё передаст. если у него нет компонента для отображения — не страшно: покажет alien placeholder.

как раз вот в обероне разрывать код и документацию я смысла не вижу совершенно.

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

103. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +1 +/
Сообщение от anonymous (??), 23-Июн-11, 22:42 
документация к Qt генерится из исходников. лучше документации я пока не видел, даже «написаной руками».
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

239. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от maginoidemail (ok), 30-Июл-14, 20:30 
>> признайся сразу что ты не кодер вообще. так будет всем лучше. :D
> Признаюсь в том что автоматически сгенеренная документация - как правило такой же
> бред как автоматически сгенеренные стихи. То-есть, читать нормальную, писанную человеком
> который шарил в вопросе - сильно быстрее, доходчивее и приятнее.

На то и посажен кодер , а на пккодер.


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

6. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anon8 (ok), 23-Июн-11, 13:02 
> Проблема только в том что у XFS строк уже больше, а у btrfs фичность как-то поболее будет :)))

Нуну, и что, неужели btrfs уже годна для продакшена?
Фичи-фичами, а главное - стабильность.

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

8. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от BratSinot (?), 23-Июн-11, 13:42 
А еще пряморукость. Я полностью согласен(в отношении с Btrfs) с Эдуардом Шишкиным.
Ответить | Правка | Наверх | Cообщить модератору

17. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +1 +/
Сообщение от koblin (ok), 23-Июн-11, 14:17 
Предложения, алтернативы?
Ответить | Правка | Наверх | Cообщить модератору

19. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +3 +/
Сообщение от Аноним (-), 23-Июн-11, 14:32 
> А еще пряморукость. Я полностью согласен(в отношении с Btrfs) с Эдуардом Шишкиным.

У Шишкина было какое-то очень предвзятое мнение, наверное потому что он разработчик конкурирующего дизайна ФС. Он взял кривой юзкейс, получил кривой результат и долго плевался. Кстати, половина его плевков несмотря на едкость вполне попала в цель, и указанные слабые места были существенно затюнены/пофикшены. Соответственно, спасибо ему за тестирование этого юзкейса, хоть и далеко не основного для btrfs. В результате никому не стало хуже, а некоторым станет лучше. Что-то не так?

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

24. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 23-Июн-11, 15:12 
плевались как раз авторы btrfs
Ответить | Правка | Наверх | Cообщить модератору

27. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +1 +/
Сообщение от Аноним (-), 23-Июн-11, 15:21 
> плевались как раз авторы btrfs

Да они там на пару плевались, но в результате - тюнинг/твикинг все-таки был. Спасибо Шишкину за ругань! Половина уже стало неактуально - вот так и надо работать ;).

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

35. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +1 +/
Сообщение от Михаил (??), 23-Июн-11, 15:35 
Файловая система должна работать с любыми данными. Если заявила отсутствие ограничений на число файлов - будь добра обеспечить.
Об этом и речь, что нет гарантии что бтрфс на конкретной структуре данных и особенностях с ними работы не сдохнет, не займёт всё место. Никто не проверял алгоритмы, на то что фрагментация гарантированно меньше некоторого значения (как в XFS например). Замечены попытки решения задач способами которые для этого не приспособлены, с вытекающими побочными эффектами.

Да добавили костыль на один случай. Будут ещё. И будет код пухнуть исключениями, больше и больше. А потом чтобы разобраться в бардаке и восстановить данные оракл потребует у корпораций миллиарды :)

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

67. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +2 +/
Сообщение от Аноним (-), 23-Июн-11, 17:43 
> Файловая система должна работать с любыми данными. Если заявила отсутствие ограничений
> на число файлов - будь добра обеспечить.

У них раньше было ограничение прямо в утилитах - они посылали при попытке создать том менее 2 Гб. Шишкин создал 600Мб и завалил его мелкими файлами. Получив вполне предсказуемый результат.

> Об этом и речь, что нет гарантии что бтрфс на конкретной структуре
> данных и особенностях с ними работы не сдохнет, не займёт всё место.

В сложной конфигурации вам вообще никто ничего и никогда не гарантирует. XFS в частности хорош лишь для больших нефрагментированных файлов. На куче мелочи он вообще зверски тормознут. В последних версиях ядра (в районе 37..39 ядер чтоли) это подтянули слегка правда, стало более-менее похоже на остальные типа EXT4/JFS/... даже.

> Никто не проверял алгоритмы, на то что фрагментация гарантированно меньше
> некоторого значения (как в XFS например).

Теория - это прекрасно. Проблема только в том что если не миндальничать и взять дейстивтельно негуманный сценарий, например, забить XFSный том до упора торентами с мелкими блоками, слитыми без преаллокации - сдуется он точно так же как и любая другая ФС. И толку с теоретизирований будет немного. Все-равно без дефрагментации будет неюзабельно. Когда диск выдающий на крайних треках 150Мб/сек натужно шуршит, выдавая 10Мб/сек при последовательном чтении файла - толку то с ваших теоретических гарантий? На практике - Ж!

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

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

> Да добавили костыль на один случай. Будут ещё. И будет код пухнуть
> исключениями, больше и больше.

Функционала у btrfs намного больше. Там уже управление томами в пуле есть, фоновый дефраг, ребаланс, CoW и при этом у них почему-то до сих пор меньше строк кода. Напрашивается вывод что код у них в целом довольно эффективный.

> А потом чтобы разобраться в бардаке и восстановить данные оракл потребует у корпораций миллиарды :)

Для начала, CoW не убивает данные при перезаписи. И кстати кто оплатит протертые нулями XFSом файлы?Есть желающие? :)

Вообще, файловые системы которые вы противопоставляете - очень разные по функционалу. Ну например у XFS нет снапшотов. И перезапись - разрушающая. И полного журналирования - нет (спасибо что хоть вытирание нулями спорных кусков удавили). И фоновый дефраг/ребаланс и прозрачное добавление диска в пул с XFS не сделаешь. XFS это "просто еще одна ФС". А btrfs это такой комплексный комбайн. К слову довольно прилично надирающий зад и в режиме "якобы мы тут простая ФС".

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

16. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +1 +/
Сообщение от Аноним (-), 23-Июн-11, 14:14 
> Нуну, и что, неужели btrfs уже годна для продакшена?

Еще не годна. Но неотвратимо приближается к этому моменту.

> Фичи-фичами, а главное - стабильность.

В продакшне? Разумеется. Но это не значит что не надо идти вперед. К слову, у XFS довольно плохая история заботы о сохранности пользовательских данных с ее затиранием нулями в случае краха в момент записи. А вот btrfs в этом плане должен быть напротив очень хорош, архитектурно у него для этого все карты на руках.


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

105. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 23-Июн-11, 22:54 
> годна для продакшена?

что значат эти слова? винда вон нестабильна даже при штатном использовании без хаков — а считается «готовой для продакшэна».

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

108. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от PereresusNeVlezaetBuggyemail (ok), 23-Июн-11, 23:10 
>> годна для продакшена?
> что значат эти слова? винда вон нестабильна даже при штатном использовании без
> хаков — а считается «готовой для продакшэна».

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

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

168. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 24-Июн-11, 12:33 
Да какой там бубен, если видеодрайвера падают? Ты или пользуешься футуристичной VESA видеокартой, или миришься с тоннами глюков а то и просто дедлоков. А каким бубном ты исправишь глючный видеодрайвер? Даже если б ты это захотел, сырцов нет, а колупать многомеговую портянку дизассемблером - крайне малоперспективно, тем более что для защиты от модификаций там все подписями нынче обложено от и до.
Ответить | Правка | Наверх | Cообщить модератору

183. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от PereresusNeVlezaetBuggyemail (ok), 24-Июн-11, 13:54 
> Да какой там бубен, если видеодрайвера падают? Ты или пользуешься футуристичной VESA
> видеокартой, или миришься с тоннами глюков а то и просто дедлоков.
> А каким бубном ты исправишь глючный видеодрайвер? Даже если б ты
> это захотел, сырцов нет, а колупать многомеговую портянку дизассемблером - крайне
> малоперспективно, тем более что для защиты от модификаций там все подписями
> нынче обложено от и до.

Видеокарты нормальные используйте. Или кроме ATI (AMD) и NVIDIA других названий не знаете? В моём продакшене видеокарты вообще в большинстве случаев побоку, более того, Win2003+ даже последовательную консоль какую-никакую заимел нормальную — необходимости в видеокарте попросту нет. К слову, видеодрова в других ОС глючат ничуть не меньше. С той оговоркой, что винда отвечает лишь за свои родные дрова, а не то г..., которое качают с сайтов производителей.

А насчёт колупания дизассемблером — не в кассу. Хотите ковыряться в дровах — используйте другие ОС, никто не запрещает. Я лично только поприветствую. Просто не надо со своим уставом в чужой монастырь, ку? :)

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

193. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 25-Июн-11, 00:12 
> Видеокарты нормальные используйте. Или кроме ATI (AMD) и NVIDIA других названий не знаете?

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

> необходимости в видеокарте попросту нет.

Как бы тянуть отдельный шнур до сервера - совершенно не прикольно. В нормальных осях есть ssh а на случай когда приперло - можно и по сетке отсигналить ядру наконец, если сервер в труднодоступном месте а что-то идет не так и юзермод настолько сдох что ssh уже не работает (при постоянном out of memory такое бывает, например).

> К слову, видеодрова в других ОС глючат ничуть не меньше.

По-моему, под семерку/висту (ну и 2008) одни из наиболее глючных дров из всех ос вообще. Правда вот на серверных ОС видеодрайвера почти не у дел и с чего б им глючить, если 99% времени никто не то что ничего не делает а даже в монитор не смотрит? А если попользоваться - найти чертыхания юзеров висты/7/2008 совершенно не проблема.

> С той оговоркой, что винда отвечает лишь за свои родные дрова,

Судя по тому как работают эти драйвера - они там вообще ни за что не отвечают. Они только формально лепят подпись. Все. В результате амдшные дрова - глючат как хотят и тормознее официальных амдшных чуть ли не в два раза. Где они это вообще берут? Интел - аналогично. Очень нестабильные и падучие драйвера. С подписью майкрософт. На нвидию тоже бочки катят периодически. Кстати в XP/2003 с этим получше было. В семерке/висте для благой цели укрепления DRM драйвера переделали, производители в спешке писали ну хоть что-нибудь к выходу висты. Понятно что и как написали. И главное - как пользователь я не вижу что мне это все дает кроме геморроя.

> а не то г..., которое качают с сайтов производителей.

Субъективно у MS такое же г... как и на сайте производителей. Можно подумать, они сами пишут дрова. Они лепят свою подпись на какую-то античную версию дров производителя, и вот уже встроенный в винды драйвер готов. Такое же г, только еще и окаменелое.

> Просто не надо со своим уставом в чужой монастырь, ку? :)

Ну так и не лезьте.Идите на MSDN и лечите там какие замечательные у MS дрова. Там вас поймут.

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

196. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от PereresusNeVlezaetBuggyemail (ok), 25-Июн-11, 02:34 
>> Видеокарты нормальные используйте. Или кроме ATI (AMD) и NVIDIA других названий не знаете?
> Почему же, знаем встроенные в интелские чипсеты еще. Вообще тормозная гадость. С
> не менее гадостными драйверами, запросто вешающими систему. Кстати дрова для серверных
> мамок от интела под винду - вообще жуткий вырвиглаз. Мало того
> что все часто упихано в монолитный EXE инсталлер, так он еще
> и обламывается установить дрова как только условия хоть на миллиметр отличаются
> от идеала. Лишний хотфикс или не да - и вот уже
> инсталлер говорит что винда не та. Круто придумано.

Второй ноутбук с Intel'ом на борту. В винде проблем нет вообще. В X.org есть небольшой глюк при переключении консолей (кто там виноват, дрова или Иксы, точно сказать не могу), в целом всё стабильно. Может, конечно, просто потому, что мой продакшн, как я уже говорил, не завязан сильно на видеоподсистеме? :)

И, повторюсь, винда тут абсолютно ни при чём. Траблы с видеодрайверами есть везде.

>> необходимости в видеокарте попросту нет.
> Как бы тянуть отдельный шнур до сервера - совершенно не прикольно.

А что, VGA/DVI-шнур чем-то лучше?

> В нормальных осях есть ssh

Никто не мешает его ставить в винде. Более того, в винде есть RDP (сюрприз!), а также можно поставить VNC, RAdmin, NX...

> а на случай когда приперло - можно
> и по сетке отсигналить ядру наконец, если сервер в труднодоступном месте
> а что-то идет не так и юзермод настолько сдох что ssh
> уже не работает (при постоянном out of memory такое бывает, например).

Вот когда SSH не работает, и вообще совсем плохо, и нужна последовательная консоль. Учите матчасть, что ли...

>> К слову, видеодрова в других ОС глючат ничуть не меньше.
> По-моему, под семерку/висту (ну и 2008) одни из наиболее глючных дров из
> всех ос вообще. Правда вот на серверных ОС видеодрайвера почти не
> у дел и с чего б им глючить, если 99% времени
> никто не то что ничего не делает а даже в монитор
> не смотрит?

Браво, до вас начало доходить.

> А если попользоваться - найти чертыхания юзеров висты/7/2008 совершенно
> не проблема.

Да. Равно как и чертыхания пользователей других ОС.

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

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

Родные драйвера MS - это, например, драйвер SCSI-контроллера. Который взаимодействует с т.н. драйвером минипорта. Который в свою очередь уже предоставляется обычно производителем контроллера.

MS и Windows - мишени крупные, промахнуться сложно. Но вы всё же умудрились это сделать. :)

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

Эта подпись всего лишь удостоверяет, что MS действительно дала вам эти дрова. Не путайте тёплое с мягким, а автора - с издателем.

> На нвидию тоже бочки катят периодически. Кстати в XP/2003 с этим
> получше было. В семерке/висте для благой цели укрепления DRM драйвера переделали,
> производители в спешке писали ну хоть что-нибудь к выходу висты. Понятно
> что и как написали. И главное - как пользователь я не
> вижу что мне это все дает кроме геморроя.

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

Упреждая вопрос, откуда я, опёнковод с семилетним стажем, это знаю? Да просто интересуюсь много чем. Кроме разве что 3D-игр...

>> а не то г..., которое качают с сайтов производителей.
> Субъективно у MS такое же г... как и на сайте производителей. Можно
> подумать, они сами пишут дрова. Они лепят свою подпись на какую-то
> античную версию дров производителя, и вот уже встроенный в винды драйвер
> готов. Такое же г, только еще и окаменелое.

Что им производитель даёт, то они и лепят. Попутно отрезая всё нестабильно работающее. Хотите понтов и скорости - идите на поклон к разработчику железки.

>> Просто не надо со своим уставом в чужой монастырь, ку? :)
> Ну так и не лезьте.Идите на MSDN и лечите там какие замечательные
> у MS дрова. Там вас поймут.

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

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

204. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Аноним (-), 25-Июн-11, 19:33 
> Второй ноутбук с Intel'ом на борту. В винде проблем нет вообще.

Не знаю как там у вас нет проблем, а я регулярно наталкиваюсь на взвисы семерок и вист на интеловских чипсетах. Обычно графика виснет настолько, что помогает только reset или там где его нет (ноуты) - power button на 4 sec. Особенно характерно для входа-выхода hibernate/powersave режимы, там вообще шансы на взвис видео чуть ли не 50/50, особенно с интелом как раз.

> В X.org есть небольшой глюк при переключении консолей (кто там виноват, дрова
> или Иксы, точно сказать не могу),

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

> в целом всё стабильно. Может, конечно, просто потому, что мой продакшн,
> как я уже говорил, не завязан сильно на видеоподсистеме? :)

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

> И, повторюсь, винда тут абсолютно ни при чём. Траблы с видеодрайверами есть везде.

Они есть везде, но некоторые из них не чинятя годами. В частности это касается интеловских дров для висты и семерки.

>>> необходимости в видеокарте попросту нет.
>> Как бы тянуть отдельный шнур до сервера - совершенно не прикольно.
> Никто не мешает его ставить в винде.

..кроме того момента что винда довольно плохо через него управляется. Она никогда не затачивалась на такое применение. Не верите? Да блин, попробуйте через ssh настройки сетевого адаптера прописать? А сможете точку доступа из вай-фай адаптера через него переконфигурять? Чтобы уж совсем хорошо? Ну и толку от такого SSH? Это не шелл, это борьба с искусственными проблемами.

> Более того, в винде есть RDP (сюрприз!),

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

> а также можно поставить VNC, RAdmin, NX...

Можно. Только оно нагружает проц и сеть намного сильнее + не очень хорошо переживает сбои + второе очень часто детектится антивирусами как малварь. В сумме гемора получается выше крыши.

> Вот когда SSH не работает, и вообще совсем плохо, и нужна последовательная
> консоль. Учите матчасть, что ли...

Ни разу не видел придурков которые бы развлекались тем что от серверов сериальные шнурки бы тянули, это требует необоснованных затрат на проводку. При наличии уже проложенного эзернет-шнурка это жуткий маразм. Тем более что кернелу не так уж принципиально, работать с сетью или с сериальным шнурком. И как минимум линух можно обучить реагировать на alt-sysrq-* и по сети, как раз в случае если серверу очень плохо, а физически к нему лезть неудобно. Так удается выводить из штопора даже машины где ssh по какой-то причине не может взлететь (например, постоянный OOM не дающий форкнуть новый процесс + oom_killer почему-то не смог разрулить проблему).

> Браво, до вас начало доходить.

Да. Если компьютер выключить - то он вообще глючить не будет. Вывод: WinME - прекрасная система. Если компьютер с ней не включать.

> Да. Равно как и чертыхания пользователей других ОС.

Тем не менее, позволю себе еще 1 пример: если надо чтобы usb-девайс, например FTDI232, работал долго и в автопилотном режиме, линукс выглядит намного перспективнее. В винде оно иногда может отвалиться и .. все. До физического передерга девайса связи не будет. В линухе - оно для начала не отваливается. Однако если при работе с юсб-девайсами что-то идет не так, у пингвина хватает ума сделать "виртуальный передерг" устройства, вправив ему мозг ресетом по шине. Аналогично - SATA линки и прочая. Можно конечно долго бухтеть что глючным железом пользоваться не надо, однако если вопрос пойдет о том чтобы сколько-то девайсов сколько-то лет работало без людей, окажется что все гораздо сложнее и раз в год даже кабель питания глючит :). Мало ли, какие-то мощные помехи на кабель собирются, или там что еще. В таком случае винде нечем похвастать.

> делают производители.

Тогда к чему была реклама MS? К тому что с S3 Virge DX оно работает без глюков? У меня и на нем глюки в свое время были.

> Microsoft предоставляет необходимые спецификации (WHQL), если
> драйвер им удовлетворяет - велкам.

По факту, MS вообще ничего толком не тестирует. Случаи разворота на тестированиях крайне редки. По факту этот набор букв ничего не значит. Всего лишь глупый понт чтобы хоть немного оправдать необходимость лепить подписи и прикрыть свое неприкрытое желание рулить производителями железа.

> Драйвера, идущие вместе с ОС, обычно тестируют лучше прочих,

Малозаметно. Во всяком случае, у висты/семерки с этим предостаточно проблем.

> но и функционал при этом у них зачастую урезанный в целях надёжности.

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

> Сбой в драйвере - практически всегда оказывается на совести его разработчика.

Я уже заметил - не важно что и где случается, майкрософт никогда не виноват. Интересно, а вот по поводу такого бага http://support.microsoft.com/kb/2249857 вы их сможете отмазать? В баге который разносит на куски файловую систему на диске - тоже сторонние производители виноваты? :)

> Родные драйвера MS - это, например, драйвер SCSI-контроллера. Который взаимодействует
> с т.н. драйвером минипорта. Который в свою очередь уже предоставляется обычно
> производителем контроллера.

Да, вон там повыше пример для родных драйверов и утилит майкрософта. При записи крешдампа на том более 2Тб том оказывается попросту угроблен и не восстанавливается простыми методами - вместо файловой системы вермишель получается. Очень интересно как вы отмажете MS в этот раз.

> MS и Windows - мишени крупные, промахнуться сложно. Но вы всё же
> умудрились это сделать. :)

Мы добавим, нам не сложно.

> Эта подпись всего лишь удостоверяет, что MS действительно дала вам эти дрова.
> Не путайте тёплое с мягким, а автора - с издателем.

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

> большинстве случаев косячат они.

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

> Упреждая вопрос, откуда я, опёнковод с семилетним стажем, это знаю? Да просто
> интересуюсь много чем. Кроме разве что 3D-игр...

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

> Что им производитель даёт, то они и лепят.

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

> Попутно отрезая всё нестабильно работающее. Хотите понтов и скорости - идите
> на поклон к разработчику железки.

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

> Вы лезете с опенсорсным миропониманием (к слову, весьма узким) в пропиетарный мир.

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

> жалею, что потратил на вас время, скорее всего, это было впустую.

Ничего, зато набили руку в напевании дифирамбов. Идите вон на MSDN, там вас поймут.

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

212. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от PereresusNeVlezaetBuggyemail (ok), 26-Июн-11, 00:41 
>> Второй ноутбук с Intel'ом на борту. В винде проблем нет вообще.
> Не знаю как там у вас нет проблем, а я регулярно наталкиваюсь
> на взвисы семерок и вист на интеловских чипсетах. Обычно графика виснет
> настолько, что помогает только reset или там где его нет (ноуты)
> - power button на 4 sec. Особенно характерно для входа-выхода hibernate/powersave
> режимы, там вообще шансы на взвис видео чуть ли не 50/50,
> особенно с интелом как раз.

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

>> В X.org есть небольшой глюк при переключении консолей (кто там виноват, дрова
>> или Иксы, точно сказать не могу),
> Не заметил никаких проблем с переключением консолей. Как минимум в убунте с
> ее фреймбуферными консолями - все отлично. И вообще, интеловский драйвер может
> месяц непрерывно отпахать без ребутов. При просмотре фильмов, использовании 3D в
> играх и что там еще. Выводы напрашиваются.

Искренне рад за вас.

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

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

>> И, повторюсь, винда тут абсолютно ни при чём. Траблы с видеодрайверами есть везде.
> Они есть везде, но некоторые из них не чинятя годами. В частности
> это касается интеловских дров для висты и семерки.

Драйвера под другие ОС, повторюсь, не лучше. Вы сами себе противоречите: сначала доказываете мне, что, мол, один мой частный случай ничего не значит, а вот у вас та-а-акие глюки были на винде. А потом наоборот, приводите свой частный случай в другой ОС. Бездарный троллинг. User294 обычно лучше это делал, я по нему уже прямо-таки скучаю.

>>>> необходимости в видеокарте попросту нет.
>>> Как бы тянуть отдельный шнур до сервера - совершенно не прикольно.
>> Никто не мешает его ставить в винде.
> ..кроме того момента что винда довольно плохо через него управляется. Она никогда
> не затачивалась на такое применение. Не верите? Да блин, попробуйте через
> ssh настройки сетевого адаптера прописать? А сможете точку доступа из вай-фай
> адаптера через него переконфигурять? Чтобы уж совсем хорошо? Ну и толку
> от такого SSH? Это не шелл, это борьба с искусственными проблемами.

Через SSH - легко. Про ipconfig рассказать? Насчёт "точку доступа из вай-фай адаптера через него переконфигурять" не совсем понятно, что имелось в виду: то ли что сетевой адаптер работает как точка доступа, то ли что надо до точки доступа достучаться через сетевой адаптер, к компу с которым сделано подключение по SSH... В любом случае всё это через SSH делается. Просто по-другому, чем в *nix. И, к слову, этот разговор не имеет ни малейшего отношения к вопросу о видеодрайверах.

>> Более того, в винде есть RDP (сюрприз!),
> ...только при умирании графики он как ни странно обычно тоже умирает. Как
> правило, при сбое графики он показывает логон-скрин. Далее прогресс логона. Все
> - на этой фазе он остается навсегда. Вроде бы система и
> не полный труп, но даже корректный шатдаун там сделать - очень
> сложно.

Вы это кому рассказываете, а? Я же, по-вашему (см. ниже) латентный виндузятник, и по определению должен знать недостатки своей системы лучше вас как линуксоида, м-м-м? ;)

>> а также можно поставить VNC, RAdmin, NX...
> Можно. Только оно нагружает проц и сеть намного сильнее + не очень
> хорошо переживает сбои + второе очень часто детектится антивирусами как малварь.
> В сумме гемора получается выше крыши.

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

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

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

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

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

> При наличии уже проложенного эзернет-шнурка это жуткий маразм. Тем более что кернелу
> не так уж принципиально, работать с сетью или с сериальным шнурком.
> И как минимум линух можно обучить реагировать на alt-sysrq-* и по
> сети, как раз в случае если серверу очень плохо, а физически
> к нему лезть неудобно. Так удается выводить из штопора даже машины
> где ssh по какой-то причине не может взлететь (например, постоянный OOM
> не дающий форкнуть новый процесс + oom_killer почему-то не смог разрулить
> проблему).

А если у вас проблемы с сетью? DDoS-атака, глючный драйвер сети, сошедший с ума или ошибочно сконфигурированный фаервол... А RS-232 туп как пробка и работает везде. Через него можно (а подчас - единственно возможно) вести отладку ядра, между прочим.

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

>> Браво, до вас начало доходить.
> Да. Если компьютер выключить - то он вообще глючить не будет. Вывод:
> WinME - прекрасная система. Если компьютер с ней не включать.

Про передёргивания см. выше.

>> Да. Равно как и чертыхания пользователей других ОС.
> Тем не менее, позволю себе еще 1 пример: если надо чтобы usb-девайс,
> например FTDI232 <...>

Ну какое, какое отношение это имеет к видеодрайверам?! Вы хотите мне доказать, что Linux круче винды? ЗАЧЕМ?! Во-первых, всё равно не докажете - я буду использовать подходящий инструмент, будь то *BSD, Linux, Windows или вообще FreeRTOS. И у меня всё будет работать. А у вас, боюсь, будут описанные вами проблемы.

>> делают производители.
> Тогда к чему была реклама MS?

Где я рекламировал MS? Или рекламой считается тыканье собеседника в его, гм, ошибки?

> К тому что с S3 Virge
> DX оно работает без глюков? У меня и на нем глюки
> в свое время были.

1. Я ничего не говорил про S3. 2. Вообще то было сильно глючное железо само по себе, и я слабо понимаю, с чего вы приписываете мне утверждение его как эталона надёжности. Кстати, да, вы не слышали никогда, что иногда виноват не драйвер, и не ОС, а сама железяка, которая не соответствует собственным спецификациям? Но это так, к слову...

>> Microsoft предоставляет необходимые спецификации (WHQL), если
>> драйвер им удовлетворяет - велкам.
> По факту, MS вообще ничего толком не тестирует. Случаи разворота на тестированиях
> крайне редки. По факту этот набор букв ничего не значит. Всего
> лишь глупый понт чтобы хоть немного оправдать необходимость лепить подписи и
> прикрыть свое неприкрытое желание рулить производителями железа.

Почитайте сначала, что такое WHQL, а? В эти тесты НЕ ВХОДИТ тестирование корректности работы драйверов с железом! Только корректность взаимодействия драйвера и подсистем Windows. Прохожение WHQL-сертификации не подразумевает выявление ошибок в коде драйвера как таковых.

>> Драйвера, идущие вместе с ОС, обычно тестируют лучше прочих,
> Малозаметно. Во всяком случае, у висты/семерки с этим предостаточно проблем.

Я так понимаю, ваш пример ниже, там и ответ. И всё-таки перечитайте, что я написал выше: за эти драйвера отвечает производитель. Можете выставить претензии MS, что они должны тестировать поставляемые производителем драйвера на всё выпускаемое этим же производителем железо...

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

!"№;%:? Какое отношение имеет интеловский драйвер к самой ОС? Вы б ещё на винду за некачественные прошивки для каких-нибудь вайфай-карточек, идущих с этими драйверами, наехали.

>> Сбой в драйвере - практически всегда оказывается на совести его разработчика.
> Я уже заметил - не важно что и где случается, майкрософт никогда
> не виноват. Интересно, а вот по поводу такого бага http://support.microsoft.com/kb/2249857
> вы их сможете отмазать? В баге который разносит на куски файловую
> систему на диске - тоже сторонние производители виноваты? :)

Ничего хорошего я там не вижу. Чего вы от меня ждали-то? Почему я должен отмазывать винду? Потому что вы сочли меня фанатом винды?

И снова: какое отношение это имеет к видеодрайверам?

>> Родные драйвера MS - это, например, драйвер SCSI-контроллера. Который взаимодействует
>> с т.н. драйвером минипорта. Который в свою очередь уже предоставляется обычно
>> производителем контроллера.
> Да, вон там повыше пример для родных драйверов и утилит майкрософта. При
> записи крешдампа на том более 2Тб том оказывается попросту угроблен и
> не восстанавливается простыми методами - вместо файловой системы вермишель получается.
> Очень интересно как вы отмажете MS в этот раз.

Отмазывайте сами, если это вам так нужно. К драйверам видеокарт и вообще железа приведённый вами пример не имеет никакого отношения.

>> MS и Windows - мишени крупные, промахнуться сложно. Но вы всё же
>> умудрились это сделать. :)
> Мы добавим, нам не сложно.

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

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

1. Строго говоря, не диск, а раздел. 2. Никто не просит доверять. Речь шла о том, кто несёт ответственность за кривые драйвера на видеокарты и вообще железо. Вы почему-то начали утверждать, что MS, хотя MS как раз имеет мало отношения к данным случаям.

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

Баги есть у всех. У Windows, у Linux, у *BSD и у FreeRTOS.

>> Упреждая вопрос, откуда я, опёнковод с семилетним стажем, это знаю? Да просто
>> интересуюсь много чем. Кроме разве что 3D-игр...
> Спасибо за лишнее подтверждение того что пользватели BSD - это такие замаскированные
> под пенек виндузятники.

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

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

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

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

Ну и зачем вы это мне (и остальным) рассказываете-то?

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

Лучше б производители давали спеки разработчикам ОС, а не драйвера... Эх, мечты, мечты.

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

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

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

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

219. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Michael Shigorinemail (ok), 26-Июн-11, 21:38 
> Никто не мешает его ставить в винде. Более того, в винде есть
> RDP (сюрприз!), а также можно поставить VNC, RAdmin, NX...

Вроде бы речь шла про серверную часть -- удивился, заглянул на nomachine.com, NX-сервер под винду и макось продолжаю не наблюдать.


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

232. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 27-Июн-11, 08:17 
более того, в никсах тоже есть xrdp (это я про сервер).
И нормально работающие кстати. Даже могут кок прокси выступать для vnc и пр.
Ответить | Правка | Наверх | Cообщить модератору

180. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 24-Июн-11, 13:28 
а я не про это говорил. я хотел узнать, что значит «годно для продакшена». а то многие это словосочетание используют, а никто не может пояснить, что же оно значит. ну, кроме «трололо».
Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

197. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от PereresusNeVlezaetBuggyemail (ok), 25-Июн-11, 02:37 
> а я не про это говорил. я хотел узнать, что значит «годно
> для продакшена». а то многие это словосочетание используют, а никто не
> может пояснить, что же оно значит. ну, кроме «трололо».

У каждого свой продакшн, и своя правда. Nothing more, nothing less. :)

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

217. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Michael Shigorinemail (ok), 26-Июн-11, 20:13 
> а я не про это говорил. я хотел узнать, что значит «годно
> для продакшена».

О-оо.  Ну например, "жрёт ресурсы пачками, зато как-то принимает нагрузку".  Или вот "подпёрто monit".  И вообще подлежит административному решению проблем, включая технические.

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

*depends

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

225. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от anonymous (??), 27-Июн-11, 05:07 
> *depends

вот именно. потому вопрос «оно уже готово для продакшена» имеет смысл только если уточнять, что именно собираются делать, в каких объёмах и прочие необходимые условия. а просто для продакшена в вакууме… да, готово. ещё с пре-альфа-версии было готово. потому что я так считаю, и всё тут.

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

233. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от ананим (?), 27-Июн-11, 08:21 
вообще продакшн как и ынтырпрайз - слова сильно специфические. Из разряда что кто-то предоставляет коммерческую поддержку.
При этом факт наложения сотни патчей п заведения сотни запросов на поддержку никак (и никогда) не регламентировался.
Ответить | Правка | Наверх | Cообщить модератору

41. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +1 +/
Сообщение от iZEN (ok), 23-Июн-11, 16:28 
> Суровые парни. Этак скоро маны будут прямо в сорцы копипастить :)

JavaDoc видел? Это оно самое. ;)

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

187. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"  +/
Сообщение от Elhana (ok), 24-Июн-11, 16:31 
Зато там не будет ситуаций, когда вначале приходит патч в ядро "вот эта хрень с виду не нужна - выпилил", а потом его откатывают потому что оказалось нужно.  
Когда все не очевидное откомментировано, то таких проблем будет явно меньше.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

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




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

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