Сергей delphinpro

phpfaq.ru/newbie/paths

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

С появлением вычислительной техники всё изменилось. Неважно, каким запутанным для человека является шифр, машина может очень эффективно проверить хоть миллион разных "классических" вариантов с самыми разными алгоритмами и ключами. Тут даже алгоритм скрывать бесполезно, если его можно угадать подбором и комбинированием.

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

Тут

Никак.
Тостер - коллективный ресурс, поэтому участие в отметке решением могут принимать все.
Миссия Тостера - создание базы знаний, в первую очередь и только потом решение конкретных проблем конкретных людей. Поэтому отметки сообществом имеют приоритет* над отметками задающих вопрос.

Если вас по какой-то причине не устраивают ответы, напишите об этом в комментариях к ним, чтобы те, кто придут в вопрос из поиска понимали их ограничения и возможные подводные камни.

* концептуально, не помню как технически это всё организовано.

Margin-right auto для первого

Классы пишутся через пробел
<div class="container-fluid hero">

Использую по возможности всё что есть в Sass и хотелось бы видеть в нём больше. Активно использую и переменные и миксины и функции и placeholder'ы и list'ы и map'ы и т.п. Многие практические задачи намного легче решаются через препроцессор, те же CSS variables ни разу не замена.

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

Вопрос поддерживаемости - он не лежит в плоскости используемого инструмента, а является следствием наличия или отсутствия архитектуры в проекте. Если макеты дизайнера сделаны в стиле "я так вижу", без внутренней логики, если всё это сверстал верстальщик по принципу "что вижу - то и сверстал" - то никакое наличие или отсутствие препроцессора на поддерживаемость кода не повлияет.

С другой стороны наличие определённой архитектуры и следование ей в проекте даёт возможность относительно безболезненного рефакторинга стилей и оставляет код стилей поддерживаемым и расширяемым. Препроцессоры здесь только на пользу.

Какой-то конкретной цели, объясняющей для чего мне это надо, пока что нет.

- Скажите пожалуйста, куда мне отсюда идти?
- А куда ты хочешь попасть? - ответил Кот.
- Мне все равно... - сказала Алиса.
- Тогда все равно куда и идти, - заметил Кот.
- ...только бы попасть куда-нибудь, - пояснила Алиса.
- Куда-нибудь ты обязательно попадешь, - сказал Кот. - Нужно только достаточно долго идти.

Льюис Кэрролл

Как там на луне дела?

Функции mysql_connect уже 5 лет как нет в языке. И предупреждать об этом начали 10 лет назад.

в /system/database/drivers/ надо поискать какой-нибудь другой драйвер

Кнопка.

Семантика дизайна очень проста:
- кнопки выражают действие
- ссылки ведут на страницы

Соответственно, "добавить в избранное" - это действие.
Как и "зарегистрироваться", "найти" и т.д.

все так говорят, когда начинают переходить с css на препроцессоры... )

Технически Pardon Me! Where Do I Find 4giveness?, прав, но в контексте вопроса есть нюанс.

В РНР используется механизм copy-on-write. То есть по умолчанию дублированная переменная является таки ссылкой на оригинал. И только если начать её изменять, она скопируется физически.

В данном случае это означает что если только перебирать значения, читая но не изменяя их, то фактически, по расходу памяти, это будет как будто передача по ссылке.
А вот если изменять значения массива - то тогда да, размер потребляемой памяти удвоится.

Вот я даже примерчик набросал для иллюстрации

Другое дело что если выборка из БД настолько большая, то просто не следует выгружать сразу массивом, а надо перебирать строки по одной, старым добрым fetch() в цикле. И не забыть использовать небуферизованный запрос. В этом случае, даже если мы в итоге будем собирать массив, памяти будет израсходовано под 1 массив, а не 2(3) (1 под результсет, 1 массив из БД и 1 - опционально - если мы изменяем исходный/генерим новый)

Если отличия стилистические, то есть, можно предположить что в любом месте можно использовать один из двух вариантов, то лучше делать через модификатор с ключем и его значением. Например:
socials_theme_ligth
socials_theme_dark
где theme это ключ, а ligth и dark его значения, которые не могут быть использованы одновременно на одном блоке.
Для остальных изменений, которые необходимо внести только в footer мы применяем микс. К примеру нам нужна светлая тема, но в футере необходимо добавить отступ сверху или еще какие-то изменения в данном контексте. Выглядеть это может вот так:

<ul class="footer__socials  socials socials_theme_ligth">
...
</ul>

.socials {
  color: #000;
}
.socials_theme_ligth {
  color: #fff;
}
.footer__socials  {
  margin-top: 100px
}

Чем обусловлена замена северного и южного моста чипсетом?

Вопрос не имеет смысла.
Чипсет - набор (set) микросхем (chip) - обеспечивающих работу процессора.
Северный и южный мост - название некоторых блоков чипсета.

В итоге серверный и южный мост это часть чипсета. Никто ни чем их не заменял.

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