Conficker все еще заражает 50 000 компьютеров в день
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
RE: Conficker все еще заражает 50 000 компьютеров в день - 2009-05-21 14:04:27.420000
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
На самом деле это урок для микрософта,
пусть дальше долбит гавяню винду,
все останутся без компа и всё,скажите пасиба билли.
Так что переходите на никс системы.
|
|
|
|
|
RE: Conficker все еще заражает 50 000 компьютеров в день - 2009-05-21 14:46:37.570000
|
|
|
Flint_ta
Сообщений: 3720
Оценки: 1120
Присоединился: 2007-01-26 15:49:18.323333
|
quote:
Так что переходите на никс системы.
По поводу никсов позволю себе процитировать мнение одного умного человека:
"Вопрос: Отсюда вытекает вопрос, который я давно хотел у тебя узнать, как человек не любящий проприетарное ПО ты сидишь на ОС с закрытым исходным кодом?
Ответ:
Приходится сидеть, потому что больше не на чем. Мне нужна ОС для работы, а не ебли с компиляцией ядер в консоли. Сейчас я сижу на собственной сборке windows 2003 x64, в которой удалено всё, что можно удалить и которая по максимуму изолирована от дыр/бэкдоров m$ с помощью сторонних открытых решений. Мне это не нравится, но Linux не нравится ещё больше. В будущем надеюсь перейти на ReactOS, целью которой является совмещение достоинств windows с идеологией открытой разработки.
Чтобы не быть голословным, приведу четыре причины, по которым я не люблю Linux и которые мешают ему стать господствующей десктопной ОС:
Причина №1 - отсутствие бинарной совместимости.
Я, как разработчик, хочу компилировать свой код в один дистрибутив, который любой пользователь мог бы установить двумя кликами мыши. И я хочу, чтобы мой софт мог быть использован даже через 10 лет после прекращения его поддержки. Под Windows мне достаточно придерживаться документированного API, и работоспособность везде и всегда гарантирована. Под Linux эта цель недостижима, поскольку нет не только бинарной совместимости, но и даже стабильного API. Я могу скомпилить .rpm и .deb, но они поддерживаются не всеми дистрибутивами, и скорее всего перестанут работать на следующей версии ОС из за изменения API библиотек. Извините, но это сущее блядство, и мне, как разработчику, оно отвратительно.
Я, как пользователь, хочу ставить понравившийся мне софт двумя кликами мыши, невзирая на то, что он может выпущен 10 лет назад, и даже не собирается в последней версии GCC. Если вы используете только почту, браузер и офис, то возможно вам не придется с этим столкнуться, но к примеру поставить Freenet на Gentoo - целое сексуальное приключение в стиле садо-мазо (по словам знакомого фаната Gentoo).
Конечно можно искать нужные версии библиотек, править код, искать решения в гуле, но я не фанатик, и мне оно нахрен не сдалось, я лучше потрачу своё время на что-нибудь полезное.
Причина №2 - отсутствие стабильного API даже на уровне исходного кода.
Эта причина не очевидна для тех, кто не пытался писать что-нибудь серьезное под Linux. По словам фанатиков-линуксоидов такой проблемы не существует, и из сорцов всё и всегда компилится без проблем. Я до недавнего времени тоже так считал, пока не попытался написать target для device mapper (модуль ядра). Извините, но такого блядства с API в жизни не видел. Определения и функций и структур меняются даже в минорных билдах ядра, и мне нужно ставить вагон ifdef'ов, чтобы мой код просто скомпилился на всех популярных ядрах. О какой-либо компилябельности кода в будущих ядрах без постоянной поддержки конечно же не может быть и речи. Извините, но нахуй мне это? У меня и так достаточно дел, чтобы ещё следить за выходом новых ядер и оперативно править код. В итоге драйвер я написал, но выкладывать сырой и несовместимый продукт посчитал постыдным, а поддержку слишком накладной, и версия под Linux отложена до лучших времен.
Чтобы не быть голословным, приведу несколько цитат из одного Linux драйвера:
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,5)
#error Linux kernel 2.6.5 or later required
#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
static struct kmem_cache *bio_ctx_cache = NULL;
#else
static kmem_cache_t *bio_ctx_cache = NULL;
#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
#define congestion_wait blk_congestion_wait
#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,17)
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,14)
static void *mempool_alloc_pg (gfp_t gfp_mask, void *pool_data)
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
static void *mempool_alloc_pg (unsigned int gfp_mask, void *pool_data)
#else
static void *mempool_alloc_pg (int gfp_mask, void *pool_data)
#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,17)
tc->bio_ctx_pool = mempool_create_slab_pool (MIN_POOL_SIZE, bio_ctx_cache);
#else
tc->bio_ctx_pool = mempool_create (MIN_POOL_SIZE, mempool_alloc_slab, mempool_free_slab, bio_ctx_cache);
#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
static void work_process (struct work_struct *qdata)
{
struct bio_ctx *bc = container_of(qdata, struct bio_ctx, work);
#else
static void work_process (void *qdata)
{
struct bio_ctx *bc = (struct bio_ctx *) qdata;
#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
INIT_WORK (&bc->work, work_process);
#else
INIT_WORK (&bc->work, work_process, bc);
#endif
К слову, этот драйвер в настоящий момент не компилируется, т.к. API ядра уже 10 раз изменилось. Кому как, но мне это блядство не по нраву.
ИМХО эти две причины объясняют то, что производители железа не горят желанием выпускать дрова для Linux. А открытые дрова сделанные энтузиастами почти всегда недофункциональны, а иногда их просто нет, ведь не зря wifi традиционно запускают через ndiswrapper, с помощью виндовых дров. И пока совместимость остается на столь плачевном уровне, никаких особых подвижек здесь не предвидится.
Причина №3 - идиотская и тормознутая архитектура графического интерфейса.
Тут всё очень просто: иксы висят отдельным процессом в юзермоде, что катастрофически снижает производительность при отрисовке большого кол-ва графических примитивов. Попробуйте запустить wine в ubuntu на виртуальной машине, и это станет очевидно. К тому же иксы часто падают, это меня до ужаса бесило, когда я писал код в KDevelop.
Причина №4 - ядро Linux крайне дыряво.
В ядре Linux за последние 2 месяца найдено больше дыр, чем в ядре NT за всё время его существования. И это не какой-то бум поиска дыр, а обычная ситуация. Не знаю как вы, а я не доверю такому ядру никаких конфиденциальных данных.
Думаю я внятно объяснил свою позицию. Фанатики Linux сейчас кинутся меня опровергать, но их я попрошу поберечь пыл до другого раза. Если для вас эти проблемы могут быть малозначимыми, то для меня они фатальны, поскольку комп мне нужен для производительного труда, а не возни с ОС."
|
|
|
|
|
RE: Conficker все еще заражает 50 000 компьютеров в день - 2009-05-22 00:15:51.050000
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
Плагин Nessus #36036 выполняет сеть базируемая проверка на компьютеры Windows, зараженные вариантом вируса Conficker. Просмотр не нуждается в верительных грамотах, но действительно требует, чтобы порты 445 или 139 были открыты между сканером Nessus и Вашими просмотренными системами. Плагин основан на исследовании от университета Бонна в Германии.
|
|
|
|
|
RE: Conficker все еще заражает 50 000 компьютеров в день - 2009-05-22 13:53:48.980000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
По поводу никсов позволю себе процитировать мнение одного умного человека:
[…]
Мне очень понравилось про тормозящую вендовс-программу, которая запущена на эмуляторе венды wine, который запущен в Ubuntoo, которая запущена на эмуляторе PC, который (как я домысливаю) запущен на Windows. Собственно в том примере, самой конфеткой является то, что в тормозах виноват XServer xD
Ты считаешь что это было написано умным человеком? Умный человек не будет обосновывать своё мнение религией. А этот обосновывает. И в его аргументах мало нерелигии.
Если тебе непонятно это…
|
|
|
|
|
|
