- 1
- 2
- 3
- 4
- 5
- 6
if ($result->fetch()) {
return $result->get('num_flags');
}
else {
return 666;
}-
PHP / Говнокод #14237
+149
Верующий программист :)
Запостил:
xakip,
17 Декабря 2013
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Не, число же не восьмиричное. Да и 666 не особо хорошие права, больно уж свободные. Обычно все-таки ставят 664 или даже 644.
http://askubuntu.com/questions/44187/how-do-i-move-the-unity-title-bar-buttons-to-the-right-side
>> в реестре
Тонко.
Ага, а потом конфиг самоуничтожается вместе с репозиторием программы.
Да вот хуй бы знал, стоит ли... Конфиги же в основном читаются при старте прог, да и не так уж долго парсятся на современном железе. Ну да, будет на несколько миллисекунд быстрее грузиться... А оно надо?
Имхо, если уж менять на какую-нибудь иерархическую бд, то совсем не из-за скорости, а из-за унификации самих конфигов и работы с ними.
Вобяз потребуется встроенное и неотключаемое версионирование (не банальные снепшоты аля .reg, а полноценный контроль версий), чтобы можно было откатывать кривые изменения, или что-нибудь тестить или ставить без боязни запороть все к хуям.
И в идеале нужен в какой-то форме контроль полномочий. Чтобы приложения не могли править (и даже смотреть) конфигурации друг друга, если им это не было явным образом разрешено.
Тогда профит может быть и будет...
> Тогда профит может быть и будет...
В таком виде и на винде профит будет. Только не заебет ли вопросами?
Ну если сделать грамотные дефолты - не заебет.
Например каждой паре (пользователь; приложение) выделяем приватную ветку, в которой они могут делать что хотят. Другие приложения и пользователи к ней доступа не имеют, если исходное приложение не разрешит. Ну разве что кроме специально помеченного софта в духе regedit'а. И никаких вопросов не будет.
А насчет вопросов о том, как назвать коммит - обязать проги, которые вносят изменения в "реестр" работать в транзакциях, и давать каждой из них название. Например "установка проги firefox" или "изменение разрешения экрана" или "прописал виря в автозагрузку". Тогда пользователю не придется все это вбивать, но он всегда сможет понять, что, зачем, и какой прогой было изменено...
Инфа скольки %?
Ну названия будут даваться на отъебись, а какой будет размер лога транзакций, если прога пишет в реестр раз в 5 секунд?
А х.з. я же пока не продумывал концепцию, и запиливать ее не хочу. Просто обсуждаем ее с тобой. К концу дискуссии определимся ;)
> если прога пишет в реестр раз в 5 секунд?
Можно сделать для веток флаг запрета логирования для таких случаев. Вешаешь на ветку, и она не логируется. Ну и флаг нетранзакционности до кучи, если нам похуй на сохранность этой ветки при жестком ребуте, но нужна большая скорость записи...
> названия будут даваться на отъебись
Ну с этим ничего не поделать. Но по крайней мере какая-нибудь айдишка или название этой уебанской проги останется в журнале. Ну и дата изменения.
угу :) получится как с самим реестром - идея может и хороша, но детали (что говнопрога может засрать весь реестр) ее убивают.
>Можно сделать для веток флаг запрета логирования для таких случаев.
Дрейф в сторону слива.
Что-то из этого сделать можно, а что-то не реализуемо. Изолированные настройки можно было бы попробовать. Еще бы сделать легкий перенос отдельных настроек при переустановке Шиндовс.
Она и сейчас может это сделать ;) Так что хуже уже не будет. На крайний случай можно замутить квоты.
> Дрейф в сторону слива.
Почему? В сторону слива была бы возможность указывать это при старте транзакции. А так, например, те же файловые ассоциации или автозапуск ты никак не сможешь поменять без логирования. И переключить флаг не сможешь, т.к. права на это только у создателя ветки, а это не ты.
> а что-то не реализуемо.
А что именно нереализуемо?
> Еще бы сделать легкий перенос отдельных настроек при переустановке Шиндовс.
Это да, интересно было бы. Но тут куча проблем... Настройки то перенести можно, но будут ли они иметь смысл на свежей оси? Те же пути могут оказаться сбитыми и т.п. Каких-то зависимостей не будет установлено. Короче тут явно нужна поддержка со стороны самого софта.
Я не пойму идею - разные настройки для разных веток?
>А что именно нереализуемо?
От многого пахнет фейлом вроде журналирование всех подряд изменений.
>Короче тут явно нужна поддержка со стороны самого софта.
Будет лет через 10 мб. Хотя с UAC некоторые до сих пор не дружат, а некоторые его тупо вырывают с мясом, ставя софт в %appdata%
Вот какого черта у меня автоматом добавляется английская раскладка?
Да. И менять их может только владелец ветки, т.к. он знает для чего она нужна и как ее будут юзать.
> От многого пахнет фейлом вроде журналирование всех подряд изменений.
Ну большая часть реестра же очень редко меняется. И мне хотелось бы, чтобы она журналировалась. Хотя бы на какой-то период, допустим пара месяцев.
Понятно что всякую хуйню, типа recently used и статистики не стоит логировать.
А вот для ассоциаций файлов, автозапуска, настроек всякого софта журнал явно не повредит.
А если прога решит писать настройки раз в 5 секунд, что делать бум?
>А вот для ассоциаций файлов, автозапуска, настроек всякого софта журнал явно не повредит.
Ну это вообще реализуется внешним софтом. Есть автобекапилки реестра.
Вспомнил. У одного меня настройки сохраняются в реестре только при выходе из винды?
Хм, да, кривожопые проги это проблема. Может квоты тогда делать не на объем данных в реестре, а на объем проведенных транзакций? Типа 5 метров в месяц (если журналы держатся месяц) на прогу, если юзер не согласился на большее.
Если прога выжирает лимит - сама виновата.
> Есть автобекапилки реестра.
Ну да, это тоже решает проблему :)
Ну как, появилось?
Ну как бы Mandatory Access Control уже изобрели и даже запили несколько реализаций.
Вообще хотелось бы видеть ограничения для программ примерно как в андроиде. И ведь сейчас это реально сделать - взаимодействие через dbus настраивается (и вроде работает с selinux), доступ к конфигам, .gpg и прочим нужным вещам запрещается.
Для доступа в ФС можно запилить диалог, который выполняется в отдельном процессе и может разрешать приложения читать/писать определенный файл. Но как быть с запуском вида vlc yast-another-pron.mkv я хз.
Ну вот в виндовом реестре он на уровне пользователей. А хотелось бы на уровне пары (пользователь; приложение).
> Но как быть с запуском вида vlc yast-another-pron.mkv я хз
Ну как вариант - чтобы проги могли передавать доступ к файлу или ветке реестра. Т.е. если cmd или bash имеет доступ к файлу, оно может временно, не меняя флагов на фс, разрешить vlc поюзать этот файл.
ну это не помешает какому-нибудь огороженному приложения вызвать rm -rf /*. Лучше запихать приложение в домен и не выпускать из него и все дочерние процессы тоже будут ограничены именно этим доменом
*Ушел курить про контроль доступа
Начиналась «Windows» как графическая оболочка для «DOS». Т. е. по сути как чисто клиентская питушня.
Потом появилась «NT» — серверная система, но сделанная по мотивам клиентской питушни: с гуём, сидящим глубоко в кишках, даже в сетевые сокеты зачем-то нужно передавать дескриптор окна.
Потом слепили 95 — домашнюю однопользовательскую систему, но с API, похожим на «NT».
После выпуска Me однопользовательские системы делать перестали. Все последующие системы «для дома» — стали делать на основе «NT» — по сути многопользовательской серверной системы. Даже если XP/Vista/7/8/10 называется «Хоум Эдишон», она всё равно многопользовательская.
Где-то к 4.0 стало понятно, что всё равно писать все будут под Win32API, а переключать GDI туда-сюда (в юзерспйс и обратно) -- дорого!
Тогда-то и занесли GDI в kernel space. Само ядро конечно про GUI ничего не знает, но win32k.sys -- драйвер для реализации win32 в кренелй спейсе -- знает
Описанная мною проблема, когда ОС защищает себя от своего пользователя, но не пользователя от программ, характерна и для других многопользовательских ОС
Во-во. Нужна изоляция программ и чтобы при деинсталляции все их следы пребывания выдирались с мясом. Тогда и переустановка шиндовс может не понадобиться.
Можно прям галочки.
☑ Я согласен, что эта прога может поиметь мой комп.
☑ Я согласен, что эта прога может испортить ось.
☑ Я согласен, что эта прога может повредить работоспособность других программ.
☑ Я согласен, что изменения, внесенные этой прогой будут необратимыми и не будут отменены после ее удаления.
☑ Я в здравом уме и твердой памяти хочу запустить эту прогу и осознаю все возможные последствия.
Я согласен. А с другой стороны, может быть и не будут, если таких прог будет мало.
Ну не требовать же разрешения от разрабов оси, как это делали в симбиане?
☑ Я согласен, что эта прога может поиметь мой комп.
☑ Я не согласен, что эта прога может поиметь мой комп.
☑ Я согласен, что эта прога может поиметь мой комп, но не надо её устанавливать.
☑ Я знаю, что эта прога может поиметь мой комп, и хочу её установить.
☑ Я знаю, что эта прога может поиметь мой комп, и хочу её не установить.
☑ Я знаю, что эта прога может поиметь мой комп, и категорически против завершения процесса её неустановки.
http://www.gamedev.ru/files/images/pilot.jpg
Я человек добрый, помогу тебе извести их до конца побороть твой страх перед холодильником. Держи:
http://jsfiddle.net/5uNEW/1/
Да этот код можно сразу на гк выкладывать ;)
Ай-ай-ай, фу-фу-фу
Какой алгоритм придумал?
Кстати, это идея. Надо придумать авторешатель
Ну когда я первый раз в нее играл - я тоже рандомом натыкал ;)
А сейчас, в принципе, алгоритм очевиден.
Если прокликать строчку и столбик (7 кликов, т.к. в пересечение тыкаем 1 раз), то переключится всего один флажок на их пересечении.
Если выщелкивать все флажки таким способом, то получается, что в каждую клетку надо тыкнуть столько раз, сколько она "видит" включенных флажков (клетка "видит" свою строчку, свой столбик и саму себя). Т.к. больше одного раза кликать бессмысленно, берем все по модулю 2.
И получаем тупейший алгоритм: ищем клетку, которая "видит" нечетное количество флажков и тыкаем в нее.
Хм, интересно, а можно ли это формально доказать?
Так то можно тупо прогнать прогой все 65536 вариантов и убедиться или опровергнуть. Но это читерство ;)
Прогнал, проверил. Двух раз всегда достаточно. Три не нужно никогда, ну если я в проге не накосячил ;)
Черезжопное доказательство на хаски:
http://ideone.com/BjP6j7
100*100 решил за 9960 ходов
> Пока я искал его уже Хаски поведал)
Да, для нечетной (по крайней мере для трех) он зависнет на втором проходе:
http://ideone.com/psR0LW
А чем мой алгоритм не нравится? Он гарантированно решает за не более чем N*N кликов для поля N*N :)
твой - за (2*N) * количество чекнутых
в итоге твой в хучшем случае решает за 2*n*n*n в среднем - за тот же n*n*n а мой за N*N
Откуда столько кликов? Может ты его не до конца дочитал?Не более N*N кликов и ровно N*N*(2*N+1) взглядов на клеточки.
И работает на любых полях.
Хуй. Мой тоже виснет. Может быть нечетные поля тупо неразрешимы?
Короче надо доказывать, что для нечетных полей нет алгоритма, который переключит ровно 1 флажок. Ибо если такой алгоритм есть - то из него вытекает разрешимость любой ситуации. Если же такого алгоритма нет - множество всех состояний распадется на несколько подмножеств, недостижимых друг из друга. И задача становится разрешимой не во всех случаях (что мы и видим на опытах).
Для четных полей такой алгоритм существует - "прокликать строчку и столбик, тыкая в пересечение только один раз". Поэтому они разрешимы всегда.
ты просто писал
> Если прокликать строчку и столбик (7 кликов, т.к. в пересечение тыкаем 1 раз), то переключится всего один флажок на их пересечении.
я дальше читать не стал - сделал вывод и пошел кодить)
Думал твой переписать для 5 на 5 и потыкать - ан нет
Тыкай: http://www.bormand.tk/
неси зачётку!
#~~~~
~~~~~
~~~~~
~~~~~
~~~~~
А оттуда уже все, никак
замечание: либо не всегда, либо факт сведения не влияет на разрешимость
помнится на старой работе сделал фичастый кросс-платформенный "реестр"
без откатов и версионности, конечно, но реально кросс-платформенный, типизированный, с сетевым доступом, с листенерами изменений, вешаемых на узлах/листьях дерева
с бекендом под виндой в виде родного реестра, и под линухом в виде демона с бд в виде набора xml-файлов (корневой xml мастер-файл, в котором произвольную ноду - которая будет часто обновляться - можно сослать в отдельный файл)
ну и сетевой доступ тоже как бекенд
клёво было....
Да, вот это я забыл. Очень годная фишка, чтобы не перечитывать весь конфиг по таймеру/изменению файла, и не пинать лишние утилитки...
> без откатов и версионности, конечно
Ну хотя бы лог операций поди можно было включить? :)
Так что можно завести по файлу на параметр. Может не очень быстро работает, но зато быстро пишется. директории за путь, имена файлов за ключи, содержимое за данные. тут тебе и версионность в некоторые фс встроена, бекапы. и быстрый поиск файлов, а не перебор за О(n). и даже права. и даже кеширование. и самовосстановление
Ололо диванный кукаретик.
>а не перебор за О(n)
Это где?
Ну так кто мешает загрузить его в хешмап за O(n) и искать за O(1)?
ФС не самое лучшее средство для таких целей. Они не особо любят много файлов в одном каталоге, имеют ограничения по длине пути и т.п..
Хотя да, такая схема работала в реестре гнома 2.
Считай что я писал зеленым. Под линупсом я бы взял Redis
А ничего, что количество watcher'ов ограничено?
> и даже права.
Права не совсем такие, как хотелось бы. На уровне юзеров. Ну разве что по-андроиски поступить: одна прога - один uid.
Ну для чего-то может и не чо
Это как?
Ну там для каждой софтины при установке заводится свой "пользователь" (это в линухе практически бесплатно - домашная папка, да где-то хранить целое число с uid'ом "юзера"). За счет этого как раз проги не могут лезть в папки друг к другу.
>Ну там для каждой софтины при установке заводится свой "пользователь"
Эт на серваке чтоли? Потому что по другому нормальную изоляцию не сделать.
Ты не поверишь, но я сейчас рассказывал об андроиде ;)
> размер uid-а какой
32 бита вроде. Ну по крайней мере sizeof(uid_t) выдает 4 байта даже на x86_64.
Ну во-первых на андроиде для общения между прогами есть вполне кошерное IPC, и лазить в папки это уже самый крайний случай. Во-вторых прога вроде бы может поменять права на какой-нибудь свой файл, чтобы другая прога могла его трогать. Но я это не проверял.
На своем же серваке можно просто никсовыми правами на уровне фс разрулить кто именно и куда может лезть. Так то в линухе и ACL есть, как в винде, если не хватает классической owner-group-other.
> И как пользователи определяют, нужно лезть в чужие настройки или нет?
На андроиде, емнип, никак. На серваке - админ само собой решает что и как должно быть.
во-вторых, файл на каждый числовой параметр - это плохое использование ресурса, особенно когда вместо диска - флешка со всеми вытекающими на 128М под всё
ну и в третьих, поддерживать такие конфиги не очень приятно - особенно, когда надо "закоммитить" в "реестр" сразу пачку настроек - в т.ч. удаления ключей
а так собсно весь вопрос в ещё одном бекенде, всего-то
ну т.к. там в любом случае клиент-сервер, то на сервере можно допилить что угодно
не вставала задача транзакционности просто, acid был ни к чему
Вполне могут быть в NT