Linux-ваше мнение

[amito66]

Вот сигнал о неблагополучии в работе с дисками у LINUX
http://www.proza.ru/2009/11/09/1399

По моему дилетантов линукс никогда не любил. Да и у них не все с ним гладко получалось.

[md5sum]

Полноценная 1С на Линукс ЕСТЬ! Делает 1С с производителями дистрЛинукс.
Про Корел: ищите на сайтах дизайнеров и художников (аналоги есть и по моему, возможность запуска тоже), здесь сайт по радиоэлектронике!

Сайт по радиоэлектронике, но тема про linux.
Про Corel и 1С - это просто примеры. (Для 1С (с их сайта):"компьютер конечного пользователя: операционную систему: Microsoft Windows 98/Me, Microsoft Windows 2000/XP/Server 2003/Vista"). Не нравится пример про Corel, тогда AutoCAD. Можно найти "аналоги" ACAD под линукс, но проработав с автокадом начиная с 10-й версии, просто нет желания менять привычную и удобную среду разработки на "аналоги"

И мой пост был к тому, что (это мое мнение) если нужна рабочая станция, то это windows, если сервер - то linux (*nix)

[oldzren]

По моему дилетантов линукс никогда не любил. Да и у них не все с ним гладко получалось.

amito66, в точку! плюспицот!

[EagleStars]

Уважаемый md5sum, Вы меня правильно отдёрнули по поводу 1С (Проверил, она портирована через wine (вопреки уверениям продавца, хотя я бы и под вайн взял без проблем); покупал с установкой; чисто ставится только 1С сервер), но мы про автокад...
wine готовит полноценную поддержку для компас и автокад:
http://www.etersoft.ru/content/view/...eetersoft-cad-
Так что те, кто поднаторел и предпочитает конкретные программы на винде, в ближайшем будущем будут не ограничены в выборе ОС.
P.s. Я уважаю Ваше мнение! Мой комментарий исключительно для обозначения ситуации, если заинтересует.

[BashSlash]

Мое мнение у GNU GUI Linux отличное будущее. Любой может настроить ОС под свои требования, или вообще собрать свою ОС. Конечно в школе Линуху не учат, но каждый желающий может и сам обучиться(в нете инфы море). Вопрос с фотошопом и автокадом, я считаю вопросом времени(Спрос рождает предложение). Но в данное время я считаю что 2 ос самое оптимальное решение. GUI Linux как основную поставить а Win на подстраховку.PS Для обычных пользователей конечно!

[NiTr0]

Кстати про винты и файловые системы кто-нибудь пытался установить вынь на USB-HDD? просто было дело достался бучный винт гигов на 40 так вот посмотрев с 10 интернет ресурсов такого разнообразия шаманских плясок я не видел нигде куда там Unix системам с компиляцией драйвера под чип видеокарты с остановленными иксами ))

Ставил. С плясками с бубном, правкой inf-файлов дров и hive реестра.

Потому как если ни чем кроме инета (да и то половина сайтов не откроется) не пользоваться то оно может и ниче а чуть чего програмного обезпечение под пингвина нету

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

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

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

Ну и? Что сложного? Сама хп (ретайловая или оем) не имеет нужных драйверов для поддержки загрузки с усб (в момент старта усб опрашивается, вызывая в обычной системе крах запуска).

Имеет. Не работает с ЮСБ исключительно из вредности. Потому что драйвер юсб стартует не на уровне boot, а позже.

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

Пообщайтесь с автором поста... Ему таки переписывали. Возможно - coreboot адаптированный, возможно - своя разработка, ибо военка.

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

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

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

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

Увы, не справляется, когда речь идет о сотне клиентов и индексах базы данных размером больше 4 Гб. При множественных запросах начинается интенсивный своппинг из-за нехватки памяти для одной задачи, особенно если запросы связанны с созданием или использованием "вьюшек" (view) - виртуальных, динамически формируемых таблиц. Единственный выход - уходить на 64 разряда и увеличивать физическую память.

Повторюсь: страничная адресация памяти. Которая при 32 битах адреса позволяет использовать неограниченный объем памяти. Единственное ограничение - не позволяет использовать "всю и сразу", но это не является серьезной проблемой, разве что дополнительные расходы на переключение страниц, отображаемых в окне. + модификация софта для поддержки страничной адресации.

При чем тут ядро? Это чисто железные проблемы и решаются совершенно другими методами. Кроме того серверные платформы сделаны на других конденсаторах, нежели десктоп-ширпотреб. У нас сервера Intel без проблем работают уже больше 8 лет и емкости на них в полном порядке.

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

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

А кто мешает ядру(драйверу) управлять контроллером страничной памяти, и проверять, какому процессу какая страница принадлежит? Проблема тут надуманная.

А EMM/EMS никогда не выходили за границы 4 Гб.

Ну и что, что не выходили? EMS работали на 16-разрядном 8086. При ограничении в 1 МБ. И позволяли наращивать память до 16МБ.

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

Накладные расходы на переключение страниц не так и велики, максимум - десяток %. На своппирование - куда больше.
Почему никто не реализовал это - я пока не представляю... Возможно - в связи с тем, что АМД реализовала х64 до того, как реально потребовались такие объемы памяти... В 2001, как-никак, более 4 ГБ не требовалось...

На наших серверах активны примерно в равной степени от 30 (минимальная нагрузка) до 200-300 (максимальная) процессов. А когда активен 1 (один) процесс, то это сервер просто стоит и скакание этого процесса между ядрами ну ни как не может сказаться на производительности сервера.

Речь ведь идет не только о ваших серверах. Или вы не можете представить задачи, где крутятся 2-3 ресурсоемких процесса?

Потом есть такое понятие как "нити" (threads), которыми процесс может внутри себя распараллелиться. Так вот "скакание", скорее всего, связанно именно с "нитями" и вполне естественно для современного программирования.

Отнюдь. Берете однопоточное приложение, и запускаете его на дуалкоре или квадкоре. Видите 50% загрузку проца (для дуала), при этом - практически одинаковую загрузку ядер. Резонный вопрос - а нахрена???

[EagleStars]

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

Хочу добавить...
Все цифровые микросхемы подвержены не частым, но регулярным сбоям. Вызвано это несколькими причинами:
1.) высокая тактовая частота, что делает микросхемы чувствительными к большому диапазону помех.
2.) микросхемы для вычислительной техники в основном состоят из большого числа компонентов. Компоненты делают как можно меньше и следовательно:
а.) они работают на малых токах (по микроскопическим проводникам большой ток не пропустить, излишки выделятся в виде тепла, что приведёт к перегреву(в перегреве не последнюю роль играет и высокая частота работы)), что делает их чувствительными к слабым помехам.
б.) такая миниатюризация ведет к большой вероятности брака, в том числе и скрытым дефектам (триггеры срабатывают через раз).
Источники помех для сбоев:
1.) радиочастотный шум.
2.) радиация; хватает даже естественного фона, чтобы изредка ловить свой протон или нейтрон.
3.) электростатические разряды, какая не была бы защита, в силу своих свойств (огромное напряжение, эффект солитона), они пробивают любую защиту; тока для повреждений хватает редко, зато для сбоя часто.
Методы борьбы:
1.) фильтры; обвеска из сглаживающих конденсаторов и индуктивностей.
2.) экраны соединённые с корпусом; помогает:
а.) сместить разницу потенциалов в безопасную сторону;
б.) поглотить или ослабить ряд помех.
3.) конструктивные методы:
а.) дублирование счётных частей, с последующим выявлением наиболее повторённого значения, как вероятнее всего правильного.
б.) наличия контрольных бит, для выявления ошибки и последующего пересчёта или сообщения об ошибки.
4.) программные методы:
а.) наличие контрольных сумм, так же как и с контрольным битом, но уже для более больших кусков данных.
в.) наличие механизмов контроля состояния процессов и их восстановления.
Подытожу...
Ни одно из цифровых устройств не застраховано от сбоев. Часто, не часто, но они происходят. Поэтому все ОС и не только, имеют системы защиты и восстановления в таких ситуациях. На данный момент наиболее устойчивыми де факто являются Unix подобные системы.

[SergCh]

Софт-бэды - могут быть. Физических повреждений - возникнуть не может.

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

2 EagleStars
Вся эта теория может быть справедлива для схемотехники времен 70-х середины 80-х го. С базой на ЭСЛ. В настоящем имхо используется ПЛМ, с коррекцией ошибок на аппаратном уровне. Думаю эти рассуждения едва ли актуальны.
Сбои системы скорее не из-за аппаратной ошибки, а программной. Но винда как бы противостоит сотням или даже десяткам версиям линукса. Среди последних есть и сбойные, но есть и более более устойчивые. Выбор за пользователем.

[NiTr0]

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

Вы даже понятия не имеете о том, о чем говорите. По порядку:
1) Пользуя унифицированные комманды ата-стандарта попросту невозможно добраться до служебки. Для этого есть вендор-комманды, которые для каждого производителя (а вернее - для каждой группы близких семейств от одного производителя) свои.
2) Из пользовательского уровня максимум, что можно сделать - это запись write long сектора вместе с КС (ессно неправильной), в результате чего получится софт-бэд. Который ликвидируется банальной записью в него.
3) Софт-бэды моут лезть и от кривых драйверов, и от китайского дешевого БП с завышенными пульсациями.
4) Винда при форматировании, если не ошибаюсь, проверяет только читабельность секторов, писать в них она не пробует. Остальные утилиты - тоже скорее всего.

Вся эта теория может быть справедлива для схемотехники времен 70-х середины 80-х го. С базой на ЭСЛ. В настоящем имхо используется ПЛМ, с коррекцией ошибок на аппаратном уровне. Думаю эти рассуждения едва ли актуальны.

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

Сбои системы скорее не из-за аппаратной ошибки, а программной.

Ну да, ну да. Заменили на машине (сервер на десктопном железе) материнку на новую (вообще - сначала ставили мать+проц+память, потом - для проверки поставили только мать, все остальное родное) - в результате поимели кучу геморроя в виде краша при ~100 мбит нагрузке.

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

Версии? Или вы так дистрибутивы называете?
Так ведь и винды сборок ого-го сколько, если уж сборками мериться...
Линукс - это ядро + набор базового софта (gcc, binutils, sh). Остальное - прикладное ПО.

[Alex_Prince]

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

Разговор двух админов:
- А Линукс лучше чем Виндовс!
- Чем лучше?
- Чем Виндовс!