Здравствуйте, Antikrot, Вы писали:
N>>Наиболее грамотные производители сами отдают дрова, проверенные и вычищенные ими. В области сетевух, например, это Intel. Могут отдавать только спеки — 3Com, Tulip (DEC). A>как думаешь, почему это сделано для сетевух, и не сделано для скажем hiend видюх?
Даже не хочу гадать. Если у тебя это риторический вопрос — ответь сюда сам:)) Я же ни одной внятной причины не вижу. Всё, что могло составлять какой-то коммерческий секрет, обычно давно запатентовано.
N>>Если подход виндового стиля, драйвер поступает вместе с железякой. Так можно делать и для свободных ОС, примеры есть. A>совсем недавно была ссылка(на одного из мейнтейнеров, не последний человек в линухе): A>
A>You think you want a stable kernel interface, but you really do not, and
A>you don't even know it. What you want is a stable running driver, and
A>you get that only if your driver is in the main kernel tree. You also
A>get lots of other good benefits if your driver is in the main kernel
A>tree, all of which has made Linux into such a strong, stable, and mature
A>operating system which is the reason you are using it in the first
A>place.
A>видишь какое дело — несовместимость с идеологией...
Я не вижу здесь никакой несовместимости. Если пришла новая железка, которая удовлетворяет тому же драйверу, достаточно переделать трансляцию device ID в ссылку на драйвер. Если что-то меняется, но покрыто старым кодом, можно применить корректировочные указания. Если же новое вообще не покрывается старым кодом, то оно не покрывалось бы независимо от того, где разработан драйвер — в ядре или отдельно.
Здравствуйте, jazzer, Вы писали:
J>>>Но вообще шаблонное метапрограммирование существует уже не один год, можно было уже и пофиксить. N>>Очевидно, до последнего времени она не стояла так остро — тенденции такого жестокого использования появились уже в основном вместе с новым boost'ом, AFAIK. J>C новым бустом — это с каким?
Не знаю, я его обычно только в ldd чужих программ вижу. Но если раньше не было причин лечить, значит, что-то поменялось только пару лет назад.
N>>Очень просто: -Wextra включает список совершенно конкретных варнингов и они должны быть все описаны, так что назвать конкретное название. J>хорошо, какое конкретное название у варнинга про неполный список инициализации агрегата?
Назови версию GCC, пороюсь.
J>Но даже если бы она и была, это жа маразм — давать именную опцию на каждый варнинг! J>А если они решат еще 20 варнингов добавить — это что, они добавят еще 20 опций? J>Ну это же ужас, в них там уже черт ногу сломит, как там эти опции совокупляются в разных позах...
Опции варнингов никак не "совокупляются". Есть только два групповых регулятора — -Wall и -Wextra (он же -W для совместимости). Остальное по отдельности.
J>>>То же касается еще некоторых групповых варнингов, типа -Wabi. N>>В этом случае его не было причин делить на отдельные пункты. J>Ну само собой.
Если это сарказм, то замечу, что проблема, что делать, а что нет, строится у любого ПО на том, что попросили.:) Видимо, мало кто такое просил.
Здравствуйте, netch80, Вы писали:
J>>>>Но вообще шаблонное метапрограммирование существует уже не один год, можно было уже и пофиксить. N>>>Очевидно, до последнего времени она не стояла так остро — тенденции такого жестокого использования появились уже в основном вместе с новым boost'ом, AFAIK. J>>C новым бустом — это с каким?
N>Не знаю, я его обычно только в ldd чужих программ вижу. Но если раньше не было причин лечить, значит, что-то поменялось только пару лет назад.
Ну так ldd это пофиг, речь о тормозах во время выпекания объектника, а не во время линковки
N>>>Очень просто: -Wextra включает список совершенно конкретных варнингов и они должны быть все описаны, так что назвать конкретное название. J>>хорошо, какое конкретное название у варнинга про неполный список инициализации агрегата? N>Назови версию GCC, пороюсь.
ну у меня это 3.4.6.
J>>Но даже если бы она и была, это жа маразм — давать именную опцию на каждый варнинг! J>>А если они решат еще 20 варнингов добавить — это что, они добавят еще 20 опций? J>>Ну это же ужас, в них там уже черт ногу сломит, как там эти опции совокупляются в разных позах...
N>Опции варнингов никак не "совокупляются". Есть только два групповых регулятора — -Wall и -Wextra (он же -W для совместимости). Остальное по отдельности.
Но это же не отдельные группы изолированных опций, там опции влияют друг на друга.
Например, -Wsystem-headers ведет себя по-разному в зависимости от -Wall и -Wunknown-pragmas.
Или вот, например, цитата из мана:
-Wunused-parameter
Warn whenever a function parameter is unused aside from its declaration.
....
-Wunused All the above -Wunused options combined.
In order to get a warning about an unused function parameter, you must either specify -Wextra -Wunused (note that -Wall implies -Wunused), or separately specify -Wunused-parameter
Ну и к чему тогда All, если на самом деле не All и надо упоминать явно либо использовать дополнительно -Wextra ?
J>>>>То же касается еще некоторых групповых варнингов, типа -Wabi. N>>>В этом случае его не было причин делить на отдельные пункты. J>>Ну само собой.
N>Если это сарказм, то замечу, что проблема, что делать, а что нет, строится у любого ПО на том, что попросили. Видимо, мало кто такое просил.
Всё так, только вот если бы изначально сделали как в мелкософте, по номерам, то и проблем таких не возникало бы, просто потому что не пришлось бы рожать по опции на каждый варнинг, как сейчас, а был бы единый унифицированный интерфейс для управления варнингами. Это ошибка дизайна, а не просто "не попросили", потому что в случае мелкософта и просить ничего не надо, вопрос так вообще не стоит.
Плюс, ЕМНИП в мелкософте можно включать/выключать прагмы через push/pop, восстанавливая старое значение, gcc вроде так не умеет.
Здравствуйте, netch80, Вы писали:
N>>>Скорость и память компиляции — фактор обычно очень мало значимый.
Для тех, кто сидит на одной платформе (а это большинство внутренних проектов в компаниях) — очень даже значимый.
Потому что компании стараются не генерить без нужды зоопарк платформ, и юзают какую-то одну, максимум две.
N>>>Значительно важнее, например, то, что работа по переносу gcc на доселе неизвестную платформу — один человеко-месяц.
J>>Это ты говоришь про back-end, а тормозит front-end, который ну никак не зависит от количества платформ, поддерживаемых back-end-ом. J>>На back-end никто и не нападает, вроде.
N>Ну, во-первых, мне странно разделять их в этом контекте. Они же не поставляются раздельно? Конечно, при определённых усилиях можно одну из этих частей заменить (как в гибриде gcc frontend + LLVM, на котором в основном испытывался LLVM). Но мало кто на сейчас так делает, и особенно мало — делает сам.
Просто это практически независимые части, и то, что back-end написан хорошо и расширяемо и позволяет добавить новую платорму за месяц, не извиняет ситуации с frontend-ом, в котором проще повеситься, чем вносить изменения или не дай бог изменять внутренние структуры или добавлять фичи.
Я имел удовольствие смотреть в код фронтэнда, мне пришлось потом чинить себя пивом.
Более того, сами гццшники признают, что у них там кошмарный ужас, и переписывают фронтэнд на С++.
N>Во-вторых. Ты говоришь про те тормоза, которые ты упоминал, или абстрактные тормоза имени КБ? Твои — да, frontend. Но когда говорят что "gcc тормозит и жрёт" независимо от экстремальных ситуаций типа "дофига шаблонов", то речь уже AFAIU про уровень, когда прошла первичная кодогенерация и начинаются оптимизации. В зависимости от настроек там может очень много тратиться.
Не знаю, что такое КБ, я говорю именно про тормоза с инстанцированием шаблонов, это фронтэнд.
90% шаблонов в шаблонном метапрограммировании обычно вообще никакого реального кода для генерации не имеют, там вся работа на уровне системы типов идет (т.е. просто пустые структуры с кучей тайпдефов). Так что кодогенерация тут ни при чем.
Ну и я не сказал бы, что "дофига шаблонов" — это экстремальная ситуация, для нормального С++-проекта это нормальная ситуация.
N>Практически все остальные компиляторы относятся к оптимизации по умолчанию более мягко — код без оптимизации далеко не идеален, но это просто последовательное переложение действий из исходника, а не каких-то внутренних расчётов, кто на ком стоял и почему.
+1
Товарищи из Clang тоже ругаются на излишнее количество приседаний во фронтэнде.
S>Поддерживают — точно мало, плавно переходящее в очень мало.
GRUB, GIMP, GNOME, ntfs-3g, fuse, etc, etc, etc
S>Практически, по возможности стоит класть в коробку или печатать на ней то, что работает. Иначе с дерьмом смешают, не посмотрев на third party bullshit.
Да ладно. Видел я такие надписи, никого это не смутило. А вообще-то можно и не печатать ничего на коробке, вообще-то.
J>Сравнивается именно скорость и потребление памяти фронт-энда.
ОК. Я же не спорю. Я вообще-то никогда ничего большого gcc не компилировал. Просто пытаюсь поддержать уровень дискуссии.
J>только он при превышении определенного значения приводит к дополнительным тормозам из-за постоянного свопа.
Я разбалован ситуацией, когда памяти на борту больше, чем объем максиммально адресуемого пространства для 32битного приложения.
Да здравствует мыло душистое и веревка пушистая.
Re[14]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Vamp, Вы писали:
IID>>До семёрок была Vista + XP, до висты Win2k3 + XP. На них ни одного вируса тоже не было. ЧЯДНТ ? V>Врешь, вот что ты делаешь не так. V>У меня на ХР вирус с флешки схватился, потому что по умолчанию на съемных носителях включен автозапуск. И кстати, чтобы отключить его в ХР, надо лезть в реестр.
Мне всегда казалось, что он есть в GPO для Local Machine.
