forum.opennet.ru

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

Оглавление

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

Проблема только в том что у XFS строк уже больше, а у btrfs фичность как-то побо, Аноним (-), 12:28 , 23-Июн-11, (1) +2 //

Ну вообще то генерация документации в т ч манов на основании соотв образом пре, klalafuda (?), 12:41 , 23-Июн-11, (4) +10 //

Правда вот такие мануалы обычно стойко навевают воспоминания о анекдоте моя ско, Аноним (-), 14:10 , 23-Июн-11, (14) –1 //

неа а вот такие коментари уж точно навевают мысли о быдлокодере признайся сразу, ананим (?), 17:01 , 23-Июн-11, (46)

А тут надо помнить, что административные проблемы не решаются техническими средс, fr0ster (ok), 17:12 , 23-Июн-11, (50) –1

Э-э-э-э О чём Вы Комментарии к коду - не административная проблема, а техниче, ананим (?), 17:19 , 23-Июн-11, (54) –1

зыжайзен жабадок снизу уже привёл в качестве доказательства А я даже добавлю -, ананим (?), 17:26 , 23-Июн-11, (58) +1

Я с этим столкнулся не на жабе а на абапе, но вот привычка комментить чуть ли не, fr0ster (ok), 17:32 , 23-Июн-11, (62)

если каментить надо каждый чих 8212 то это быдлокод нормальный код отлично ч, anonymous (??), 22:21 , 23-Июн-11, (102) –2

Техническая это использовать Доксиген или еще чтото для документирования, а треб, fr0ster (ok), 17:26 , 23-Июн-11, (59)

ну дык и я о чём Важно не путать проблемы со средствами хорошо документированный, ананим (?), 17:40 , 23-Июн-11, (65)

Хорошо документированный код это вообще не проблема Плохое документирование техн, fr0ster (ok), 18:01 , 23-Июн-11, (74)

фиг там Административная она до тех пор, пока кода мало, а тот кто его написал е, ананим (?), 18:32 , 23-Июн-11, (81)

Это всегда административная проблема Если руководитель допустил завязанность пр, fr0ster (ok), 21:43 , 23-Июн-11, (99) –1

эх, молодо-зелено Через дцать лет любой проект завязан на одного человека Д, ананим (?), 03:33 , 24-Июн-11, (134)
какие в попу сейчас госконторы тут вон Путин возмущался что в приморье таможню у, ананим (?), 11:02 , 24-Июн-11, (157)

Признаюсь в том что автоматически сгенеренная документация - как правило такой ж, Аноним (-), 17:22 , 23-Июн-11, (56)

http wiki lustre org lid subsystem-map subsystem-map htmlвот документация кото, Аноним (-), 17:31 , 23-Июн-11, (61)

Да как сказать Фифти-фифти Врубиться по этой доке в принципе можно Но читать , Аноним (-), 18:05 , 23-Июн-11, (75)

Вообще говоря дока автоматом сгенерированная из нормально написанных комментарие, fr0ster (ok), 18:11 , 23-Июн-11, (77)

Честно говоря, сырцы и коменты в них я могу почитать и без тупых автогенераторов, Аноним (-), 01:21 , 24-Июн-11, (126)

авторы Qt удивлены , anonymous (??), 01:28 , 24-Июн-11, (128)

Они не умеют использовать grep , Аноним (-), 12:19 , 24-Июн-11, (165)

Автоматически генерируемая документация полезна при использовании библиотек, так, PereresusNeVlezaetBuggy (ok), 21:33 , 23-Июн-11, (98) +2

верно Но так же верно, что вставить в нужное место свой коммент забывают уж о, ананим (?), 17:34 , 23-Июн-11, (63)

Да не только быдло, вон там человек в общем то по делу подпинывает btrfs ников з, Аноним (-), 18:23 , 23-Июн-11, (79)

оставлю это на его совести Dа нахрена Разрабам ФС на это покласть, а от нови, ананим (?), 18:43 , 23-Июн-11, (83)

Думаю у него совесть чиста - он в вопросе разбирается Нафига Чтобы был ман дающ, Аноним (-), 23:28 , 24-Июн-11, (189)

За счёт комментариев Строго говоря, Вы правы, но самому не смешно ли Нет уж, у, Michael Shigorin (ok), 21:25 , 26-Июн-11, (218)

Открой для себя нормальные IDE со сворачиваемым фолдингом участков комментариев , iZEN (ok), 19:03 , 23-Июн-11, (84)

О, как это в стиле жабистов сначала создать себе проблем, а потом их героически, Аноним (-), 01:27 , 24-Июн-11, (127)

Преждевременные оптимизации вредны Сначала пишем код 8212 потом оптимизируем, iZEN (ok), 01:38 , 24-Июн-11, (130) –1

это был пример рассуждений типичного быдлокодера ну и что, что у вас техника б, anonymous (??), 01:42 , 24-Июн-11, (131) +2

К сожалению писать качественный код стало экономически не выгодно Зачастую прощ, kshetragia (ok), 05:46 , 24-Июн-11, (139)
как язык 8212 да а вот по поводу инструментария 8212 не согласен его пон, anonymous (??), 08:15 , 24-Июн-11, (140)
писец Можно подумать С и С запрещают писать комменты по стандарту доксигенов И, ананим (?), 11:07 , 24-Июн-11, (158)
LSE с вами не согласны , Аноним (-), 23:29 , 24-Июн-11, (190)
Ит с эн оверстэйтмент, мэн http lwn net Articles 443775 , Michael Shigorin (ok), 19:04 , 26-Июн-11, (216)

Да, конечно, сперва делаем, потом думаем Хотя немного подумав заранее, можно из, Аноним (-), 12:29 , 24-Июн-11, (166)

он даже про valgrind не знает, потому что для его жабы оно бесполезно а если в , anonymous (??), 13:25 , 24-Июн-11, (179)
У него наверное даже ума собрать статистику сисколов strace ом не хватит - такие, Аноним (-), 23:35 , 24-Июн-11, (191)

Для нормального кода IDE не нужен Он должен быть интуитивно понятен Где непоня, kshetragia (ok), 05:42 , 24-Июн-11, (138)

это совершенно не важно да и 8212 что значит 171 как реально выглядит 187, anonymous (??), 08:19 , 24-Июн-11, (141)

Смешались в кучу кони, люди и получилась хрень на блюде , Аноним (-), 12:30 , 24-Июн-11, (167)

сразу видно Анонимного Эксперта, который не по наслышке знаком с системой Оберон, anonymous (??), 13:15 , 24-Июн-11, (176)
Судя по повсеместному распостранению Оберона не так уж эксперт и неправ , Аноним (-), 18:37 , 25-Июн-11, (203)
Система отличная, но малораспространенная Пока же приходится смотреть на реализ, kshetragia (ok), 07:07 , 27-Июн-11, (227)
в принципе, BlackBox Component Builder открыт вроде как даже уже есть порт ядра, anonymous (??), 07:22 , 27-Июн-11, (229)
действительно мелочь , kshetragia (ok), 14:24 , 27-Июн-11, (235)
на крайний случай есть winelib убегает, увёртываясь от булыжников , anonymous (??), 16:13 , 27-Июн-11, (237)

Как только появится свободная реализация в исходниках под Unix И не Оберона, а , kshetragia (ok), 07:06 , 27-Июн-11, (226)

BlackBox Component Builder я, кстати, после открытия кода отрывал компилятор от, anonymous (??), 07:25 , 27-Июн-11, (230)

Это значит, что я должен быть в состоянии прочитать код без IDE костылей И его , kshetragia (ok), 07:15 , 27-Июн-11, (228)

у оберона вообще с понятием 171 файл 187 некоторая напряжёнка они, вроде бы, anonymous (??), 07:30 , 27-Июн-11, (231)

документация к Qt генерится из исходников лучше документации я пока не видел, д, anonymous (??), 22:42 , 23-Июн-11, (103) +1
На то и посажен кодер , а на пккодер , maginoid (ok), 20:30 , 30-Июл-14, (239)

Нуну, и что, неужели btrfs уже годна для продакшена Фичи-фичами, а главное - ста, anon8 (ok), 13:02 , 23-Июн-11, (6) //

А еще пряморукость Я полностью согласен в отношении с Btrfs с Эдуардом Шишкины, BratSinot (?), 13:42 , 23-Июн-11, (8) //

Предложения, алтернативы , koblin (ok), 14:17 , 23-Июн-11, (17) +1
У Шишкина было какое-то очень предвзятое мнение, наверное потому что он разработ, Аноним (-), 14:32 , 23-Июн-11, (19) +3

плевались как раз авторы btrfs, Аноним (-), 15:12 , 23-Июн-11, (24)

Да они там на пару плевались, но в результате - тюнинг твикинг все-таки был Спа, Аноним (-), 15:21 , 23-Июн-11, (27) +1

Файловая система должна работать с любыми данными Если заявила отсутствие огран, Михаил (??), 15:35 , 23-Июн-11, (35) +1

У них раньше было ограничение прямо в утилитах - они посылали при попытке создат, Аноним (-), 17:43 , 23-Июн-11, (67) +2

Еще не годна Но неотвратимо приближается к этому моменту В продакшне Разумеет, Аноним (-), 14:14 , 23-Июн-11, (16) +1
что значат эти слова винда вон нестабильна даже при штатном использовании без х, anonymous (??), 22:54 , 23-Июн-11, (105) //

Винда стабильна или нестабильна при штатном использовании точно так же, как люба, PereresusNeVlezaetBuggy (ok), 23:10 , 23-Июн-11, (108)

Да какой там бубен, если видеодрайвера падают Ты или пользуешься футуристичной , Аноним (-), 12:33 , 24-Июн-11, (168)

Видеокарты нормальные используйте Или кроме ATI AMD и NVIDIA других названий , PereresusNeVlezaetBuggy (ok), 13:54 , 24-Июн-11, (183)

Почему же, знаем встроенные в интелские чипсеты еще Вообще тормозная гадость С, Аноним (-), 00:12 , 25-Июн-11, (193)

Второй ноутбук с Intel ом на борту В винде проблем нет вообще В X org есть неб, PereresusNeVlezaetBuggy (ok), 02:34 , 25-Июн-11, (196)

Не знаю как там у вас нет проблем, а я регулярно наталкиваюсь на взвисы семерок , Аноним (-), 19:33 , 25-Июн-11, (204)

Ну так не используйте Intel В чём проблема Вы что, решили, что я вас агитирую , PereresusNeVlezaetBuggy (ok), 00:41 , 26-Июн-11, (212)

Вроде бы речь шла про серверную часть -- удивился, заглянул на nomachine com, NX, Michael Shigorin (ok), 21:38 , 26-Июн-11, (219)

более того, в никсах тоже есть xrdp это я про сервер И нормально работающие кс, ананим (?), 08:17 , 27-Июн-11, (232)

а я не про это говорил я хотел узнать, что значит 171 годно для продакшена 1, anonymous (??), 13:28 , 24-Июн-11, (180)

У каждого свой продакшн, и своя правда Nothing more, nothing less , PereresusNeVlezaetBuggy (ok), 02:37 , 25-Июн-11, (197)
О-оо Ну например, жрёт ресурсы пачками, зато как-то принимает нагрузку Или, Michael Shigorin (ok), 20:13 , 26-Июн-11, (217)

вот именно потому вопрос 171 оно уже готово для продакшена 187 имеет смысл , anonymous (??), 05:07 , 27-Июн-11, (225)

вообще продакшн как и ынтырпрайз - слова сильно специфические Из разряда что кт, ананим (?), 08:21 , 27-Июн-11, (233)

JavaDoc видел Это оно самое , iZEN (ok), 16:28 , 23-Июн-11, (41) +1
Зато там не будет ситуаций, когда вначале приходит патч в ядро вот эта хрень с , Elhana (ok), 16:31 , 24-Июн-11, (187)

так и правельно делают, чем лучше исходники снабжены коментами, тем легче искать, Битазавр (?), 12:33 , 23-Июн-11, (2) +2 //

Если есть необходимость комментировать код, то значит этот код плохо написан и е, пельмешка (?), 13:58 , 23-Июн-11, (9) –16 //

Сам, то писал хоть раз Суровый челябинский кодер Если код не документирован, Зилибоба (ok), 14:09 , 23-Июн-11, (13) +1 //

Не челябинский кодер, а архуский Дания Это мнение про комментарии принадлежит, пельмешка (?), 14:33 , 23-Июн-11, (20)

Цитата так же точна, как напев Желтой Субмарины Абрамом по телефону С Что собств, fr0ster (ok), 15:28 , 23-Июн-11, (31) +1
Ну и шут с ним и его великом -- если гура до седины в бороде дожил, а не осозн, Michael Shigorin (ok), 15:30 , 23-Июн-11, (33)

Ой, вот таки не надо сразу гуру дураком делать Сначала посмотрите насколько , fr0ster (ok), 15:32 , 23-Июн-11, (34)

if а с выражениями действительно надо осторожней -- мало ли кто как поймёт , Michael Shigorin (ok), 15:35 , 23-Июн-11, (36)

лично я даже и не думал, что выссказывание Страуструпа о необходимости писать ко, ананим (?), 17:48 , 23-Июн-11, (69)

а вот тут начинает не зватать терминов комментировать перед функцией 8212 вх, anonymous (??), 23:08 , 23-Июн-11, (107)

от быдло-кодера слышу Этож писец Теперь что и в структурах не писать какие зна, ананим (?), 03:45 , 24-Июн-11, (135)

В идеальном случае код должен быть написан так чтобы коментов не требовалось В , Аноним (-), 14:41 , 23-Июн-11, (21)

Просто Вы не видели реализацию сложных алгоритмов или структур данных , Аноним (-), 15:15 , 23-Июн-11, (25)

Почему же, видел Просто если хочется что-то именно фундаментально задокументиро, Аноним (-), 15:22 , 23-Июн-11, (28)

Затем, что в какой то момент вы рискуете вместо пояснения темных мест реализации, fr0ster (ok), 15:30 , 23-Июн-11, (32) +2

Если код пишут товарисчи с таким подходом - им лучше всего вообще не пользоватьс, Аноним (-), 18:28 , 23-Июн-11, (80)

Лучше то лучше, но иногда выбор небогат Здесь Родос, здесь и прыгай , fr0ster (ok), 20:49 , 23-Июн-11, (91)

Ну тогда прыгайте, чо Только так и убиться можно Умные люди обычно стараются п, Аноним (-), 01:32 , 24-Июн-11, (129)

Вот умные люди и комментируют свой код Буквально каждый чих Что бы потом не вспо, fr0ster (??), 13:36 , 24-Июн-11, (181)

если это надо специально вспоминать, то это называется 171 хак 187 хаки, ко, anonymous (??), 13:41 , 24-Июн-11, (182)
Это не хак, это требования контролирующих органов Ну вот положено считать так, , fr0ster (??), 15:04 , 24-Июн-11, (184)
по-моему, ты только что описал грязный хак , anonymous (??), 15:12 , 24-Июн-11, (185)

Чтобы не было рассинхронизации документации и кода , segoon (ok), 16:23 , 23-Июн-11, (39) +2

ты риальне веришь, что при наличии этого в одном файле вероятность десинка меньш, anonymous (??), 23:16 , 23-Июн-11, (109) –4

по исходникам, хорошо и грамотно документированым, как раз и делают документацию, mealstrom (?), 12:40 , 23-Июн-11, (3) +1
А ширину строк учли, интересно , Дмитрий (??), 12:50 , 23-Июн-11, (5) //

в таком случае -- вообще лучше сравнивать количество токенов слов и разделяющих, Аноним123321 (ok), 13:42 , 23-Июн-11, (7)

Имхо, это плохо говорит о ядре Код не реюзается, а содержит много дубликатов , crypt (??), 14:07 , 23-Июн-11, (11) +1 //

Это говорит о том, что еще оптимизировать и оптимизировать Тоесть - графики мог, Зилибоба (ok), 14:10 , 23-Июн-11, (15)
Большой вопрос станет ли эффективнее если каждую строку выносить в функцию и пот, Аноним (-), 15:26 , 23-Июн-11, (30) –2 //

Откройте для себя inline-функции , kibab (?), 15:50 , 23-Июн-11, (37) //

Да Давайте сделаем каждую строку программы отдельной инлайн-функцией Извращать, Аноним (-), 17:46 , 23-Июн-11, (68)

code const static inline volatile unsigned char __attribute__ always_inline , pavlinux (ok), 00:23 , 24-Июн-11, (117) +2

Ты уже заблудился P , Аноним (-), 01:45 , 24-Июн-11, (132) +2

Угу В одном коде везде написано 171 for i 0 i sz i 187 , а в друго, PereresusNeVlezaetBuggy (ok), 16:54 , 23-Июн-11, (45)

Пути графиков сойдутся на 50тыс срок , zamir (??), 14:08 , 23-Июн-11, (12) +1
Статья из серии Занимательная фалометрия для Чайников или как создать срач на р, ImPressed (ok), 14:28 , 23-Июн-11, (18) +5 //

Чем больше код, тем больше ошибок Чем меньше комментариев, тем сложнее его подде, Аноним (-), 15:19 , 23-Июн-11, (26) //

С другой стороны и при минимуме кода бывают интересные ошибки Думали код времен, fr0ster (ok), 17:04 , 23-Июн-11, (48) //

Бываают, но мистер D J Berstein делом доказал что это отличный способ минимизац, Аноним (-), 12:41 , 24-Июн-11, (169)

Чем меньше _полезных_ комментариев И чем больше бесполезных Индусское комменти, PereresusNeVlezaetBuggy (ok), 17:07 , 23-Июн-11, (49) +2 //

Маразм, но иногда алгоритм не так прозрачен, как кажется возьмите алгоритм окру, fr0ster (ok), 17:18 , 23-Июн-11, (53)

Я и не спорю, что иногда это, к сожалению, нужно Речь была как раз о том, что в, PereresusNeVlezaetBuggy (ok), 17:21 , 23-Июн-11, (55) +1

Жаль только тривиальные случаи это вовремя не обнаруженные необычности Индусский, fr0ster (ok), 17:29 , 23-Июн-11, (60) +1

Дык на то голова программисту и дана, чтобы отличать одно от другого Чем прощ, PereresusNeVlezaetBuggy (ok), 17:34 , 23-Июн-11, (64) +1

Если архитектура запутанна, то медицина бессильна Весь код не может быть ясным , fr0ster (ok), 17:42 , 23-Июн-11, (66)

Дык вы ж сами и привели примеры, когда внешние обстоятельства заставляют городит, PereresusNeVlezaetBuggy (ok), 21:23 , 23-Июн-11, (97)

Как можно сравнивать прирост кода в старой 2001 XFS, с ее устоявшейся базой И , Sokoloff (?), 14:51 , 23-Июн-11, (23) //

Форониксу - можно , Аноним (-), 15:23 , 23-Июн-11, (29) +4

крайний раз копался в коде btrfs с год назад, откомментирован он действительно о, fresco (ok), 15:59 , 23-Июн-11, (38) //

Есть такой грешок за ними, факт С другой стороны когда 40 исходника это комент, Аноним (-), 17:49 , 23-Июн-11, (70) //

много -- не мало, процентов 35, по опыту, в самый раз , fresco (ok), 21:48 , 23-Июн-11, (100) +1

Дедупликация ZFS уменьшит занимаемое ими место , iZEN (ok), 16:26 , 23-Июн-11, (40) //

Неа Дедупликация ZFS действует только на блоки Очевидно, даже несколько идущих, Аноним (-), 17:12 , 23-Июн-11, (51) //

это всё потому, что есть куча народу гордящегося_неимоверно новой цацкой, а не, ананим (?), 17:53 , 23-Июн-11, (71) –1
И давно она там есть Какой командой делается Ах, в виде патчей , Anon Y Mous (?), 09:15 , 24-Июн-11, (146)

Сапожник Дедупликация ZFS не оперирует строками, она дисковыми блоками оперируе, Аноним (-), 17:54 , 23-Июн-11, (72) –2 //

Что же с вами случилось, люуууудиии Сарказм уже воспринимают как личный наезд , iZEN (ok), 19:58 , 23-Июн-11, (87) –3 //

Уж извини, не слежу за темой, но видать, заслужил ты имидж среди местного народа, crypt (??), 21:10 , 23-Июн-11, (94) +1

Да, кстати, был же этот товарищь от M со звучной фамилией Тот был еще прово, crypt (??), 21:14 , 23-Июн-11, (95)
не только среди местного , anonymous (??), 23:47 , 23-Июн-11, (111) +1

iZEN умудряется сливать сразу на многих ресурсах, будучи наглядной иллюстрацией , Аноним (-), 12:46 , 24-Июн-11, (172) +1

пора тэг irony вводить, а то так понимать перестали , fresco (ok), 21:51 , 23-Июн-11, (101) +2

поратолько без поиска от витеньки, йопт (??), 11:12 , 24-Июн-11, (160)
iZEN слишком толстый, ему этот тег не засчитают , Аноним (-), 12:47 , 24-Июн-11, (173)

Инфляция , gegMOPO4 (ok), 22:52 , 23-Июн-11, (104) +1

Кто-нибудь в жизни её использует А то уж очень хочется неограниченного количест, IamthinkingaboutBTRFS (?), 16:41 , 23-Июн-11, (43) –1 //

http ru wikipedia org wiki NILFS, iZEN (ok), 16:47 , 23-Июн-11, (44) +1
ZFS уже давно портировали на линакс, между прочим , Аноним (-), 17:13 , 23-Июн-11, (52) +1
Использую на нетбуке с 64 GB SSD с выхода убунты 10 10 по текущий момент Нескол, Frank (ok), 17:23 , 23-Июн-11, (57)
Пробовал btrfs начиная с Ubuntu 10 10 с последующим апдейтом до 11 04, причем ос, Алексей Волков (?), 18:10 , 23-Июн-11, (76) +2 //

Только если что - у zfs вообще fsck нет, даже в планах А у btrfs он пока поп, Аноним (-), 18:40 , 23-Июн-11, (82) –2 //

zpool scrub poolname 8212 рассчитывает все контрольные суммы файлов и метадан, iZEN (ok), 19:08 , 23-Июн-11, (86) –1

Все это замечательно, но убитые метаданные не восстановит Так что действительно, Аноним (-), 20:37 , 23-Июн-11, (89)

Там оно и не нужно CoW, контрольные суммы и дублирование метаданных решают, а б, Мяут (ok), 23:49 , 23-Июн-11, (113) –1

адептам свойственно говорить, что то, чего у них в технологии нет, на самом деле, anonymous (??), 23:56 , 23-Июн-11, (114)

ZFS изначально проектировался, как надежная ФС, для которой бы не требовался fsc, Мяут (ok), 00:06 , 24-Июн-11, (115)

дык можно подумать, что та же винда изначально проектировалась как система, кот, anonymous (??), 00:09 , 24-Июн-11, (116)

Ну есть zdb если на то уж пошло А все фичи fsck типа определения сбойной ФС в Z, Мяут (ok), 00:47 , 24-Июн-11, (118)

Он может проверить все структуры на валидность и починить все что невалидно или , Аноним (-), 20:31 , 25-Июн-11, (206)

http www freebsd org cgi man cgi query zdbТо только эта цепочка и будет недост, iZEN (ok), 20:58 , 25-Июн-11, (207)
Можно вот рассказать, как это могло получиться, со ссылочками на on-disk format , Мяут (ok), 01:39 , 27-Июн-11, (221)

Да-да Сколько было излито желчи по поводу того, что ZFS - комбайн-все-в-одном-, Anon Y Mous (?), 09:19 , 24-Июн-11, (147)

Желчь была в основном потому что ZFSники утверждали что оно такое незаменимое Хо, Аноним (-), 00:26 , 25-Июн-11, (195)

От 2005 года данные, когда исходники ZFS открыли Сейчас количество строк кода в, Anon Y Mous (?), 09:23 , 24-Июн-11, (148)
Ага, вот вылезет у вас бэд так что ФС перестанет монтироваться, бэкап фигакс и с, Аноним (-), 00:18 , 25-Июн-11, (194)

Это у вас бэд приводит к немонтируемой ФС, у нас 4 копии метки на VDEV и 3 копии, Мяут (ok), 01:44 , 27-Июн-11, (222)

А зачем ему что-то восстанавливать Сама ZFS спроектирована по принципу CoW 82, iZEN (ok), 00:56 , 24-Июн-11, (120) +1

Малацца, основы CoW зазубрил Садись, пять И положи букварь на парту Только у , Аноним (-), 13:27 , 25-Июн-11, (198)

gt оверквотинг удален Матчасть подучи http blogs oracle com bonwick ru cate, iZEN (ok), 17:44 , 25-Июн-11, (202)

Это ты себе Как ты думаешь, к чему относилось про эффект домино CoW довольно ле, Аноним (-), 23:05 , 25-Июн-11, (208)

Наконец-то дошло Ты делаешь успехи А теперь прочти, что я написал РАНЕЕ про z, iZEN (ok), 00:44 , 26-Июн-11, (213)

Я -- да А Вы заканчивайте всё-таки свои чушебравады _Это_ как раз точно бессмы, Michael Shigorin (ok), 21:40 , 26-Июн-11, (220)
прежде чем что-то там восстанавливать пусть вначале на ней ПО нормально работать, ананим (?), 08:23 , 27-Июн-11, (234)

Включаешь либо избыточность по копиям параметром FS, либо делаешь зеркалирование, Аноним (-), 23:01 , 24-Июн-11, (188)

И какой командой мне сделать чтобы на моем ноуте у меня зазеркалировались все да, Аноним (-), 23:09 , 25-Июн-11, (209)

zfs set copies 2 tankДелает две копии данных и защищает от бедов, Мяут (ok), 01:49 , 27-Июн-11, (223)

конечно, не похоже унылые fsck традиционных ФС ещё и восстанавливать данные уме, anonymous (??), 23:49 , 23-Июн-11, (112)

Ага 8212 cкладывать горкой в lost-found неназванный мусор Чего ж до сих , iZEN (ok), 00:50 , 24-Июн-11, (119) –1

Проблема лишь в том что если все настолько плохо, том скорее всего совсем не смо, Аноним (-), 13:37 , 25-Июн-11, (199) +1

Да уж Унылый fsck по задумке еще и репайрит порушенные метаданные до более-мене, Аноним (-), 12:50 , 24-Июн-11, (174)

Увидь http compute cnr berkeley edu cgi-bin man-cgi zpool 1---zpool import -F, iZEN (ok), 15:51 , 24-Июн-11, (186)

И что в этой копипасте предлагается увидеть То что реализован аж целый один мет, Аноним (-), 13:42 , 25-Июн-11, (200)

Не поможет 8212 zdb в зубы и вперёд , iZEN (ok), 17:16 , 25-Июн-11, (201) –1

Лучше уж fsck, имхо Он большую часть типовых проблем чинит автоматически, а там, Аноним (-), 23:13 , 25-Июн-11, (210)

У него вопрос один Чинить или не чинить 8212 и то, файловую систему, а не, iZEN (ok), 07:58 , 26-Июн-11, (215)
Список типовых проблем, которые btrfsck чинит можно в студию А то как бы не ока, Anon Y Mous (?), 17:20 , 27-Июн-11, (238)

Да-да, ZFS нет никакой zfsc, а у btrfs есть А то, что этот чинящий что-то там b, Anon Y Mous (?), 09:29 , 24-Июн-11, (150) –1

Ну так научат, фигли Быстро только языком на форуме тарахтеть До тех пор никто, Аноним (-), 12:53 , 24-Июн-11, (175) +1

Странно Мне вот вот все равно, есть fsck или нет, ибо ее наличие дает разве чт, Anon Y Mous (?), 15:56 , 27-Июн-11, (236)

Кстати btrfsck уже научился исправлять ошибки , Аноним (-), 20:24 , 23-Июн-11, (88) +1
В этих 39 комментариев учтены стандартные заголовки файлов с указанием копирайт, gegMOPO4 (ok), 22:55 , 23-Июн-11, (106)

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

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 +/–

Сообщение от fr0ster (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 +/–

Сообщение от PereresusNeVlezaetBuggy (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 Shigorin (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" +/–

Сообщение от kshetragia (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 Shigorin (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" +/–

Сообщение от kshetragia (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" +/–

Сообщение от kshetragia (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" +/–

Сообщение от kshetragia (ok), 27-Июн-11, 14:24

действительно мелочь.

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

237. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS" +/–

Сообщение от anonymous (??), 27-Июн-11, 16:13

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

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

226. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS" +/–

Сообщение от kshetragia (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" +/–

Сообщение от kshetragia (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" +/–

Сообщение от maginoid (ok), 30-Июл-14, 20:30

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

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	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 +/–
	Сообщение от fr0ster (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 +/–
	Сообщение от PereresusNeVlezaetBuggy (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 Shigorin (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ообщить модератору