я про другие недостатки ничего и не писал.
но процитированное недостатком не является.
судя по тому, что дальше рекомендуют использовать svnadmin dump и подобное, речь шла не об онлайновых репозиториях :)
речь шла о том, что в истории останется невалидная ссылка на внешний ресурс. то есть совсем о другом речь шла.
это для миграции рабочей копии, чтобы checkout заново не делать.
для изменения свойства в предыдущих ревизиях есть svnadmin setrevprop, та черная магия с переписыванием дампа вручную все равно не нужна.
Разумеется, мы можем работать над всеми проектами/модулями в пределах одного репозитория, но такой подход не лишен недостатков. Например, все разработчики могут загружать к себе в рабочие копии много ненужных изменений. Не получится ограничить доступ разработчикам к тем проектам, к которым у них доступа быть не должно.
/path/to/rep/conf/authz
и настройте для каждого пути свой список доступа.
Если сервер, на который мы ссылаемся, переехал – надо полностью модифицировать репозиторий
никогда не понимал этого фанатизма с проверкой в соответствии с RFC.
имхо, такой фильтр должен пропускать все, что корректно поймет программа, которой мы дальше этот адрес передаем (sendmail, например).
пример: при установке локально всяких движков (для тестирования), требующих email вбиваю адрес admin@localhost
возможно, он «расово неправильный», но отправленное туда через mail() письмо прекрасно доходит куда мне надо.
но некоторые «особо умные» скрипты на это начинают ругаться.
другой пример: новые зоны первого уровня, тот же рф.
проверка все же должна помогать пользователю (что он в поле email нечаянно не ввел что-то другое), а не мешать.
предположим, по одной дороге прошло 100 обладателей карт со скоростью 5км/ч каждый.
а по соседней — 50 со скоростью 5км/ч, еще 30 — со скоростью 20км/ч, еще 20 — со скоростью 40км/ч.
1. вы сможете определить, на какой из дорог пробка?
2. вам для этого обязательно надо знать, кто есть кто?
для тех, кому phpmyadmin кажется слишком громоздким и тормозным, и не хочется ставить десктопный софт, есть замечательный проект под названием phpMiniAdmin (один файл весом в 26к)
давно использую только его, с рядом своих патчей (например, экспорт/импорт в sql.gz на лету)
Таким образом, не снижая стойкость алгоритма более 16 бит (а по моему твердому убеждению для 128-битных хеш-функций – это никак не скажется на практической их стойкости на ближайшие скажем 25 лет)
допустим, разрядность снизилась на 16 бит.
(иными словами, возможных хэшей стало в 216 раз меньше)
время вычисления хэша одной строки (по вашим данным), при этом можно увеличить в 130000 ~= 217 раз.
непонятно, почему вообще идет речь о снижении стойкости, если среднее время на поиск коллизии для заданного хэша (опять же, исходя только из ваших данных) только возрастет в ~2 раза.
и что же такое надо спросить, чтобы ответом на это было что-то типа fweklnfo34njkrnjfnwmnv43?
разве что «побейся лбом о клаву и напиши результат», но ответ вряд ли подойдет с 1-й попытки =)
в марафонах совершенно необязательно сидеть по 24 часа в сутки все 2-4 недели.
по крайней мере в первых раундах на написание достаточно хорошего для прохождения дальше решения хватает 2-3 дней.
хотя 24-часовой финал в этом году (против 8-ми часового в прошлом) — это мощно =)
если пользователь хочет — пусть вводит мыло, подтверждает его и соглашается с получением спама тем, что угон мыла приведет к угону аккаунта и на сайте.
(кстати, это наиболее частый способ кражи аккаунтов в том же жж)
зачем эту очевидную дыру в безопасности делать принудительной — не очень понятно.
есть менее уязвимые способы не забывать пароль.
можно пойти еще дальше и отказаться, наконец, от обязательного ввода email-а с его обязательной проверкой.
2010-й год все-таки уже, а не 1995-й, когда зарегистрировать новый ящик было тяжело и этим реально какая-то «подлинность» пользователя проверялась.
далеко не у всех есть желание светить свой адрес на всех сайтах подряд, популярность сервисов типа mailinator и bugmenot тому подтверждение.
по-человечески и «полдень» должен наступать, вы не поверите! в 12:00, а не в 13:00 зимой и 14:00 летом, как сейчас (в мск/питере).
то есть «издевательство» в смысле несоответствия «привычных» показаний на часах солнцу УЖЕ есть.
тем не менее, никто это издевательством над собой не воспринимает, это исключительно дело привычки.
отвечая на ваш вопрос: видимо, только над теми, для кого время, например, окончания работы в любом регионе всенепременно должно называться «шесть вечера» и никак иначе.
вы полностью прочитали комментарий, на который отвечаете, или только первое предложение?
если все делать по-человечески, а не так, как у нас в стране, к сожалению, принято, никто по ночам работать не начнет.
лучше бы отменили эти часовые пояса вообще вместе с летнем временем.
идея привязки времени на часах к солнечному и так уже вовсю трещит по швам, предмет этого топика тому пример.
мне кажется, в какой-то момент станет проще единоразово пересмотреть графики работы и прочего в разных регионах, чем дальше мучаться с пересчетом времени туда-сюда.
т.е., например, для бывшей UTC+4 сдвинуть их все на час назад, а не сдвигать часы вперед, эффективно это будет то же самое, никому реально вставать раньше/позже не придется.
1. не надо искать скрытых смыслов там, где их нет.
дано значение функции в нескольких точках:
14 — -24
15 — -26.5
16 — -27
…
и вопрос, в скольких точках значение находится в диапазоне (-26, -21.5), имеет ровно один ответ — 7.
да, есть неточность, т.к. не указано, включаются ли концы, но числа подобраны так, что на ответ это не влияет.
3. если вся задача заключается в том, чтобы поделить два числа и написать ответ, мне кажется, она включена вовсе не для проверки умения пользоваться калькулятором, а именно для проверки знаний правил определения значащих цифр.
то есть ответ 2.1 верен, а ответ 2.12, равно как и 2.119353039598438 — нет.
это школьная программа, как минимум меня за это в свое время пинали.
но процитированное недостатком не является.
судя по тому, что дальше рекомендуют использовать svnadmin dump и подобное, речь шла не об онлайновых репозиториях :)
это для миграции рабочей копии, чтобы checkout заново не делать.
для изменения свойства в предыдущих ревизиях есть svnadmin setrevprop, та черная магия с переписыванием дампа вручную все равно не нужна.
/path/to/rep/conf/authz
и настройте для каждого пути свой список доступа.
svn switch --relocate
имхо, такой фильтр должен пропускать все, что корректно поймет программа, которой мы дальше этот адрес передаем (sendmail, например).
пример: при установке локально всяких движков (для тестирования), требующих email вбиваю адрес admin@localhost
возможно, он «расово неправильный», но отправленное туда через mail() письмо прекрасно доходит куда мне надо.
но некоторые «особо умные» скрипты на это начинают ругаться.
другой пример: новые зоны первого уровня, тот же рф.
проверка все же должна помогать пользователю (что он в поле email нечаянно не ввел что-то другое), а не мешать.
а по соседней — 50 со скоростью 5км/ч, еще 30 — со скоростью 20км/ч, еще 20 — со скоростью 40км/ч.
1. вы сможете определить, на какой из дорог пробка?
2. вам для этого обязательно надо знать, кто есть кто?
а почему это лучше, чем mysqldump db >dump.sql && gzip dump.sql?
быстрее отработает дамп => меньше времени заблокирована запись в базу, нет?
about:config
network.standard-url.escape-utf8 = false
и не надо никаких убогих сокращалок.
давно использую только его, с рядом своих патчей (например, экспорт/импорт в sql.gz на лету)
допустим, разрядность снизилась на 16 бит.
(иными словами, возможных хэшей стало в 216 раз меньше)
время вычисления хэша одной строки (по вашим данным), при этом можно увеличить в 130000 ~= 217 раз.
непонятно, почему вообще идет речь о снижении стойкости, если среднее время на поиск коллизии для заданного хэша (опять же, исходя только из ваших данных) только возрастет в ~2 раза.
разве что «побейся лбом о клаву и напиши результат», но ответ вряд ли подойдет с 1-й попытки =)
по крайней мере в первых раундах на написание достаточно хорошего для прохождения дальше решения хватает 2-3 дней.
хотя 24-часовой финал в этом году (против 8-ми часового в прошлом) — это мощно =)
получением спаматем, что угон мыла приведет к угону аккаунта и на сайте.(кстати, это наиболее частый способ кражи аккаунтов в том же жж)
зачем эту очевидную дыру в безопасности делать принудительной — не очень понятно.
есть менее уязвимые способы не забывать пароль.
вы еще паспорт потребуйте.
такие отсечения решают только проблему «мне надоели лишние пользователи» =)
2010-й год все-таки уже, а не 1995-й, когда зарегистрировать новый ящик было тяжело и этим реально какая-то «подлинность» пользователя проверялась.
далеко не у всех есть желание светить свой адрес на всех сайтах подряд, популярность сервисов типа mailinator и bugmenot тому подтверждение.
то есть «издевательство» в смысле несоответствия «привычных» показаний на часах солнцу УЖЕ есть.
тем не менее, никто это издевательством над собой не воспринимает, это исключительно дело привычки.
отвечая на ваш вопрос: видимо, только над теми, для кого время, например, окончания работы в любом регионе всенепременно должно называться «шесть вечера» и никак иначе.
если все делать по-человечески, а не так, как у нас в стране, к сожалению, принято, никто по ночам работать не начнет.
идея привязки времени на часах к солнечному и так уже вовсю трещит по швам, предмет этого топика тому пример.
мне кажется, в какой-то момент станет проще единоразово пересмотреть графики работы и прочего в разных регионах, чем дальше мучаться с пересчетом времени туда-сюда.
т.е., например, для бывшей UTC+4 сдвинуть их все на час назад, а не сдвигать часы вперед, эффективно это будет то же самое, никому реально вставать раньше/позже не придется.
дано значение функции в нескольких точках:
14 — -24
15 — -26.5
16 — -27
…
и вопрос, в скольких точках значение находится в диапазоне (-26, -21.5), имеет ровно один ответ — 7.
да, есть неточность, т.к. не указано, включаются ли концы, но числа подобраны так, что на ответ это не влияет.
3. если вся задача заключается в том, чтобы поделить два числа и написать ответ, мне кажется, она включена вовсе не для проверки умения пользоваться калькулятором, а именно для проверки знаний правил определения значащих цифр.
то есть ответ 2.1 верен, а ответ 2.12, равно как и 2.119353039598438 — нет.
это школьная программа, как минимум меня за это в свое время пинали.