С точки зрения физики, никакой разницы в том что вы назвали отраженным светом или источником света, нет никакой. Это одно и тоже.
Можно рассуждать об интенсивности, где ваш отраженный будет обладать интенсивностью стремящуюся к источнику. И все.
Вся эта суета вокруг темной или светлой темы яйца выйденного не стоит по причине того, что на наш зрительный аппарат такие вещи как разрешение экрана, контраст, яркость и частота обновления, влияют на порядки сильнее чем гипотетические рассуждения о типе палитры.
Если с разрешением и частотой все ясно, то в случае контраста и яркости - многое индивидуально. И удивительно, когда люди занимаются выбором палитры в то время когда что первое что второе не адаптировано под индивидуальные особенности. А между тем, именно это является первыми причинами усталости.
Как же так, скажет кто-то, я изменил светлое на темное и мне стало легче. В данном случае не тема виновата, а факт того, что вы косвенно изменили яркость.
Марти Макфлай,
Посмотрите внимательно еще раз видео.
То что ресурсы загружаются - никто не оспаривает. Оспаривается время их загрузки, которое бессмысленно.
Суть любого LazyLoadа в загрузке того что терубется в момент когда это требуется.
То же что сделали с атрибутом loading lazy с точки зрения граничных характеристик - то есть того времени КОГДА он срабатывает делает его бесполезным чуть более чем полностью. По причине того, что что активация процесса загрузки происходит настолько рано, что сводит процесс динивой загрузки к нулю. Он уже не ленивый.
И это я напомню, после того кка удалось уговорить снизить лимиты в два раза.
пол года назад у большинства сайтов вообще не было шансов увидеть ленивую загрузку, потому что грузилось сразу все. Если быть точнее 14 кжранов прокуртки в разрешении 320 x 568 загружались сразу.
И не потому что это была ошибка, а потому что программисты решили что именно такая область должна грузиться сразу. А уж что идет ниже вот то и должно грузиться отложенно.
Еще раз повторяю цифру - 14 экранов.
Забудьте про loading lazy.
Это пример работы сделанной на от-бись со стороны гугла. ссылка на видео, где разобрано по косточкам его работа, а точнее ее отсутствие.
Попробуйте посмотреть что именно висит на 22 порту. Совсем не обязательно что там висит именно ваш sshd
netstat -tpln
попробуйте установить рут кит хантер и посмотреть отсканировать систему и посмотреть что он вам подскажет. В репозитеариях убунты он кажется есть
посмотрите все процессы которые запущены на машине один за одним, не обращайте внимания на названия процессов а смотрите именно откуда какой процесс запущен.
Но все эти процедуры мертвому припарки, если человек был достаточно квалифицирован чтобы установить нормльный ядерный руткит. В этом случае вы не найдете ровным счетом ничего.
Чуть успокою Вас тем фактом, что если бы было именно так, то вы бы не обнаружили запущенное хакером ПО. Кстати вы смотрели от какого пользователя оно было запущено?
так же добавлю, что нередки случае когда компромитацией системы занимается бот, а не реальный человек. И в том случае ваши шансы на то чтобы восстановить систему в оригинальное состояние растут.
В любом случае, у Вас сейчас удивительный шанс подтянуть свои знания администратора системы расследуя этот случай на вашей машине. Дам парочку советов
увидев чужой процесс не спешите его сразу удалять. Узнайте место откуда он запущен. От какого пользователя. В какое время файл был создан сколько времени процесс активен. Попробуйте по разным логам посмотреть что именно происходило в это время.
Нет. Совсем разные.
mysql_insert_id возвратит вам id от последней операции insert в рамках соединения.
SELECT ом же вы получите поcледний id акутальный в базе. Который может и измениться после insert что выше.
В сущности ваш выбор распределяется между двумя основными вещами
sql или nosql решения.
Поскольку опыта, как Вы сами сказали, у Вас нет то, очевидно, и архитектуру Вы спланируете не самую оптимальную. От того идите по течению. Берите самую обыкновенную mysql и набивайте шишки. Если проект взлетит то рефакторинга в будущем Вам все равно не избежать.
В общем случае алгоритм действия такой.
zip архив имеет стандартные заголовки зная их расположения уже можно реверсировать ключ.
Например если я ничего не забыл то первые два байта любого zip архива это 50 4B
что уже вам сразу дает первые два байта ключа. Достаточно сделать xor первых двух байтов вашего файла с 50 4B.
И далее покурить мануалы на тему того как организован формат zip и уже плясать от этого на примере того что выше.
@VitaZheltyakov Дружище. О своей компетенции вы уже заявили выше, не понимая азов. Не хотите внимательно читать документацию поступите проще,
Создайте базу данных InnodDB обьемом больше чем доступная вам RAM
создайте в ней уникальные поля и не уникальные.
Выполните несколько запросов и следите за дисковой активностью. Может тогда наступит просветление.
Ну или включите простую логику, какой смысл будет в индексах в InnodDB если любая операция приводящая к работе с индексами будет приводить к загрузке связанных с ними данными?
@VitaZheltyakov Хранятся в месте, но это совсем не означает что вся база mysql лежит в памяти. При нехватке памяти дынные лежащие в памяти будут удалены, индексы же будут там храниться максимально долго.
@VitaZheltyakov как я и говорил ты не понял описанного. В документации идет речь о том что в myisam запрос вида SELECT COUNT(*) FROM student; специальным образом оптимизированы для максимальной скорости выполнения. Именно такой запрос, без параметров с count звездочка.
Я же пишу совсем о другом. О том как работает сервер mysql с запросами и порядком их выполнения. Если запрос идет по полям которые являются индексами и выполняется count то выборка данных из таблиц не осуществляется а идет подсчет только по дереву индексов. В случае же когда идет не count а есть выборка поля даже если оно проиндексировано это может привести к дисковым операциям в случае если таблица не оказалась в кеше. Данные же индексов, сервер mysql старается держать в памяти всегда. Все еще конечно зависит от того помещаются ли эти индексы в обьем отведенной памяти, но даже если не помещаются это будет означать только то что, сначал будет дисковая операция на получение нужных индексов, а потом следом дисковая операция на получения данных.
нет не будет.
В случае составного индекса mysql нужно только посчитать количество индексов которые в общем случае должны находится в памяти.
Выборка же может привести к дисковым операциям совершенно не нужным в этом случае
Можно рассуждать об интенсивности, где ваш отраженный будет обладать интенсивностью стремящуюся к источнику. И все.
Вся эта суета вокруг темной или светлой темы яйца выйденного не стоит по причине того, что на наш зрительный аппарат такие вещи как разрешение экрана, контраст, яркость и частота обновления, влияют на порядки сильнее чем гипотетические рассуждения о типе палитры.
Если с разрешением и частотой все ясно, то в случае контраста и яркости - многое индивидуально. И удивительно, когда люди занимаются выбором палитры в то время когда что первое что второе не адаптировано под индивидуальные особенности. А между тем, именно это является первыми причинами усталости.
Как же так, скажет кто-то, я изменил светлое на темное и мне стало легче. В данном случае не тема виновата, а факт того, что вы косвенно изменили яркость.
И т.д.