Дмитрий

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

Ссылка тоже занимает место, так что в случае int и других маленьких объектов (которые влезают в машинное слово) дешевле передавать значение (как по памяти, так и по времени).

Да и выделение/освобождение памяти в куче дороже, чем выделение/освобождение памяти на стеке. (зато меньше риск получить висячий указатель или stack overflow)

Хороший вопрос содержит половину ответа :)

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

В целом, в С++ хорошее правило - передавать большие переменные как const &.

Но для мелких типов, вроде int, передавать по ссылке может быть даже дороже, ибо и ссылка и значение тупо помещаются в регистр. Но ссылку надо будет еще разыменовывать, чтобы прочитать значение из памяти, а значение из регистра компилятор может даже не сохранять в память.

С другой стороны, компилятор может наоптимизировать и даже ссылка на int будет не дороже копии int.

Сразу говорить про все языки программиования нельзя. В некоторых языках вообще все передается по ссылке, в других вообще нет разницы для мелких типов.

загрузил ПО на свой ноутбук

нужно не загрузить а установить.

У тебя liveusb версия, в ней на рабочем столе есть иконка - устновка (install), откроется мастер, где можно указать на какой диск устанавливать, и главное, куда прописывать загрузчик (нужно будет выбрать диск, загрузчик называется grub).

Еще момент, некоторые (все чаще вижу) производители материниских плат, скорее всего по требованию майкрософт, ломают процедуру настройки загрузочных записей UEFI, таким образом, что бы только установщик windows мог его менять (т.е. записываешь загрузочную запись, биос отвечает что все ок, записалось, но после перезагрузки все возвращается назад, а если это сделать из windows setup то все работает), в этом случае загрузчик придется создавать вручную из windows. Так же альтернатива, перевести bios в режим загрузки не UEFI а CSM (это еще может называться Legacy MBR или Legacy DOS или compatibility), что бы этот режим работал, нужно будет либо создавать тип разбиения дисков DOS (когда 4 раздела только можно, и лимит размера диска 2тб) либо в режиме GPT добавлять еще один раздел (настоятельно рекомендую в первых секторах) - biosboot.

grub по умолчанию пытается установить оба доступных режима, и UEFI и CSM (если биос не будет загружен в режиме UEFI то будет доступна установка только CSM)

Установить загрузчик можно вручную после установки, из командной строки linux:
grub-install /dev/sda --root-directory=/mnt

тут /dev/sda - это диск, на котором должен быть загрузчик (раздел biosboot либо диск с разбиением dos, если есть UEFI то нужно еще 100мб EFI загрузчик, диск типа efi boot и отформатированный fat32), а /mnt это диск, в который нужно вручную смонтировать установленную ОС (причем если она состоит из нескольких разделов, то смонтировать все, включая /mnt/boot/EFI раздел efiboot)

p.s. повторюсь, тебе нужны разделы - biosboot (автоматически 1мб), efiboot (минимум 100мб), опционально /boot (обычно не меньше 500мб, и в 99% случаев он не нужен) и корневой /
Это все можно сделать из мастера установки, когда будет предложено выбрать диск для установки (там будет отображены все диски и нужно будет указывать какой раздел какой точкой монтирования / или /boot является)

Да, вполне могла в результате короткого замыкания питания USB. Могла сработать защита порта USB и/или блока питания по линии 5 Вольт. А если нет защиты — то мог сгореть USB контроллёр и вполне возможно дальше по цепочке ещё что-нибудь сгореть и замкнуть могло.

Простой пример. Скрипт ежесуточно создаёт папку с текущей датой в названии и делает на неё символическую ссылку /some/directory/today. В настройках программы /some/directory/today указана как папка для сохранения каких-то файлов. В результате файлы каждый день сохраняются в отдельную папку, а программе не надо менять настройку.

youtube.com
youtu.be
yt.be
googlevideo.com
ytimg.com
ggpht.com
gvt1.com
youtube-nocookie.com
youtube-ui.l.google.com
youtubeembeddedplayer.googleapis.com
youtube.googleapis.com
youtubei.googleapis.com
yt-video-upload.l.google.com
wide-youtube.l.google.com

Могу ответственно подтвердить как разработчик обходов)

Символ # является спецсимволом, который требуется кодировать как %23.
По-хорошему ваша ссылка должна выглядеть вот так:

http://site.ru/dw/?url=https%3A%2F%2Fmega.nz%2Ffile%2Fe8hzUIJS%23eE1Nb6VdmFmtF2YlgO8a25X09l_fa9uxtTOjNNBgIS

В этом примере кодированы все спецсимволы, а не только #. Такой вид ссылки гарантированно будет работать так, как вы хотите.

В php за подобное кодирование отвечает функция rawurlencode().

На выбор, в зависимости от сценария и задач:
wget
curl
lynx ( спасибо AUser0)
openssl (что бы проверить валидность сертификата)

Сам по себе ping не может говорить о доступности ресурса (может не работать ping, а ресурс работать. И наоборот)

Blade в этом плане сложен - он "компилируется" в настоящий php и кэшируется, поэтому реальный стек сложно сопоставить с исходником.

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

$cats=$site->qa("select * from categories where catid=0  order by name asc");

Тогда они будут простыми и ошибку будет сложнее совершить и гораздо легче найти. А если она случится в контроллере, то там уже трейс будет нормальный.
Использовать нормальный фреймворк, но при этом писать в нём код так, как будто на дворе до сих пор PHP 5.2 - это странно.

обслуживание необслуживаемых систем - это для энтузиастов?

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

С точки зрения простоты и безопасности лучше купить новую СВО.

Нет, не стоит. Риск залить ПК водой есть в любой системе водяного охлаждения. Необслуживаемые водянки - чисто маркетинг, а по факту они со временем тоже изнашиваются: помпа обычно встроенная и замене не подлежит - так что когда она сломается (механика же) придётся покупать целиком новую систему, а радиатор обычно внутри забивается в результате коррозии - там обычно внутри такая же вода с присадками и оно всё равно потихоньку взаимодействует. В то же время в обычном воздушном кулере менять надо только вентилятор, и то если это не почти вечные ноктуа. Абсолютное большинство водянок — обычный маркетинг с целью заработать денег (особенно с хрупкими акриловыми крышками, которые трескаются на раз как от затяжки болтов так и от времени из-за нагрева).

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

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