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

[jamy]

Переключение контекста (context switch) есть переход вектора выполнения из одного виртуального адресного пространства в другое. Связан (часто ) с сохранением состояния текущего вектора, (всегда) с перезагрузкой таблиц виртуальной памяти, TLB, очисткой пайплайна процессора, инвалидированием кэш и последующей перезагрузкой всего этого в новом пространстве. Процесс очень дорогой.

Вот именно! И переходить в контекст ядра по каждому "чиху" (как в случае с ядром Линукса) - не есть правильное решение.

Так что там, где драйвер работает в том же адресном пространстве что и ядро (Линух), обращение к драйверу есть просто косвенный вызов через таблицу точек входа, никакого context switch при этом не происходит. Там же, где драйвер сидит в отдельном виртуальном пространстве (маздай и хвалёные микроядра), для каждого обращения необходимо полное переключение контекста. Поэтому, обращение к драйверу в Линухе на несколько порядков величины дешевле.

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

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

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

Ещё одна полная чушь. Некоторые драйвера заводят отдельный kernel thread для выполнения операций слежения за устройством (пример: драйвер 10Гбитной Интеловской сетевой карточки), но в основной массе своей драйвера это просто набор подпрограмм, вызываемых компонентами ядра либо по обращению пользовательских процессов, либо по получению прерывания от устройств. Никаким "ядерным потокам" там делать нечего, их там и нет, никогда не было и не будет.

Верно подмечено - подпрограмм! И что эту подпрограмму невозможно остановить при поступлении нового прерывания?

А это просто бред сивой кобылы в буйную ночь. За такое я выгнал бы Вас со своего экзамена в универе и больше никогда не пустил бы.

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

Именно так она и работает. По крайней мере, пока количество активно бегущих процессов (не спящих и не ждущих какого-либо ввода/вывода) не превысит числа процессоров, чего в реальности добиться очень трудно, только на искусственно написанном тесте.

А если один из процессов перешел в режим ожидания, а другой наоборот, готов работать? Тут как раз и произойдет смена контекста.

На тот момент (2001 или 2002 год), ARM926EJ-S нет, не поддерживал.

Я что то не нашел. А вы можете привести отличия его от седьмого семейства?

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

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

Не Ваше, извините, собачье дело. Что и как хочу, то так и делаю.

Также не наше дело что вы там не успеваете всех обслуживать. Это была информация не относящаяся к делу. Но вы ей поделились, так что не "не обессудьте..."(C)

Расписано с некоторой степенью детализации в этом посте выше по тексту.

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

Наверняка есть и не один. Просто Вы в их число не входите (см. выше)

А я и не пытался в него входить. Я всеголишь отвечал на ваши выпады.

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

Нет. Вы обознались уважаемый.

Ага, поплачьте тут ещё, шалунишка-шкодник! Сами начали, теперь не обижайтесь. А впрочем, можете обижаться, мне-то что?

А чего мне плакать? Я вам указал на вашу невоспитанность. И мне ничуть не обидно что кто то там, на другой стороне пытаеться распространить на меня свое красноглазие.
А плакать вы начали по поводу того что вас, такого профи, пытаеться тыкать носом в маны не пойми кто.

[urmlr]

Вот именно! И переходить в контекст ядра по каждому "чиху" (как в случае с ядром Линукса) - не есть правильное решение.

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

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

Промах у Вас. Любой драйвер маздая сделанный через DDK бежит в отдельном адресном пространстве и на другом уровне защиты. Вплоть до того что при упрощении маздая до WinCE драйверы вообще были выхолощены до пользовательских "потоков" как Вы их называете.

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

Доказательства в студию пожалста!

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

На многоголовых машинах Линух работает точно так же. В конце концов вся подсистема IPC/RPC сделана на разделяемой памяти. Плюс, повторю, даже на однопроцессорных машинах в Линухе память ядра отмаппирована в любой пользовательский процесс. При этом верно и обратное, при обращении пользовательского процесса к ядру, память текущего пользовательского процесса уже доступна для ядра, поэтому никакого контекстного переключения не произойдёт. Оно может быть выполнено позднее, если выяснится что в результате этого обращения к ядру процесс должен быть приостановлен. Так и в микроядре в лучшем случае будет то же самое. А вот когда микроядро полезет в драйвер, тут оно сразу и проиграет. Хоть как, по любому.

Так что бросьте вы про мифическое превосходство микроядер. Нет его и принципиально быть не может.

Верно подмечено - подпрограмм! И что эту подпрограмму невозможно остановить при поступлении нового прерывания?

Причём здесь? Что-то можно, а что-то и нет. Только на многоголовой машине прерывание будет обработано другим процессором и ничего останавливать просто не надо. А вот если процессор один, а драйверный код (допустим для иллюстрации, что бежит в момент поступления прерывания именно драйвер) бежит с разрешённым прерыванием, то будет аппаратно сохранен вектор выполнения, ISR будет обработана и вектор будет восстановлен по RTI. Это на несколько порядков дешевле контекстного переключения, о чём Вы говорите вообще?

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

А вы бы их и не прошли. Так что результат один

А если один из процессов перешел в режим ожидания, а другой наоборот, готов работать? Тут как раз и произойдет смена контекста.

Да ну? И откуда же куда?

Я что то не нашел. А вы можете привести отличия его от седьмого семейства?

Господи! В форум писать научились а гуглом пользоваться - нет? Вот и вот например.

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

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

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

Неверно по определению и разжёвано в предыдущем абзаце.

Также не наше дело что вы там не успеваете всех обслуживать. Это была информация не относящаяся к делу. Но вы ей поделились, так что не "не обессудьте..."(C)

Мой пассаж на тему что я успеваю и чего нет никак не относится к Вам, это не была рекомендация Вам или ещё чего-то в этом духе.

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

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

И диалог с Андреем Танненбаумом мне вести не о чем, потому как если бы он был прав, то сейчас этот топик был бы о Миниксе против маздая а не о Линухе.

Нет. Вы обознались уважаемый.

Да? Надо же, обмишулился! Но какое поразительное сходство!

А чего мне плакать? Я вам указал на вашу невоспитанность. И мне ничуть не обидно что кто то там, на другой стороне пытаеться распространить на меня свое красноглазие.

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

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

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

[jamy]

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

Я же вам говорил, почитайте сперва про микроядра, потом будете вести спор.

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

Промах у Вас. Любой драйвер маздая сделанный через DDK бежит в отдельном адресном пространстве и на другом уровне защиты. Вплоть до того что при упрощении маздая до WinCE драйверы вообще были выхолощены до пользовательских "потоков" как Вы их называете.

Это которая WDK? Не вводите людей в заблуждение! DDK - это всеголишь набор средств разработки. С его помощью можно написать как usermode так и kernelmode драйвер. Но kernelmode драйвера всеравно остаються в ядре, и осовная работа проходит всеравно через них.
WinCE вы зря сравнивает потому что это микроядро.

Доказательства в студию пожалста!

Учитывая ваше упрямство, я полагаю что даже если я и потрачу свое время и предоставлю доказательства, то вы всеравно найдете аргументы чтобы раскритиковать их. Примерно такого рода: "Авторы этого теста использовали старую версию ядра линукса, в новой все уже работает быстрее" или ваше любимое "А что они запускаю тесты на одноголовых машинах, пусть проведут на Intel westmere!"

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

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

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

Микроядро никуда не лезет! Если вы действительно такой корифей инженерии, то должны уметь говорить техническим языком. Называйте вещи своими именами. А то "полезет", "обратиться к ядру"...

Так что бросьте вы про мифическое превосходство микроядер. Нет его и принципиально быть не может.

Если б это было так то в MacOSX сейчас бы было ядро *.BSD а не XNU!
MacOSX можно сказать самая свежая коммерческая ос. Хм! А почему не не на ядре линукса?(это риторический вопрос)

Причём здесь? Что-то можно, а что-то и нет. Только на многоголовой машине прерывание будет обработано другим процессором и ничего останавливать просто не надо. А вот если процессор один, а драйверный код (допустим для иллюстрации, что бежит в момент поступления прерывания именно драйвер) бежит с разрешённым прерыванием, то будет аппаратно сохранен вектор выполнения, ISR будет обработана и вектор будет восстановлен по RTI. Это на несколько порядков дешевле контекстного переключения, о чём Вы говорите вообще?

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

Да ну? И откуда же куда?

Не понял вопрос.

Господи! В форум писать научились а гуглом пользоваться - нет? Вот и вот например.

Я написал это чтобы вы здесь сами привели список различий. Чтоб мы могли оценить проделанную работу по портированию. Мне лично эти мануалы не нужны и читать их не собираюсь.

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

См. этот мой пост вверху.

Мой пассаж на тему что я успеваю и чего нет никак не относится к Вам, это не была рекомендация Вам или ещё чего-то в этом духе.

Я иговорю что это была лишняя информация, поэтому вы ее зря написали и поэтому не обижайтесь теперь на такие мои ответы.
А еще! Вам осталось здесь написать о том где учились и эту ветку можно будет переименовывать в "Блог urmlr".

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

А я не против Юникса! Если б вы внимательно читали мои посты, то знали бы что я и сам пользуюсь линуксом по сей день.
Какое станное у вас сравение. Это всеравно что я скажу: "Феррари - плохая машина, потому что на ней ездит меньше миллионной доли взрослого населения планеты".
Другое ваше заблуждение - это то что понятие микроядро и юникс не пересикаються. Примером тому все та же MacOSX. У нее достаточно много пользователей. И они что то не жалуются на скорость, хотя там используется микроядро первого поколения, можно сказать самое медленное микроядро. Она даже более юниксоподобная чем линукс. К чему тогда ваши сравнения количества пользователей микроядер и юниксов?

И диалог с Андреем Танненбаумом мне вести не о чем, потому как если бы он был прав, то сейчас этот топик был бы о Миниксе против маздая а не о Линухе.

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

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

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

А плакать мне нечего, мне тут вполне хорошо, недостаток заезжего конферанса на русском языке Вы мне успешно восполняете...

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

[VAdimSE]

Ребята, давайте жить дружно!!!
А главное - прочитайте название, не побоюсь этого слова, ФОРУМА. Ну может быть по делу

[VAdimSE]

Понимаю, опять вышвырнут.
Кто это сделал из двух за...
Но, вернувшись к теме "Линукс или Виндовз" надо говорить о задачах, которые интересуют ЮЗЕРОВ.
Например, сдать отчет, Виндовз - помог, Линукс - нет.
Для меня говно второе (никто не смог открыть "файл", да и Open Ofice не сильно справляется со своей работой).
Более того, если кому-то интересно время беспребойной работы системы то прихожу на службу в 8:00, ухожу (это не правда) - 17:00. Вот это и есть ВРЕМЯ РАБОТЫ.
Электричество экономить надо.
Куда складывать сэкономленное?
Пока в чем разница между системами НЕ понял из прочитанного трепа.

[_guardianangel]

VAdimSE, Если не секрет - какой файл? .docx и .xlsx прекрасно открываются опенофисом. Кстати даже поврежденные. А вот ридный офис сказал файл поврежден и иди нах. Восстановить не могу.

[bobic]

_guardianangel,

.docx и .xlsx прекрасно открываются опенофисом.

А так же Microsoft Office XP и 2003 http://www.microsoft.com/downloads/r...displaylang=ru

[urmlr]

Пока в чем разница между системами НЕ понял из прочитанного трепа.

Во первых, есть юридическая разница. За скачанную винду могут спокойно вышибить дверь, положить мордой в пол и вынести всю технику. Уже бывало в Росии не раз. А Линух от этого недостатка свободен.

Во вторых, в Линухе можно посмотреть любой (практически) исходный текст и если не нравится - поправить. В маздае, что индюк в Редмонде написал, то она и делает, "нравится, не нравится - жри, моя красавица".

В третьих, маздай требует определённого железа, например семёрку не поднять на стареньком 486-ом с 32 мегами ОЗУ, а Линух - за милую душу.

Это навскидку.

[zhevak]

Из анекдота:
-- А теперь, Золотая рыбка, ящик водки и всех обратно!

-- Я так понимаю, мои сонные, собрание пайщиков стихийно продолжается? -- реплика Гафта из к/ф "Гараж"
[/I]

Не-не-не!!! Постойте, постойте! Это ж излюбленный прием виндузятников.

1. Создать какой-нибудь навороченный тестовый файл в Ворде и попытаться открыть его в ОпенОфисе. Кто виноват? -- Линух! Он не понимает стандартных файлов! Ату его!!!

2. Создать какой-нибудь навороченный тестовый файл в ОпенОфисе и попытаться его открыть в Венде. Кто виноват? -- Линух! Он не умеет создавать стандартных файлов! Ату его во второй раз!

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

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

Я всякие документы предпочитаю творить в ОО.Writer. И что из этого следует? -- А ничего абсолютно! Я действительно не очень глубоко знаю Ворд. И мне как-то несподручно разбираться почему Ворд не способен обрабатывать большие документы, под сотню-две страниц. Мне очень даже непонятно, почему Ворд вообще падает (!!!) при загрузке определенного набора символов. Я на вскидку не скажу, но фокус десятилетней давности состоял в том, что если в Ворде набрать какое-то слова, то он валится. Я так же видел в бинарниках Майкрософт Офиса порочащие текстовые закладки от программистов. Ребята прикалываются, да. Но это наводит на грустные мысли -- а вообще, кто-нибудь проверяет исходные тексты Майкрософтовских программ? Что в них можно найти? Т.е. контроль на фирме вроде как толком-то и не работает. А теперь, прикинте, если в ОО.о кто-нибудь обнаружт подобную закладку левого кода? Исходники-то открыты! В прочем, это уже пошла политика отношений к работе и потребителям. Смачно плюнуть в котел с борщем -- это наше все! Пипл схавает все. Никто не заметит. Все скрыто под крышкой котла.

[urmlr]

Предлагаю задачку сторонникам маздая:

Есть сетка класса А+ (254.0.0.0) на которой болтаются несколько тысяч компов подвешенных через гигабитные верёвки. IP сетки, вестимо локальный, в инет с таким не вылезешь.

Задача: Создать систему доступа к инету с
- трансляцией адреса,
- локальным DNS и кэшированием внешних адресов,
- кэшированием доступа к внешней сетке по HTTP с целью уменьшения траффика наружу
- DHCP для всей сетки как с прибитыми гвоздиком адресами, так и с динамическими,
- почтовым сервером с обнаружением вирусов и троянов в аттачментах
- файрволлом, блокирующим Р2Р сетки в рабочее время но разрешающим их работу вне рабочего времени
- системой контроля трафика с обнаружением внутренних машин а) жрущих трафик и б) пытающихся переслать подозрительно большие объёмы информации наружу
- системой обнаружения попыток взлома
- WEB (HTTP) сервером доступным как изнутри, так и снаружи, но с разной информацией для внутреннего и для внешнего доступа.
- резервированием на случай отказа железа.

На всё про всё бюджет: одна тысяча баксов.

Слабо на маздае, нет?