«По умолчанию доступно автодополнение (по табуляции) и история команд (стрелочка вверх).»
Только для ОС с readline, то бишь, фактически, только *nix и MacOs.
Виндузятники пролетают мимо.
Хотя, простите, прочитал ваше «Хехе :) Вот за это я линукс и не люблю, и не использую :)) ». Могу ошибаться, но у меня складывается впечатление, что вы просто «не умеете его готовить». Ну и не понимаете, как работают базовые функции ядра с VFS, уж простите за прямоту.
Мне кажется, или вы что-то перемудрили с отслеживанием переименования, переоткрытия файлов и крутилки?
Если вы сделали open файла в процессе «раскладывалки», то и читайте его, пока он пополняется. До тех пор, пока ваш хэндл не будет закрыт, другие процессы могут хоть переименвывать, хоть удалять этот файл — для вашего процесса это никак не скажется.
Или я не так понял проблему.
Dr.Web,
webalta.ru — находится в категории «не рекомендованные для посещения». К сожалению, есть большая путаница с этими категориями у обычных пользователей. Почти всегда считают, что если антивирус блокирует страницу, то там вирус. Однако (пока) нет причин вносить вебальту в категорию «распространение вирусов». Но мы очень внимательно следим ;)
Воистинну! Интерфейс стал быстрее, не спорю, но всё еще глючный и без wiki markup стало трудно. С очень большим скрипом прижился апгрейд конфлюинса у нас. Лишь сильный аргумент, что в предыдущей версии была критичная дыра в безопасности. Так что плачем, колемся, но назад пути нет. Только если менять.
С точки зрения концепции рекомендую посмотреть реализацию ACL баз данных в IBM Lotus/Domino. Эта модель работает уже не первый десяток лет и, насколько я знаю, не претерпела значительных изменений.
Если очень кратко, то есть сущности: User, Group, Role. User может входить (а может и не входить) в одну или несколько(!) Group.
Также, группа может содержать другие группы, даже вперемешку с User'ами.
Роль — это предопределенная совокупность разрешений/ограничений (прав). Одну или несколько ролей можно назначать User'у и/или группе.
При этом, назначив роль(и) пользователю или группе, мы можем дополнительно переопределить нужные нам права, которые будут иметь приоритет над правами, выдаваемые назначенной ролью.
Это кажется сложным, но когда вникаешь, понимаешь, что это очень гибкая и прозрачная схема.
Смысл в том, что вы проектируете приложение именно под _Роли_, а не группы. Например, роли «Админ», «Юзер RO», «Юзер RW», «Редактор», и тп. Это логика приложения, на нее не влияют внешние факторы, типа набора подразделений в организации. Т.е., например, появление «Бухгалтерии» в компании приведет к появлению группы «Бухгалтерия», но на приложении никак не отразится!
А в приложении вы связываете (в ACL) пользователей и группы с их ролями. Группе «Админов» будет назначены все роли или только роль «админ», если она покрывает все остальные.
У вас появился новый админ или ушел старый — вы всего-лишь меняете состав группы «Админы».
Появилось новое структурное подразделение — добавили группу «Новое подразделение» и назначили ему необходимые роли.
Удобно создать группу «уволенные сотрудники», которая будет во всех ваших ACL и у которой сняты все права.
Сотрудник уволен — легким движением руки у него отбираются все права.
Итого: приложение проектируется под роли (наборы прав). Роли статичны. Группам и пользователям назначаются роли. Группы динамичны — их состав меняется со временем.
Как-то так.
Даже если антивирус работает на 100% эффективно, всё равно пользователь запустит файл, если очень того хочет. Пример из запроса в СТП: " Почему ваш… ый антивирус не дает мне скачать файл ??!!!111 Скачайте и пришлите мне его сами!". При этом URL, который был у него заблокирован, выглядел примерно так: g0og1e-fi1es.ru бла-бла-бла.
Т.е если бы у человека была кнопка «иди нафиг, я хочу скачать и запустить этот файл» (на самом деле она есть, но убрана) — он это сделал бы не задумываясь. Последствия очевидны.
P.S. В фоновой консоли трудится скрипт, перелопачивающий рунетовские сайты на предмет apk с SMSSender'ами. Очень много находит… :(
судо/рут нужен, если хочется получить полноценный доступ к ОС. Подавляющей части вирусов это не нужно, нужны ваши данные — парольчики, и прочее. А для этого вполне достаточно уязвимости в вашем браузере, запущенном под вашими же правами. Даже меньше — если у вас Ubuntu, например, посмотрите права в ~. Вас не смущает доступ r для others? Да, конечно, все критичные конфиги и каталоги, типа, .ssh закрыты, но возьмите ~Desktop — опять r! А ведь сюда хомячки кладут всё своё ценное. Возьмите сегодняшний бич под винду — энкодеры, с которыми непонятно что делать вообще и как ловить.
Так что мы спокойно живем под линукс, пока он не интересен с т.з. малой популярности у хомячков. Как только понадобится, поверьте, уязвимостей там хватит надолго.
RX-1000 и некоторые другие модели на работе (не помню).
Колесико вправо-влево использую для вперед-назад в браузере, Nautilus'е и некоторых других местах. Для этого хватает прописать где-нибудь в загрузке:
Ладно. CMMI красивое название, но показывает в основном только готовность компании отлистать $$$ за пунктик в своей карточке. Что-то вроде наших сертификаций ФСТЭК, МО и прочих. Толку 0, но все при деле.
Разочарую вас — это был сарказм. Цитата была из Золотого теленка, товарищ Полыхаев тоже любил оптимизировать, вы мне его и напомнили.
Я считаю ваш подход неправильным и неоправданным.
Как уже правильно заметили — правильный инструмент под конкретную задачу будет работать всегда лучше, чем неправильный. Но это на уровне КЭПа. От статьи хотелось бы побольше конкретики: более точные цифры о количестве и роде данных. А то, знаете, миллиард key-value записей и миллиард записей по 100 полей это две большие разницы…
Опять же, что вы будете делать с вашей RDB на миллиард записей, когда (внезапно!) понадобиться расширить схему данных? А если для проекта намного важнее бОльшая скорость вставки, чем вероятность потерять какую-то небольшую часть данных?
Это риторические вопросы, намекающие на плюсы и минусы двух подходов — вот это было бы интереснее.
имхо, конечно.
Только для ОС с readline, то бишь, фактически, только *nix и MacOs.
Виндузятники пролетают мимо.
Да, и не у всех linux =)
Если вы сделали open файла в процессе «раскладывалки», то и читайте его, пока он пополняется. До тех пор, пока ваш хэндл не будет закрыт, другие процессы могут хоть переименвывать, хоть удалять этот файл — для вашего процесса это никак не скажется.
Или я не так понял проблему.
webalta.ru — находится в категории «не рекомендованные для посещения». К сожалению, есть большая путаница с этими категориями у обычных пользователей. Почти всегда считают, что если антивирус блокирует страницу, то там вирус. Однако (пока) нет причин вносить вебальту в категорию «распространение вирусов». Но мы очень внимательно следим ;)
Если очень кратко, то есть сущности: User, Group, Role. User может входить (а может и не входить) в одну или несколько(!) Group.
Также, группа может содержать другие группы, даже вперемешку с User'ами.
Роль — это предопределенная совокупность разрешений/ограничений (прав). Одну или несколько ролей можно назначать User'у и/или группе.
При этом, назначив роль(и) пользователю или группе, мы можем дополнительно переопределить нужные нам права, которые будут иметь приоритет над правами, выдаваемые назначенной ролью.
Это кажется сложным, но когда вникаешь, понимаешь, что это очень гибкая и прозрачная схема.
Смысл в том, что вы проектируете приложение именно под _Роли_, а не группы. Например, роли «Админ», «Юзер RO», «Юзер RW», «Редактор», и тп. Это логика приложения, на нее не влияют внешние факторы, типа набора подразделений в организации. Т.е., например, появление «Бухгалтерии» в компании приведет к появлению группы «Бухгалтерия», но на приложении никак не отразится!
А в приложении вы связываете (в ACL) пользователей и группы с их ролями. Группе «Админов» будет назначены все роли или только роль «админ», если она покрывает все остальные.
У вас появился новый админ или ушел старый — вы всего-лишь меняете состав группы «Админы».
Появилось новое структурное подразделение — добавили группу «Новое подразделение» и назначили ему необходимые роли.
Удобно создать группу «уволенные сотрудники», которая будет во всех ваших ACL и у которой сняты все права.
Сотрудник уволен — легким движением руки у него отбираются все права.
Итого: приложение проектируется под роли (наборы прав). Роли статичны. Группам и пользователям назначаются роли. Группы динамичны — их состав меняется со временем.
Как-то так.
Т.е если бы у человека была кнопка «иди нафиг, я хочу скачать и запустить этот файл» (на самом деле она есть, но убрана) — он это сделал бы не задумываясь. Последствия очевидны.
P.S. В фоновой консоли трудится скрипт, перелопачивающий рунетовские сайты на предмет apk с SMSSender'ами. Очень много находит… :(
Так что мы спокойно живем под линукс, пока он не интересен с т.з. малой популярности у хомячков. Как только понадобится, поверьте, уязвимостей там хватит надолго.
Колесико вправо-влево использую для вперед-назад в браузере, Nautilus'е и некоторых других местах. Для этого хватает прописать где-нибудь в загрузке:
xinput set-button-map «Logitech USB Optical Mouse» 1 2 3 4 5 8 9 6
Без этого работать в браузере почти не могу уже =)
Ладно. CMMI красивое название, но показывает в основном только готовность компании отлистать $$$ за пунктик в своей карточке. Что-то вроде наших сертификаций ФСТЭК, МО и прочих. Толку 0, но все при деле.
Я считаю ваш подход неправильным и неоправданным.
«Прекрасная мысль. Полыхаев» (с)
— Что, они не называют его четвертьфунтовый чизбуогер?
— У них метрическая система, они вообще ни… я не понимают что это такое четверть фунта.
— И как же они его зовут?
— Они зовут его «Королевский чизбургер».
— «Королевский чизбургер»?
— Да, вот так." © pulp fiction
Опять же, что вы будете делать с вашей RDB на миллиард записей, когда (внезапно!) понадобиться расширить схему данных? А если для проекта намного важнее бОльшая скорость вставки, чем вероятность потерять какую-то небольшую часть данных?
Это риторические вопросы, намекающие на плюсы и минусы двух подходов — вот это было бы интереснее.
имхо, конечно.