DevMan

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

--soft сбрасывает коммит так, будто git add на файлы сделан
--mixed сбрасывает коммит так, будто не было git add на эти файлы, это по-умолчанию.
--hard сбрасывает коммит и удаляет изменеия. Но, коммит доступен по своему хэшу, если он не удален gc

"слово1 слово2 -минус1 слово3.1-слово3.2 -минус фраза -минус2"

такое?
(?:^|\s)(-\S+)
https://regex101.com/r/4YJtau/1

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

1. Вам все равно чтобы собрать страницу нужно сделать 5 - 10 - 100 запросов в бд.
Еще один лишний запрос роли совершенно не играет.

2. Если очень нагруженный проект - вполне уместно вынести хранилище этих токенов в какой-нибудь redis.

Я посмотрел основные принципы ООП с точки зрения Алана Кея и не могу понять, чего он хотел.

Неудивительно. Изначально ООП было прежде всего идеей и не имело формального описания, такого как реляционная алгебра для РБД. То, что не имеет формального описания может быть по-разному трактовано и понято, или не понято вовсе.

Да. Этого нет.

Ошибаетесь. Есть аналог "сообщений" - это методы объектов. Вызов метода - это аналог посыла сообщения. Просто вы не привыкли рассматривать это с такой точки зрения. Например, в Objective C, в котором ООП смолтоковского стиля, так прямо и говорят. В языках с Simula-подобным ООП методы не называют сообщениями, т.к. в отличие от Smalltalk-стиля выбор кода для вызова (обработки метода/сообщения) выполняется компилятором, а не самим объектом.

Каждый объект имеет независимую память, которая состоит из других объектов

Пожалуй здесь речь идёт об инкапсуляции.

Стоп. Разве это не то, что я написал в пункте 4?

Нет. В пункте 4 вводится само понятие классификации - что среди неупорядоченного набора всевозможных объектов вы выделяете подмножества объектов, "похожих" друг на друга. Здесь ещё не идёт речи о том, будут ли у них общие методы или ещё что-то конкретно. Речь о самой идее выделения объектов во множества по каким-либо признакам. В пункте 5 уже делается заключение, что если уж мы выделили некоторое подмножество объектов, то грех этим не воспользоваться и не задать одно и то же поведение сразу для всего подмножества (грубовато описал, но как то так и есть).

Если у меня есть класс Dog, описывающий собаку, то от какого мифического единого общего класса она должна наследоваться?

System.Object. Да, вы уже от него унаследовались, прямо или через других предков. С точки зрения среды исполнения не всё чем вы оперируете, является объектом, например примитивные значения. Однако с точки зрения языка можно сказать что int "является объектом" т.к. значение int может быть приведено к типу object. От себя лично скажу, что целесообразность концепции "всё - объект" весьма сомнительна по ряду причин.

Формальный (потенциальный) конфликт в Git в контексте слияния веток - ситуация, возникающая при создании коммита слияния (merge commit), когда один и тот же файл (один или более) имеет различное состояние в снимках (snapshots) сливаемых веток. Такие конфликты можно классифицировать на разрешаемые автоматически и не разрешаемые автоматически.

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

Конфликт, не разрешамый автоматически - формальный конфликт, при котором Git не может самостоятельно сформировать снимок для коммита слияния. Обычно именно такие автоматически неразрешаемые конфликты и называют просто конфликтами. В таком случае для формирования снимка требуется ручное вмешательство (что и называется "разрешением конфликтов" в бытовом смысле).

Не обязателен, а желателен и виртуалка как-раз таки подходит. Но прежде загляни на профильные ресурсы что-бы не наломать дров. Например сюда: https://applelife.ru/

Что теперь делать - незаню.

Взять учебник.

$ javac Untitled-1.java
$ java HelloWorld

Возможно место заняли локальные снапшоты.

Проверить можно так->
sudo tmutil listlocalsnapshots /
Удалить если есть ->
sudo tmutil deletelocalsnapshots com.apple.TimeMachine.2017-10-12-235937
где (com.apple.TimeMachine.2017-10-12-235937) имя снапота

ну и или отключить ->
sudo tmutil thinLocalSnapshots / 10000000000 4
sudo tmutil disable

p/s/ Занятое место лучше смотреть улиткой вроде DaisyDisk

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

1. Ткунть в первого попавшегося. Найденого на ХХ, фрилансе и пр.
2. Попросить рекомендовать спеца у людей которым вы доверяете.
3. Смешать 1 и 2 - попросить рекомендаций у анонимов на разных форумах, например, здесь.
4. Войти в тусовку (например, криптографическая конференция), познакомится с нужными людьми.

и пр. - ну ровно ничем не отличается от других профессий.

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

А зачем на процессоре радиатор? Он тоже низковольтный.

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