Здравствуйте, dr.Chaos, Вы писали:
DC>Много — не много, но когда я включил, что-то не порадовала меня отзывчивость хотя канал бизнес уровня. Да уж предвижу казнь над оригиналом включившим это на 2008 серваке . Ну хрен его. Я ж не на сервак хожу, а на личную машиу. Канал 5 мбит/сек — однако, пинг бывает достаточно большим.
Re[31]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Константин Б., Вы писали:
MC>>>Здравствуйте, Константин Б., Вы писали: КБ>>>>Да я знаком с идеологией. Я просто утверждаю что с этой идеологией линукс так и останется со своим 1%. MC>>>Для попадания десктопы к быд^W массам нужны маркетинговые, а не технические решения. Так что ты со своим процентофажеством, как обычно, мимо.
КБ>>Это ты опять мимио. Массы тут не причем. КБ>>Мне надо чтобы под линукс писали драйвера и ПО. Фотошоп вот хочу чтобы был под линуксом. Но всего этого не будет пока линукс будет так издеваться над 3rd party разработчиками.
N>Плохой пример. На сейчас абсолютно ничего не мешает лёгкому появлению фотошопа под все более-менее распространённые дистрибутивы: в нём нет такого, что требовало бы переделки под особенности другого дистрибутива. Надо просто поставить, собрать и получить результат. Код не меняется. Если кто-то этого не делает — это проблемы его лени. То же касается >95% других обычных приложений.
N>Я бы понял, если бы ты назвал что-то глубоко завязанное в систему... но тут — мимо кассы.
Т.е. ты предлагаешь пересобирать под каждый дистрибутив?
Re[48]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Константин Б., Вы писали:
КБ>>>Мне надо чтобы под линукс писали драйвера и ПО. Фотошоп вот хочу чтобы был под линуксом. Но всего этого не будет пока линукс будет так издеваться над 3rd party разработчиками.
N>>Плохой пример. На сейчас абсолютно ничего не мешает лёгкому появлению фотошопа под все более-менее распространённые дистрибутивы: в нём нет такого, что требовало бы переделки под особенности другого дистрибутива. Надо просто поставить, собрать и получить результат. Код не меняется. Если кто-то этого не делает — это проблемы его лени. То же касается >95% других обычных приложений.
N>>Я бы понял, если бы ты назвал что-то глубоко завязанное в систему... но тут — мимо кассы.
КБ>Т.е. ты предлагаешь пересобирать под каждый дистрибутив?
Не так. Во-первых, нативная сборка под два дистрибутива — RHEL и SuSE может покрыть >80% целевого рынка. Во-вторых, достаточно сборки под аппаратную архитектуру и формат библиотек, он у всех одинаков. Особенности дистрибутива выносятся в переходники реализации, которые тривиальны. У фотошопа это всё уже сделано, но подложки именно под Linux нет.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, netch80, Вы писали:
J>>>Это 2009 год, т.е. вполне современная версия гцц.
N>>Может, жалоба и правильна, но подход "2009 => современная" — нет. Без знания конкретной версии совершенно неизвестно, что именно они там вытащили и как. J>Интересно, почему это жалоба "может и правильна", если там конкретные детали и симптомы приведены. В чем сомнения?
Там даже версии gcc не названо. Впрочем, это можно списать на умолчание "все существующие сейчас".
N>>С другой стороны, это не тот вопрос, который требует существенной переделки: сделают вместо последовательного списка дерево с каким-то адекватным поиском и на этом проблема исчезнет. J>Ну если сделают — будет хорошо, кто ж спорит. J>Но вообще шаблонное метапрограммирование существует уже не один год, можно было уже и пофиксить.
Очевидно, до последнего времени она не стояла так остро — тенденции такого жестокого использования появились уже в основном вместе с новым boost'ом, AFAIK.
В любой сложной программе есть места, которые не оптимизировались, потому что на них не падала серьёзная нагрузка. Например, я не могу себе представить в реальной ситуации список каталогов для #include даже в сотню наименований, а тем более на тысячи. Но если вдруг у кого-то возникнет реальная необходимость в таком подходе — придётся ранее линейный поиск существенно оптимизировать.
N>>#pragma GCC diagnostic ignored "-Wformat" N>>пробовал? чего именно не хватает? J>Не хватает возможности заткнуть конкретный варнинг, не затрагивая остальных. J>В то время как, скажем, -Wextra рулит 20 варнингами в версии 3.4.6. И как мне заткнуть только один из 20?
Очень просто: -Wextra включает список совершенно конкретных варнингов и они должны быть все описаны, так что назвать конкретное название.
J>То же касается еще некоторых групповых варнингов, типа -Wabi.
В этом случае его не было причин делить на отдельные пункты.
The God is real, unless declared integer.
Re[45]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Константин Б., Вы писали: КБ>>Да я знаком с идеологией. Я просто утверждаю что с этой идеологией линукс так и останется со своим 1%. MC>Для попадания десктопы к быд^W массам нужны маркетинговые, а не технические решения. Так что ты со своим процентофажеством, как обычно, мимо. ;)
Может, в общем случае это и так, но не в этом. Любой маркетинг рано или поздно сталкивается с реальными фактами того, что под одну систему (как Windows) достаточно проверять корректность драйверов и прочей системной специфики не чаще раз в сервиспак (то есть, около раза в год на все активные ветки в сумме и не чаще раз в два года на каждую), а под другую (как Linux) — с каждым новым ядром — если нет смягчающей это прослойки в виде построителя дистрибутива, который берёт эту специфику на себя.
Всё сообщение Greg KH по сути сводится к одному — "потребности в колбасе нет потому, что мы постановили, что её нет". Более подробно — "нам неудобно обеспечивать здесь хоть какую-то устойчивость и мы решили не заморачиваться". Ещё один подтекст — "мы ценим производительность выше стабильности кода, поэтому убираем лишнее даже ради 0.5% экономии в редких случаях". То, что уже давно не нужно гнаться за голой скоростью, их тут не интересует.
И даже вариант организации веток с устойчивым ABI и временем активного существования в год-два их не интересует — проще ломать на месте, чем заботиться о существовании нескольких активных трейнов. Проблемы борьбы с этим всем переложены на авторов дистрибутивов, как будто тем больше делать нечего.
Здравствуйте, netch80, Вы писали:
J>>Но вообще шаблонное метапрограммирование существует уже не один год, можно было уже и пофиксить. N>Очевидно, до последнего времени она не стояла так остро — тенденции такого жестокого использования появились уже в основном вместе с новым boost'ом, AFAIK.
C новым бустом — это с каким?
книжка Александреску выпущена в 2001, книжка Гуртового-Абрахамса — в 2004
MPL в бусте с 2002 года, если не раньше (скорее всео раньше, потому что их статья про МПЛ вышла в 2002).
N>>>#pragma GCC diagnostic ignored "-Wformat" N>>>пробовал? чего именно не хватает? J>>Не хватает возможности заткнуть конкретный варнинг, не затрагивая остальных. J>>В то время как, скажем, -Wextra рулит 20 варнингами в версии 3.4.6. И как мне заткнуть только один из 20?
N>Очень просто: -Wextra включает список совершенно конкретных варнингов и они должны быть все описаны, так что назвать конкретное название.
хорошо, какое конкретное название у варнинга про неполный список инициализации агрегата?
Но даже если бы она и была, это жа маразм — давать именную опцию на каждый варнинг!
А если они решат еще 20 варнингов добавить — это что, они добавят еще 20 опций?
Ну это же ужас, в них там уже черт ногу сломит, как там эти опции совокупляются в разных позах...
J>>То же касается еще некоторых групповых варнингов, типа -Wabi. N>В этом случае его не было причин делить на отдельные пункты.
Ну само собой.
S>Выяснение вот этого "может оказаться, а может и не оказаться" может оказаться дороже, чем потенциальная прибыль с линуксоидов.
Прелесть в том, что расходов-то ноль. Не надо самому писать драйверы — открыть исходники виндовых, и сами все напишут. Я не думаю, что там в драйвере такой офигенный запатентованный алгоритм, что он сам по себе представляет коммерческую тайну. В этом прелесть опен соурс для производителей железа.
Да здравствует мыло душистое и веревка пушистая.
Re[39]: Why Desktop Linux Sucks, And What We Can Do About It
M>Нет, ты не позволяешь другим что-либо выирать. Напомнить? «RDP мне не нужен, я требую ssh»
Почему? Пусть выбирают. Мне вот нужен, да. Кому не нужен — тому не нужен.
J>Ну вот, например: J>Это 2009 год, т.е. вполне современная версия гцц.
Гм. Интересно. В любом случае, сравнивать надо просто скорость компиляции, а не то, как что и где организованно. Может, эти списки дают нефиговый выигрыш в другом месте. Берем сотню-другую проектов, компилируем и смотрим — кто выходит на круг быстрее.
J>Но самая главная претензия, которая лично меня реально достает — это то, как там в нем организована работа с варнингами,
Согласен. У меня тоже была такая же проблема, совершенно идиотский ворнинг, который не получалось выключить отдельно от всего остального.
Да здравствует мыло душистое и веревка пушистая.
Re[40]: Why Desktop Linux Sucks, And What We Can Do About It
M>>Нет, ты не позволяешь другим что-либо выирать. Напомнить? «RDP мне не нужен, я требую ssh» V>Почему? Пусть выбирают. Мне вот нужен, да. Кому не нужен — тому не нужен.
Ну тогда почему ты требуешь, чтобы это было в винде, но не позволяешь, чтобы кто-то что-то требовал от линукса?
M>Ну тогда почему ты требуешь, чтобы это было в винде, но не позволяешь, чтобы кто-то что-то требовал от линукса?
Опять за рыбу деньги. Позволяю. Требуй.
Да здравствует мыло душистое и веревка пушистая.
Re[42]: Why Desktop Linux Sucks, And What We Can Do About It
M>>Ну тогда почему ты требуешь, чтобы это было в винде, но не позволяешь, чтобы кто-то что-то требовал от линукса? V>Опять за рыбу деньги. Позволяю. Требуй.
Там должны быть стандартные решения. Например, ssh-клиент есть на моем телефоне.
[i]и чуть погодя[/]
Лично мне VPN не нужнен. Я вообще не понимаю, зачем "простому пользователю" VPN.
M>Там должны быть стандартные решения. Например, ssh-клиент есть на моем телефоне.
M>[i]и чуть погодя[/]
M>Лично мне VPN не нужнен. Я вообще не понимаю, зачем "простому пользователю" VPN.
M>Это в одном сообщении
Для МЕНЯ. Мне — должны. Мне — не нужен.
Здравствуйте, Vamp, Вы писали:
J>>Ну вот, например: J>>Это 2009 год, т.е. вполне современная версия гцц. V>Гм. Интересно. В любом случае, сравнивать надо просто скорость компиляции, а не то, как что и где организованно. Может, эти списки дают нефиговый выигрыш в другом месте. Берем сотню-другую проектов, компилируем и смотрим — кто выходит на круг быстрее.
А что там смотреть? Гцц проигрывает студийному и интеловскому компилятору по скорости и потребляемой памяти.
КБ>А что там смотреть? Гцц проигрывает студийному и интеловскому компилятору по скорости и потребляемой памяти.
Возможно, так оно и есть. Но свое высказывание хорошо бы обосновать. Кстати, на расход компилятора по памяти (пока он остается таким, что программа в принципе компилируется) наплевать.
Здравствуйте, Vamp, Вы писали:
КБ>>А что там смотреть? Гцц проигрывает студийному и интеловскому компилятору по скорости и потребляемой памяти. V>Возможно, так оно и есть. Но свое высказывание хорошо бы обосновать. Кстати, на расход компилятора по памяти (пока он остается таким, что программа в принципе компилируется) наплевать.
КБ>А что его обосновывать? Кто-то с ним не согласен?
Да вот в порядочном обществе принято свои высказывания обосновывать. Тут кто-то в ветке Пиаже цитировал, очень к месту.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, Vamp, Вы писали:
КБ>>>А что там смотреть? Гцц проигрывает студийному и интеловскому компилятору по скорости и потребляемой памяти. V>>Возможно, так оно и есть. Но свое высказывание хорошо бы обосновать. Кстати, на расход компилятора по памяти (пока он остается таким, что программа в принципе компилируется) наплевать.
КБ>А что его обосновывать? Кто-то с ним не согласен?
Я заранее соглашусь. Ну пусть проигрывает? И что с того?
Скорость и память компиляции — фактор обычно очень мало значимый. Значительно важнее, например, то, что работа по переносу gcc на доселе неизвестную платформу — один человеко-месяц. А как с VC? Под что он умеет компилировать кроме x86? Меня вот сейчас PPC интересует.
Если мне потребуется сборка быстро и дёшево по памяти в Linux/x86 — я лучше ICC возьму. MS VC мне в этом случае нафиг не сдался — ничего полезного не умеет.:)
Разумеется, вместо OO пойдет любое название. 
