защита от вандализма. Блокировка изменения настроек. ((вопросы применения ПСПО и Линукс в школах))
Модератор: Модераторы разделов
Re: защита от вандализма. Блокировка изменения настроек.
Может список блокируемых настроек вынести в отдельный конфиг-файл ? И, чтобы не менять синтаксис конфига после революций в программе и не писать проверку синтаксиса, использовать, например, что-нибудь вроде m4 для генерации настоящего файла, включаемого в код (т.е юзер пишет конфиг используя макросы m4 - примерно, как пишется configure.ac) ?
Re: защита от вандализма. Блокировка изменения настроек.
ну, если смотреть глобально - то это только сейчас и только в случае FF список опций в программе совпадает один-в-один со списком опций которые блокируются в конфигах FF.
Вообще, "одна галочка" в программе означает {"возможность"|"профит"|"полезняшку"} "для потребителя" - и может быть связана просто с "каким-то набором действий" - не обязательно с изменением конфига (хотя так будет чаще всего).
Потому в общем случае, я не думаю что получится уложить добавление новых галочек в скрипты gnu m4.
Кроме того - это мне видится как не нужное умножение сущностей, по крайней мере на текущем этапе развития программы.
Если вы гоыорите конкретно про плагин для огнелиса (он и единственный сейчас плагин - DummyFF) то сейчас для добавления новых опций - проще посадить Pyton-программиста для того, что бы он дописал новые элементы в массив optionsArray по образцу :
DummyFF.py:
- и т.д. Сколько элементов - столько и галочек в под-опциях...
В любом случае GNU m4 сейчас видится не такой приоритетной задачей. это наверное хорошо, но наверное как-нибудь попозже...
Так, как например и чтение конфигов для плагинов (пути, имена файлов и т.п.) из отдельного файла - что бы можно было адаптировать под разные дистрибутивы без переписывания исходника.
Вообще, "одна галочка" в программе означает {"возможность"|"профит"|"полезняшку"} "для потребителя" - и может быть связана просто с "каким-то набором действий" - не обязательно с изменением конфига (хотя так будет чаще всего).
Потому в общем случае, я не думаю что получится уложить добавление новых галочек в скрипты gnu m4.
Кроме того - это мне видится как не нужное умножение сущностей, по крайней мере на текущем этапе развития программы.
Если вы гоыорите конкретно про плагин для огнелиса (он и единственный сейчас плагин - DummyFF) то сейчас для добавления новых опций - проще посадить Pyton-программиста для того, что бы он дописал новые элементы в массив optionsArray по образцу :
DummyFF.py:
Код: Выделить всё
optionsArray = {
'lockPref("browser.startup.homepage", "about:blank");':"""
Устанавливаем стартовую
страницу about:blank
""",
'lockPref("browser.startup.page", 0);':"""
Та же настройка, что и browser.startup.homepage,
делаем стартовой страницей - пустую.
Просто на всякий случай.
""",
В любом случае GNU m4 сейчас видится не такой приоритетной задачей. это наверное хорошо, но наверное как-нибудь попозже...
Так, как например и чтение конфигов для плагинов (пути, имена файлов и т.п.) из отдельного файла - что бы можно было адаптировать под разные дистрибутивы без переписывания исходника.
Re: защита от вандализма. Блокировка изменения настроек.
Я с вами не согласен.
Смысл конфига в том, что он полностью повторяет "галочки" (а может даже добавляет дополнительные возможности), иначе он вообще не нужен.
Для чего может использоваться конфиг (по моему мнению):
- сохранение состояния. Это позволит, во-первых, реализовать опцию проверки соответствия текущего состояния желаемому, а, во-вторых, - профили.
Когда пользователь выполнил необходимую настройку, он может сохранить эти настройки в конфиг. Тогда при следующем запуске скрипт должен различать два состояния: текущее состояние системы, определяемое просмотром настроек программ, и "то, что хочет пользователь", определяемое из конфига. Если добавить возможность использования нескольких конфигов (пользователь может указать из какого загружать "желаемое" состояния), то получится реализация профилей.
- консольный клиент. Даже если текущая реализация привязана к ГУИ (это так?), то можно сделать просто отдельный скрипт для консоли, но они должны использовать один и тот же конфиг, иначе такой консольный скрипт не имеет смысла.
Во всех этих "применениях" конфиг должен _полностью_ повторять настройку из ГУИ (или предоставлять еще больше возмодностей).
Зачем тут m4? Я думаю, что если сам конфиг будет писаться через макросы m4, то это позволит сохранять постоянный синтаксис для пользователя при изменении "внутренней" реализации. Т.е из пользовательского конфига, написанного с помощью макросов m4, можно генерировать файл (это должен делать сам скрипт, когда хочет прочитать конфиг), который можно просто включить в код скрипта. Это позволит не писать проверку синтаксиса в скрипте (вряд ли m4 защитит от всех ошибок, но это лучше, чем вообще ничего).
Нет, это не умножение сущностей, это разделение _разных типов сущностей_: разделение неизменяемой в процессе работы части программы - кода скрипта, от изменяемой - настроек. Мне кажется, что настройка через изменение кода допустима только для "проектов" "лишь бы поскорее сделать, да лишь бы работало", которые пишутся для единичного использования и которые не планируется ни обновлять, ни поддерживать в будущем. Если же это не так, то конфиг (или что-то его заменяющее) должно планироваться изначально (даже, если в первых версиях не будет полноценной его работы, но он должен быть предусмотрен).
Не то, чтобы я не согласен с тем, что это не самая приоритетная задача, - это вам виднее, но я считаю, что он нужен и интерфейс для его чтения должен планироваться уже сейчас.
Смысл конфига в том, что он полностью повторяет "галочки" (а может даже добавляет дополнительные возможности), иначе он вообще не нужен.
Для чего может использоваться конфиг (по моему мнению):
- сохранение состояния. Это позволит, во-первых, реализовать опцию проверки соответствия текущего состояния желаемому, а, во-вторых, - профили.
Когда пользователь выполнил необходимую настройку, он может сохранить эти настройки в конфиг. Тогда при следующем запуске скрипт должен различать два состояния: текущее состояние системы, определяемое просмотром настроек программ, и "то, что хочет пользователь", определяемое из конфига. Если добавить возможность использования нескольких конфигов (пользователь может указать из какого загружать "желаемое" состояния), то получится реализация профилей.
- консольный клиент. Даже если текущая реализация привязана к ГУИ (это так?), то можно сделать просто отдельный скрипт для консоли, но они должны использовать один и тот же конфиг, иначе такой консольный скрипт не имеет смысла.
Во всех этих "применениях" конфиг должен _полностью_ повторять настройку из ГУИ (или предоставлять еще больше возмодностей).
Зачем тут m4? Я думаю, что если сам конфиг будет писаться через макросы m4, то это позволит сохранять постоянный синтаксис для пользователя при изменении "внутренней" реализации. Т.е из пользовательского конфига, написанного с помощью макросов m4, можно генерировать файл (это должен делать сам скрипт, когда хочет прочитать конфиг), который можно просто включить в код скрипта. Это позволит не писать проверку синтаксиса в скрипте (вряд ли m4 защитит от всех ошибок, но это лучше, чем вообще ничего).
Denjs писал(а): ↑09.11.2010 03:14Кроме того - это мне видится как не нужное умножение сущностей, по крайней мере на текущем этапе развития программы.
Если вы гоыорите конкретно про плагин для огнелиса (он и единственный сейчас плагин - DummyFF) то сейчас для добавления новых опций - проще посадить Pyton-программиста для того, что бы он дописал новые элементы в массив optionsArray по образцу :
Нет, это не умножение сущностей, это разделение _разных типов сущностей_: разделение неизменяемой в процессе работы части программы - кода скрипта, от изменяемой - настроек. Мне кажется, что настройка через изменение кода допустима только для "проектов" "лишь бы поскорее сделать, да лишь бы работало", которые пишутся для единичного использования и которые не планируется ни обновлять, ни поддерживать в будущем. Если же это не так, то конфиг (или что-то его заменяющее) должно планироваться изначально (даже, если в первых версиях не будет полноценной его работы, но он должен быть предусмотрен).
Не то, чтобы я не согласен с тем, что это не самая приоритетная задача, - это вам виднее, но я считаю, что он нужен и интерфейс для его чтения должен планироваться уже сейчас.
Re: защита от вандализма. Блокировка изменения настроек.
попробую детализировать мою мысль "о не полном соответствии галочек в нашей программе - опциям конфиг-файла программы которую мы настраиваем".
Приведу несколько примеров.
В нашей программе есть галочка: "заблокировать конфиг-файлы от редактирования".
Это операция связана с модификацией прав доступа на определенные файлы. Это не опция конфигурационного файла, это "действие".
Галочка в нашей программе : "Использовать автооткат домашней директории при логауте".
Это операция, связанная с созданием/модификацией некоторых конфигурационных bash-скриптов, и размещением их в заданных директориях.
Ещё: галочки в текущем плагине для фокса - они после записи в файл, требуют спец-обработки данного файла (сдвиг на 13 байт) и прописывание специального указания в .js-скрипте.
Помимо этих галочек, могут быть галочки совершенно иного рода - это модификация/переконфигурирование .js-скриптов Огнелиса.
Помимо упомянутого, в нашей программе может быть галочка "использовать R-kiosk 0.8.1 плагин". ( это совсем-жестокий-киоск-мод плагин для огнелиса) - загинание галочки будет приводить к ряду действий по копированию/установке плагина в заданное место, и его подключению к системе.
Первоочередная задача данной программы (по крайней мере - как я её вижу) - это не повторение опций конфиг файлов "в приятном интерфейсе", а предоставление готовых рецептов по настройке системы, и автоматизация данных _действий_ по настройке системы/программы.
Действия включают в себя не только модификацию конфиг-файла, но и алгоритмы: - операции над файлами, программными модулями, изменение скриптов.
т.е. "универсального алгоритма по настройке программы по списку опций" - сделать не получится.
Отделить список опций от кода не выйдет, потому что изменение опций конфиг-файла целевой программы - это один частный случай из невообразимого множества того, что может потребоваться.
Потому, не вижу того, как мы можем универсально описывать новые опции без изменения кода.
Собственно потому и сама идея плагинов и возникла - с каждой программой надо работать уникально, по своему алгоритму и подходу.
И по той-же причине программа пишется на скриптовом языке - что бы её можно было быстро модифицировать. Если бы можно было отделить код от настроек - я бы все на C++\QT набросал.
так... тут как я понимаю вы говорите о сохранении "конфигурации выбранных галочек", что бы потом можно было повторить её на другой машине?
Да, это разумная вещь, но потом. Я о чем-то похожем возможно уже говорил.
А вопросами выставления галочек в соответствие с реальным состоянием системы должен заниматься плагин. Как - отдельный вопрос, общего алгоритма нет.
....
я не запутал / не запутался?
Приведу несколько примеров.
В нашей программе есть галочка: "заблокировать конфиг-файлы от редактирования".
Это операция связана с модификацией прав доступа на определенные файлы. Это не опция конфигурационного файла, это "действие".
Галочка в нашей программе : "Использовать автооткат домашней директории при логауте".
Это операция, связанная с созданием/модификацией некоторых конфигурационных bash-скриптов, и размещением их в заданных директориях.
Ещё: галочки в текущем плагине для фокса - они после записи в файл, требуют спец-обработки данного файла (сдвиг на 13 байт) и прописывание специального указания в .js-скрипте.
Помимо этих галочек, могут быть галочки совершенно иного рода - это модификация/переконфигурирование .js-скриптов Огнелиса.
Помимо упомянутого, в нашей программе может быть галочка "использовать R-kiosk 0.8.1 плагин". ( это совсем-жестокий-киоск-мод плагин для огнелиса) - загинание галочки будет приводить к ряду действий по копированию/установке плагина в заданное место, и его подключению к системе.
Первоочередная задача данной программы (по крайней мере - как я её вижу) - это не повторение опций конфиг файлов "в приятном интерфейсе", а предоставление готовых рецептов по настройке системы, и автоматизация данных _действий_ по настройке системы/программы.
Действия включают в себя не только модификацию конфиг-файла, но и алгоритмы: - операции над файлами, программными модулями, изменение скриптов.
т.е. "универсального алгоритма по настройке программы по списку опций" - сделать не получится.
Отделить список опций от кода не выйдет, потому что изменение опций конфиг-файла целевой программы - это один частный случай из невообразимого множества того, что может потребоваться.
Потому, не вижу того, как мы можем универсально описывать новые опции без изменения кода.
Собственно потому и сама идея плагинов и возникла - с каждой программой надо работать уникально, по своему алгоритму и подходу.
И по той-же причине программа пишется на скриптовом языке - что бы её можно было быстро модифицировать. Если бы можно было отделить код от настроек - я бы все на C++\QT набросал.
Для чего может использоваться конфиг (по моему мнению):
- сохранение состояния
так... тут как я понимаю вы говорите о сохранении "конфигурации выбранных галочек", что бы потом можно было повторить её на другой машине?
Да, это разумная вещь, но потом. Я о чем-то похожем возможно уже говорил.
А вопросами выставления галочек в соответствие с реальным состоянием системы должен заниматься плагин. Как - отдельный вопрос, общего алгоритма нет.
....
я не запутал / не запутался?
Re: защита от вандализма. Блокировка изменения настроек.
Поставим в конфиге скрипта параметр 'ro_conf_files=1'. При перезапуске скрипт, увидев такой параметр, должен проверить правильные ли сейчас права доступа к конфиг файлам. Для этого он должен вызвать функцию ro_conf_files_check() (это лишь как пример, см ниже)
Поставим в конфиге скрипта параметр 'restore_home_dir=1'. При перезапуске скрипт. увидев такой параметр в своем конфиге, должен проверить создание/модификацию конфигурационных баш-скриптов и их размещение. Для этого он должен вызвать функцию restore_home_dir_check().
При чем тут сдвиг файла не понимаю, а прописывание указания и размещение файлов точно также скрипт должен проверить, если в его конфиге стоит, например, 'lock_firefox_settings=1'. И для этого тоже он должен вызвать функцию lock_firefox_settings_check().
Denjs писал(а): ↑09.11.2010 13:16Помимо этих галочек, могут быть галочки совершенно иного рода - это модификация/переконфигурирование .js-скриптов Огнелиса.
Помимо упомянутого, в нашей программе может быть галочка "использовать R-kiosk 0.8.1 плагин". ( это совсем-жестокий-киоск-мод плагин для огнелиса) - загинание галочки будет приводить к ряду действий по копированию/установке плагина в заданное место, и его подключению к системе.
Аналогично.
Результат любого действия можно проверить. И ваш скрипт должен содержать не только функции изменяющие что-то, но и проверяющие текущее состояние данного "объекта", т.е результат работы.
Мне кажется, мы под "опциями в конфиге скрипта " понимаем что-то разное.
Denjs писал(а): ↑09.11.2010 13:16Первоочередная задача данной программы (по крайней мере - как я её вижу) - это не повторение опций конфиг файлов "в приятном интерфейсе", а предоставление готовых рецептов по настройке системы, и автоматизация данных _действий_ по настройке системы/программы.
Действия включают в себя не только модификацию конфиг-файла, но и алгоритмы: - операции над файлами, программными модулями, изменение скриптов.
Именно. Одна опция в конфиге скрипта вовсе не должна один к одному соответствовать опции программы. Она может соответствовать набору действий, нескольким опций одной или нескольких программ.
В виду того, что написал выше, по-прежнему не вижу никаких препятствий, чтобы отделить список опций от кода.
Denjs писал(а): ↑09.11.2010 13:16Потому, не вижу того, как мы можем универсально описывать новые опции без изменения кода.
Собственно потому и сама идея плагинов и возникла - с каждой программой надо работать уникально, по своему алгоритму и подходу.
И по той-же причине программа пишется на скриптовом языке - что бы её можно было быстро модифицировать. Если бы можно было отделить код от настроек - я бы все на C++\QT набросал.
Честно говоря, не вижу сложностей с написанием этого на чем-то типа С. Чем, например, определение для каждой задачи ( = опции в конфиге скрипта) функций с стандартизированным прототипом:
opt_enable()
opt_check_state()
opt_disable()
не аналогия плагинам? (или я чего-то не знаю?)
Почему обязательно на другой? Сохранение "конфигурации галочек" очень полезно и на одной. Например, пользователь может сделать такие конфиги
config_block (блокировка всего, что он хочет)
config_regular_maintanance (что-то разблокировано для выполнения каких-то служебных задач)
config_allow (все разрешено)
Ведь загрузить конфиг и нажать 'apply' намного быстрее, чем каждый раз заново выставлять галочки.
Re: защита от вандализма. Блокировка изменения настроек.
Ладно, у меня во вторник-четверг прокурорская проверка будет. Я ценю ваши попытки сделать так, как нужно мне. Но, как я понимаю, результата пока отрицательный Так "что доложить мой король"? Что под линуксом это пока сделать не реально? Или будет шанс?
Или уже уходить с данного курса в направлении прозрачного прокси-сервера, а?
Или уже уходить с данного курса в направлении прозрачного прокси-сервера, а?
Re: защита от вандализма. Блокировка изменения настроек.
DoctorORZ писал(а): ↑15.11.2010 00:31Ладно, у меня во вторник-четверг прокурорская проверка будет. Я ценю ваши попытки сделать так, как нужно мне. Но, как я понимаю, результата пока отрицательный Так "что доложить мой король"? Что под линуксом это пока сделать не реально? Или будет шанс?
Или уже уходить с данного курса в направлении прозрачного прокси-сервера, а?
Не то что не реально, здесь просто другой алгоритм работы. Вы хотите привычными свистоперделки в среде, коорая решает ваши задачи другими методами.
Прозрачный прокси к топегстартовой проблеме отношения не имеет.
Re: защита от вандализма. Блокировка изменения настроек.
в направлении прозрачного прокси-сервера
Если вы про организацию доступа к сети - то да, это надо менять. А то то, как у вас был сделан доступ в инет - это ... гм.. неправильно.
Про киоск-мод различных программ - сейчас есть и работает только настройка Firefox (см #300 ) (и то - интерфейс работает "относительно", потому что раскрывать дерево со списком не стоит))). Но фокс настраивается и настройки блокируются
Если minoru-kun не сможет уделить внимание интерфейсу - "буду начать переписывать интерфейс под QT"...
и после писать плагины для остальных систем. (первый - это настройки XFCE в киоск-мод, потом установка "авторесета" каталога пользователя.)
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: защита от вандализма. Блокировка изменения настроек.
Я давно говорил, что это единственно верное решение. Если даже заблокировать настройки Firefox, он наверняка не единственный браузер в системе. А ещё есть всякие wget'ы и прочее, и ими тоже можно порнуху качать. Но главное - прокси настраивается один раз, а браузер - на каждом компе отдельно, так зачем себе жизнь усложнять?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: защита от вандализма. Блокировка изменения настроек.
Как, я думаю, вы понимаете, комьюнити линукс всегда готово помочь советом и делом, вот только ответственности не несет никакой. Поэтому, если вы сами готовы продолжать искать решение и пробовать различные способы, то шанс есть. А иначе.. вряд ли
Re: защита от вандализма. Блокировка изменения настроек.
Ну, по поводу того, что в системе много браузеров - это не вопрос. Оставляем только мозилу, остальное долой. В мозиле прописываем и замораживаем настройки. Технически, это и в других браузерах сделать не проблема. Так что это не проблема вовсе.
Denjs Я пробовал как ты советовал - не заработало. Нельзя шлюзом выставлять мой прокси
Сквид и Dansguardian собираюсь пробовать на зимних каникулах - сейчас просто нет времени. Но, они у меня останутся только при одном условии - я смогу настроить их (и управлять так же гибко) именно как мне нужно. Потому что судя по откликам, там ещё много проблем по фильтрации. И... только с помощью сквида можно реализовать прозрачный прокси? Или есть ещё что? Советы по грамотному построению сети принимаются. Хорошо, давайте про прокси и сеть в другой теме обсудим.
Denjs Я пробовал как ты советовал - не заработало. Нельзя шлюзом выставлять мой прокси
Сквид и Dansguardian собираюсь пробовать на зимних каникулах - сейчас просто нет времени. Но, они у меня останутся только при одном условии - я смогу настроить их (и управлять так же гибко) именно как мне нужно. Потому что судя по откликам, там ещё много проблем по фильтрации. И... только с помощью сквида можно реализовать прозрачный прокси? Или есть ещё что? Советы по грамотному построению сети принимаются. Хорошо, давайте про прокси и сеть в другой теме обсудим.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: защита от вандализма. Блокировка изменения настроек.
Это проблема, поскольку помимо графических браузеров есть консольные качалки, удаление которых нарушит работоспособность системы. И если технически не проблема - что же до сих пор не сделали?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: защита от вандализма. Блокировка изменения настроек.
Не проблема другие браузеры настроить я имел ввиду. Кроме того, все консольные качалки, весь этот мусор вкупе с чатами, аськами и прочей хренью будет удален с ученических компов под ноль. У меня есть указания, осуществлять контент-фильтрацию. Я её осуществляю. Ибо учить учеников как пользоваться качалками-аськами - себя не уважать. Они сами тут кого хошь научат. Ну, да, под линуксом будет непривычно. Но, процесс пошел - почти каждый день записываю по диску с линуксом для ребят... Но, как вы думаете, на что они запали? На то, что свободный? - не-а. На то, что вирусов там нет? - не-а. На куб рабочего стола они запали в компизе и на cairo-dosc. На "блестяшки" одним словом
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: защита от вандализма. Блокировка изменения настроек.
Это не мусор, это часть системы, необходимая для её нормальной работы, повторяю ещё раз. И перед Вами, насколько я понимаю, стоит задача не только оградить учеников от нежелательного контента (всё равно не будут они wget'ом порносайты выкачивать), но ещё и комиссии это доказать. А что и как она проверять станет - кто ж знает... Так что сама принципиальная возможность доступа к "неправильным" сайтам должна быть прибита.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: защита от вандализма. Блокировка изменения настроек.
вот учитель спрашивает именно про то, что здесь так долго обсуждалось: Панель задач в Альт Линукс 5.0.1 школьный мастер
но давать ссылку на эти надцать страниц пререканий — как-то не вижу смысла.
может, кто-нибудь выскажет квинтэссенцию?
p.s. только не все сразу! ведь затопчете же! (улыбка)
но давать ссылку на эти надцать страниц пререканий — как-то не вижу смысла.
может, кто-нибудь выскажет квинтэссенцию?
p.s. только не все сразу! ведь затопчете же! (улыбка)
Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог
при сбоях форума см.блог
Re: защита от вандализма. Блокировка изменения настроек.
отписался...
теперь по нашему топику - кто возьмется за допиливание нтерфейса нашей софтины? есть питоны-альтруисты со знанием GTK или QT?)))))
теперь по нашему топику - кто возьмется за допиливание нтерфейса нашей софтины? есть питоны-альтруисты со знанием GTK или QT?)))))
Re: защита от вандализма. Блокировка изменения настроек.
Bizdelnick писал(а): ↑16.11.2010 17:57Это не мусор, это часть системы, необходимая для её нормальной работы, повторяю ещё раз.
Это - мусор. Потому что когда будет нужно, я сам установлю всё, что положено и нужно. А вот сидеть в аськах на "камчатке" вместо того, что бы записывать лекцию, это никому не нужно.
Вы же в курсе, что по Аське можно передать любой файл. В том числе и порно картинку, а?
Re: защита от вандализма. Блокировка изменения настроек.
спасибо.
забыли добавить: и с чувством прекрасного.
Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог
при сбоях форума см.блог
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: защита от вандализма. Блокировка изменения настроек.
DoctorORZ писал(а): ↑23.11.2010 14:00Это - мусор. Потому что когда будет нужно, я сам установлю всё, что положено и нужно. А вот сидеть в аськах на "камчатке" вместо того, что бы записывать лекцию, это никому не нужно.
Вы же в курсе, что по Аське можно передать любой файл. В том числе и порно картинку, а?
Где я про аську писал, ткните пальцем плз.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- minoru-kun
- Сообщения: 620
- ОС: Debian GNU/Linux
Re: защита от вандализма. Блокировка изменения настроек.
А кто-нибудь может дать rdesktop и ssh до рабочей машины с ПСПО5? Пусть даже виртуальной? Иначе, чувствую, далеко мы так и не продвинемся.
Re: защита от вандализма. Блокировка изменения настроек.
Извольте
minoru-kun писал(а): ↑24.11.2010 07:18А кто-нибудь может дать rdesktop и ssh до рабочей машины с ПСПО5? Пусть даже виртуальной? Иначе, чувствую, далеко мы так и не продвинемся.
Я б дал, да белого IP нема
Re: защита от вандализма. Блокировка изменения настроек.
Простите, не дождался, давно в тему не заходил....
Насчет rdesktop - IP у мну есть, но у меня нет места на диске под виртуальку на домашнем сервере...
И так, господа. Второй работающий релиз программы настройки "киоск мода" для Firefox.
Предназначено для работы на ПСПО5, Firefox 3.5.9 установленного из репозиториев.
Предлагаю название: AnyKiosk - как суть отражающую задачу программы - настраивать все что угодно в киоск мод.
для AnyKiosk : SafeRunIt с плагином FireFox требуются:
Linux (PSPO5, AltLinux), Python, PyQT, QT4, Perl (нужен только для плагина FireFox)
(все идет в стандартном комплекте "изпоткаропки")
Простите, не дождался....
переписал все под PyQT.
В принципе, ничего окромя интерфейса (и хранения ключей в другом типе) не менял по сравнению с предыдущей версией.
Переведено на QT. Полагаю, что немного коряво, извините, пишите предложения.
Главное что это сейчас работает.
Вот "видево" как это работает:
http://www.youtube.com/watch?v=pTbUtHZIBB0
Если minoru-kun не против - я бы предложил далее жить и развиваться с PyQT.
Насчет rdesktop - IP у мну есть, но у меня нет места на диске под виртуальку на домашнем сервере...
И так, господа. Второй работающий релиз программы настройки "киоск мода" для Firefox.
Предназначено для работы на ПСПО5, Firefox 3.5.9 установленного из репозиториев.
Предлагаю название: AnyKiosk - как суть отражающую задачу программы - настраивать все что угодно в киоск мод.
для AnyKiosk : SafeRunIt с плагином FireFox требуются:
Linux (PSPO5, AltLinux), Python, PyQT, QT4, Perl (нужен только для плагина FireFox)
(все идет в стандартном комплекте "изпоткаропки")
Простите, не дождался....
переписал все под PyQT.
В принципе, ничего окромя интерфейса (и хранения ключей в другом типе) не менял по сравнению с предыдущей версией.
Переведено на QT. Полагаю, что немного коряво, извините, пишите предложения.
Главное что это сейчас работает.
Вот "видево" как это работает:
http://www.youtube.com/watch?v=pTbUtHZIBB0
Если minoru-kun не против - я бы предложил далее жить и развиваться с PyQT.
- Вложения
-
- anyKiosk_safeRunIt.qt.2010.11.30_1920.zip
- (9.84 КБ) 6 скачиваний
Re: защита от вандализма. Блокировка изменения настроек.
Был бы пакет для gear и ориентация на ALT Linux (где уже совсем другая версия), я бы включил в новую редакцию Альт Линукс 5.0.2 Школьный. Но Вы можете предложить это авторам ПСПО5.
Готовы это дорабатывать через Git?
Skull
Re: защита от вандализма. Блокировка изменения настроек.
Ни, ни в коем разе. Научить забыли.
Ребят, если вы думаете, что школьный учитель (зам по ИКТ) прошедший (фиктивно) дистанционные курсы обучения Линуксу знает всё "от и до" - вы ошибаетесь. Но, ведь и вам неведомо заполнять отчеты такого плана, а?
опс... убрали табличку то.. на 42 листа. Ничего, найду - выложу.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: защита от вандализма. Блокировка изменения настроек.
Вижу слово "аська" только в Вашей цитате. Я писал только про консольные качалки.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Re: защита от вандализма. Блокировка изменения настроек.
и dyndns и ipv6 недистрибутивоспецифичны. эти слова читаются (и означают) ровно то же самое и в gnu, и в windows, и в macos, и в любой другой операционной системе.
Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог
при сбоях форума см.блог
Re: защита от вандализма. Блокировка изменения настроек.
"Планируемый релиз 5.0.2 15 декабря 2010 года." - вы успеете?
ориентация на альт-линукс? гм... там сильно все отличается от путей в ПСПО5? В качестве "быстрого временного решения" можно сделать вариант ориентированный только на альт-5.0.2 что бы успеть к сроку.
что бы все проверить на виртуалке что бы оно работало в 5.0.2 - что туда надо ставить?
я не работал с gear. c git тоже не разбирался, но он же вроде умеет "строить из себя" svn?
сборкой пакетов с gear должен занялся кто-то другой. я же могу обновлять исходники в ваших репозиториях.
ps:Лицензия GPL.
ЗЫ:Есть кто из форумчан кто готов взять на себя задачи взаимодействия с альт-линуксом?
Re: защита от вандализма. Блокировка изменения настроек.
Добавить несложно. Был бы пакет.
(шёпотом) вообще-то ПСПО5 есть форк Simply Linux (который делается на базе ALT Linux). Так что пакетная база практически та же.ориентация на альт-линукс? гм... там сильно все отличается от путей в ПСПО5?
Думаю, там не такая сильная привязка к версии Firefox (сейчас в p5 3.6.12+)В качестве "быстрого временного решения" можно сделать вариант ориентированный только на альт-5.0.2 что бы успеть к сроку.
Любой десктопный дистрибутив из Альт Линукс 5.0 Школьный и обновить пакеты или лучше весь из p5/branch (репозиторий по умолчанию для обновления)что бы все проверить на виртуалке что бы оно работало в 5.0.2 - что туда надо ставить?
Тоже версии контролирует, но распределённо.я не работал с gear. c git тоже не разбирался, но он же вроде умеет "строить из себя" svn?
Я посмотрю на пакет. Потом можете просто исправлять и отправлять git format-patch на правах автора. Пишите мне на cas@altlinux.org.сборкой пакетов с gear должен занялся кто-то другой. я же могу обновлять исходники в ваших репозиториях.
ps:Лицензия GPL.
Кхе-кхе... По мне незаметно откуда я?Есть кто из форумчан кто готов взять на себя задачи взаимодействия с альт-линуксом?
Skull
- drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
- ОС: Slackware-current
- Контактная информация:
Re: защита от вандализма. Блокировка изменения настроек.
что нужно делать?