В гите есть только указатели на коммиты. А бранчи все выдумывают пре-коммит хуками кто во что горазд.
Вы тут "бранчами" называете теги сообщения коммита, которые показывают, в рамках какой разработки был сделан коммит. Ни в Git ни, на самом деле, в Hg это не нужно, если есть возможность писать его в сообщении коммита - что всегда и делается в процессе уровня больше чем "я и моя собака".
Как сами меркуриаловцы признают, "The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." В результате получаются ситуации типа "Две ветки-2 в пределах ветки-1 (не путать с веткой-3)" (ветка-1 это его внутренний branch, ветка-2 это безымянная голова, ветка-3 это bookmark).
Я уж не говорю о том, что он каждыйпо коммит хранит целым снепшотом состояния репозитория, а не просто диффом изменённых файлов
А это _в основе_ единственно правильный вариант (ну не учитываем, что объекты могут представляться в виде дельт, это уже вопрос сжатия репы). Трекинг копирования/переименования должен делаться уже отдельно поверх него.
Представление, где каждый каталог и файл представляются хэшом и собственно найти изменённые файлы между коммитами - это очень экономная операция (все случаи разных хэшей отбрасываются из сравнения), позволяет как раз очень экономно определять набор тех файлов, в пределах которых надо вести трекинг уже по их содержимому.
Для сложных случаев типа "переместили 200000 файлов и при этом изменением `#include <moo/foo/boo/boo.h>` на `#include <util/moo/foo/boo/boo.h>` поменяли их хэши... ну да, можно было бы придумать какие-то подпорки. Но, насколько видим, это даже для крупных реп не составляет большой проблемы.
а для отображения диффа и мёржа ему приходится опять же угадывать, где какие были изменения сравнивая разные снепшоты.
Ну и очень хорошо угадывает.
Опять же, да, я иногда (раз в два года) предпочёл бы видеть возможность явно ему сказать "считай, что Foo переименован в Boo, а историю Moo, сделанного клоном из него, надо вести отдельно". В целом, не настолько проблема.
Стиль Github, GitLab, Bitbucket - это "разрешим работать с распределённой VCS ко ак с централизованной". Это не родное для Git.
Более адекватное приспособление к стилю собственно Git это Gerrit. Он используется как серверная база в самом гугле (с сильными внутренними подточками). Но у него нету CI и прочих удобств в едином флаконе, их надо довинчивать.
1. staging area. В Mercurial ничего подобного нет и не планируют. А это (вместе с interactive rebase) практически единственное, что позволяет легко делать чистые коммиты, а не такие, в которых намешало 100500 разных типов правок.
Для меня любая VCS, в которой этого нет, непригодна.
2. Отсутствие зажима на определённые процессы разработки - который в Mercurial выглядит как множественные головы, тяжело изменяемый статус коммита вроде draft/public, и т.п.
Mercurial выглядит как "сэмулируем централизованную VCS на базе распределённой, но так, чтобы людям не надо было думать, что они делают".
Умеет. Вы, наверно, git clone запускали. Потому что если сделать init + fetch, то докачка работает с момента обрыва. Не идеально, некоторые мета-части передаются заново, но есть сохранение принятого.
Можно. Были даже примеры простых игр (уровня Pacman) как (U)EFI бинарей.
Проблема в том, что это отдельная платформа со своей спецификой, и что-то большое разрабатывать под неё тупо нет смысла. Вам придётся сделать свой R/W драйвер целевой FS, свою поддержку мультипроцессности в нужном стиле, достаточно богатое API для работы такого сервиса, сделать все нужные драйвера включая сетевой (EFI может его не предоставлять)... сама модель EFI ориентирована на простоту (ну, как её понимает Intel) и надёжность процесса, а не на скорость... с какого-то момента будет понятно, почему если "за морем телушка - полушка, да рубль перевоз", то грузить Linux с диска дешевле во всех смыслах:)
BIOS тупо загружает первый сектор с самого первого (по приотритету загрузки) диска и передает ему управление.
Если быть финально точным - бывали BIOS, которые пытались лезть в эту тему, особенно в районе конца 1990-х. Для них в загрузочных секторах файловых систем рисовали фиктивные FAT BPB, без которого могло молча отказаться грузить. Чем более "вендорский" комп, тем это вероятнее. Практически исчезло под давлением наличия альтернативных систем вроде Linux.
Вот только такая загрузка - жутко небезопасна...
Этого не понял. Чем она небезопасна, если диски подключить по ATA/SCSI/etc. это явное действие, после которого надо пересчитать загрузку, а всякие USB требуют явного вызова boot menu?
Моя сильно подозревать, что неосвоение адресной арифметики и ассемблера никак не происходит от какого-то "непонимания", а это заклин из-за боязни выйти из уютного мирка, защищённого от проблем с памятью. Кто преодолевает легко этот заклин - идёт дальше, пусть и с разумной осторожностью.
Именно поэтому "игрушки" системы "ну зависло - передёрнул по питанию" тут очень удобны.
И почему в PC перестали делать ROM Basic? Надо вернуть...
1) self должен присутствовать обязательным первым аргументом в методах, привязанных к объекту. (В принципе ничто не мешает назвать его при этом не self, а mamarama или хвостПитона, но все коллеги и статические анализаторы забьют ногами.) Для помеченных @classmethod точно так же должен быть cls.
2) Ссылка через self на поля объекта обязательна, такого, как в C++ с его "не нашли в локальных переменных - ищем в классе" нету и не предполагалось.
Оба пункта могут считаться и достоинством, и недостатком, кому как - но предмет для холивара дают по полной.
1. Объект это нечто, про что нам удобно думать, что у него есть граница, отделяющая от остального мира состояния программы, и есть более-менее чёткое определение, как он взаимодействует с остальным состоянием - и мы думаем и описываем это в коде так, что есть этот объект и есть взаимодействие с ним.
Это первично перед всем остальным, включая то, какие виды взаимодействия, явно ли присутствует слово object или class, и прочая и прочая и прочая.
2. Если у объекта есть собственный источник движения, это стиль Кея, Simula, Smalltalk и прочих. Это стиль "рыб в аквариуме", которые плавают, пускают пузырьки воздуха и перебрасываются данными в них. Сюда же следует включить 100500 агент-ориентированных сред, как, например, Erlang, где его внутренний процесс можно приравнять к объекту.
Если нет, а источник движения - внешний, как набор нитей (тредов) процессов, то это ООП стиля C++, Java, C#, VB, Pascal/Modula/Delphi/etc., Python, Ruby, тысячи их. Вот там вызываются методы, а не посылаются сообщения.
Это основное разграничение, по сравнению с которым остальные... ну не становятся совсем деталями, но менее заметны.
Дальнейшие рассказы автора статьи на 100% посвящены именно "пассивному" ООП со всей его спецификой. И при этом непонятны начальные намёки в сторону Кея, как ружьё, которое, несмотря на весь гнев Станиславского, провисело на стене всю пьесу без движения.
3. ООП предполагает инкапсуляцию - в принципе, потому что объекты, кроме самых примитивных, неизбежно имеют внутреннюю структуру.
Но защита инкапсуляции всеми private/protected/аналогами - вопрос не принципа, но уровня защиты от диверсий другими участниками в большом проекте, где невозможно следить за всем, что делает кодер за соседним столом. Поэтому "инкапсуляция" тут неоднозначна, роль защиты растёт со сложностью задач.
4. Полиморфизм наследования интерфейса - следующий критичный элемент, но он относится не к ООП самому по себе, а является неизбежным следствием необходимости контроля сложности. Посылка универсального сообщения "опиши себя текстом" в SmallTalk или вызов метода интерфейса в Java тут - перенос этой сложности с управляющего на управляемого. Разумеется, это не всегда в плюс (возможность вызвать в, к примеру, Python метод, которого нет, но который может быть добавлен или не добавлен в ходе жизни объекта назначением его "поля" - хорошо для всякой гибкости и плохо для отладки).
5. Наследование реализации - такой же метод справиться со сложностью, но там, где это полезно за счёт того, что большая часть общего кода собирается вместе. Есть задачи, где это в плюс, и есть где можно легко заабьюзить в минус. Пока что видим, что плюсов считается больше - потому что административно можно запретить наследование реализации в конкретном месте, но нельзя сделать, если язык её не поддерживает. Но есть языки, в которых её убрали намеренно.
Всё прочее - скорее местные особенности, чем принципы ООП.
Они ведь вроде бы вполне быстро обеспечивают произвольный доступ, есть ли смысл с ними заморачиваться такими структурами?
С ними - ещё более:)
На HDD дискрет перезаписи - 512 байт на классических, 4KB на многих новых (даже если они рапортуют логический размер блока всё те же 512 байт). А вот на SSD минимальный перезаписываемый объём может быть, например, 128KB. Умный контроллер набивает такую порцию многими блоками и обновляет вслед карту распределения, но чем меньше его таким грузить, тем лучше. Поэтому большая страница тут полезнее.
Хотя, 128KB для страницы B-дерева это многовато. Для таких применений придумали Log-structured merge tree.
Кстати в ГЛОНАСС не стали заморачиваться с високосными секундами, синхронизировали один раз и время идёт непрерывно.
GPS - точно так же, TAI время. PTP - точно так же. Но это не счёт в ядрах.
Ну это тем более странно, если системы реального времени завязаны на часы-минуты-секунды, в то время как нужен непрерывный счётчик времени.
Проблема в том, что база >99% систем реального времени, которые используются сейчас - это firm- и soft-realtime на базе чего-то Unix-подобного, в первую очередь Linux. Почему так - а потому что разработка на любом другом будет в разы дороже. А у Unix систем в принципе счёт в ядре в unixtime-без-вставных-секунд.
И тут при наличии багов лучше, кстати, подход BSD, которые вообще не пытаются эту секунду отрабатывать, возложив "растяжение" на длинные периоды (от 15 минут) средствами внешних NTP/etc. демонов. А вот Linux растягивает переходную секунду на две, и тут начинается полное ой.
5G это маленький пример. Не знаю, почему автор статьи взял его. И его можно решить очень грубо - да хоть порвать все разговоры в момент перехода.
Есть более серьёзные примеры. Все технологии непрерывного цикла с замером параметров, начиная с АЭС и химзаводов.
И что это за IT такое которое неспособно обработать лишнюю целую секунду
Вот такое вот IT. Которое экономит на тестировании, на сопровождении, всё, что можно и что нельзя. Я работал на таких проектах, где мы вводя мелкую новую фичу ломали фичи соседей и никто этого не видел до релиза, и они нам - точно так же:(
Я её проверил на реальном ARM (нода на AWS - достаточно реально?) - получается, описанный реордеринг таки происходит. При цикле вокруг LDAXRB и парном к нему STLXRB.
(Чтобы проверить пример, пришлось делать отдельный ассемблерный исходник - в штатных atomic функциях оно пыталось в рантайме найти и применить SWPALB.)
Так что или вам что-то другое в реальном примере помогло... или всё плохо. Ну или автор ответа ошибся в логике, IMHO минимально вероятное.
Если прогу, написанную для 32-разрядного RISC-V, можно без перекомпиляции запустить на 64-разрядном, тогда можно считать их одной архитектурой, если нет -- то нет. (Я с RISC-V реально не знаком, поэтому и говорю про "если")
И да, и нет. Общим кодом можно в три команды определить разрядность и сделать jmp на нужный вариант, но что-то сложнее этого требует раздельного кода.
addi t0, x0, 2
sll t0, 31
bne t0, x0, is_64bit
Так намеренно сделали. Но я не видел, например, двухархитектурных бинарников в ELF с компанией.
Хуже то, что архитектура подразумевает 100500 профилей, составляющих ориентированный граф добавления фич, некоторые из них можно получить стандартными средствами вроде чтения служебного регистра misa, но многие - нет, и надо выкапывать где-то отдельно (device tree, ACPI и тому подобное). Грануляция серьёзнее в разы чем с ARM. Но оно на 25-30 лет моложе, так что пока наблюдаем, что выживет из этих промежуточных уровней...
Встречал немного софта, который генерировал 1900-й год. Встречал, который генерировал 19100-й - вот тут эффекты были поинтереснее. Например, в Usenet не ходили сообщения - сервер отказывался принимать правильные с 2000-м годом как слишком старые.
Через полтора года ещё взорвался переход через миллиард секунд Unixtime, тоже были последствия.
Угу - "даём работать с распределённой базой как с простой централизованной, но с плюшками".
Вы тут "бранчами" называете теги сообщения коммита, которые показывают, в рамках какой разработки был сделан коммит. Ни в Git ни, на самом деле, в Hg это не нужно, если есть возможность писать его в сообщении коммита - что всегда и делается в процессе уровня больше чем "я и моя собака".
Как сами меркуриаловцы признают, "The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." В результате получаются ситуации типа "Две ветки-2 в пределах ветки-1 (не путать с веткой-3)" (ветка-1 это его внутренний branch, ветка-2 это безымянная голова, ветка-3 это bookmark).
А это _в основе_ единственно правильный вариант (ну не учитываем, что объекты могут представляться в виде дельт, это уже вопрос сжатия репы). Трекинг копирования/переименования должен делаться уже отдельно поверх него.
Представление, где каждый каталог и файл представляются хэшом и собственно найти изменённые файлы между коммитами - это очень экономная операция (все случаи разных хэшей отбрасываются из сравнения), позволяет как раз очень экономно определять набор тех файлов, в пределах которых надо вести трекинг уже по их содержимому.
Для сложных случаев типа "переместили 200000 файлов и при этом изменением `#include <moo/foo/boo/boo.h>` на `#include <util/moo/foo/boo/boo.h>` поменяли их хэши... ну да, можно было бы придумать какие-то подпорки. Но, насколько видим, это даже для крупных реп не составляет большой проблемы.
Ну и очень хорошо угадывает.
Опять же, да, я иногда (раз в два года) предпочёл бы видеть возможность явно ему сказать "считай, что Foo переименован в Boo, а историю Moo, сделанного клоном из него, надо вести отдельно". В целом, не настолько проблема.
Ну зачем же так, всё проверяется:
Git: Initial release 7 April 2005
Mercurial: Initial release 19 April 2005
Стиль Github, GitLab, Bitbucket - это "разрешим работать с распределённой VCS ко ак с централизованной". Это не родное для Git.
Более адекватное приспособление к стилю собственно Git это Gerrit. Он используется как серверная база в самом гугле (с сильными внутренними подточками). Но у него нету CI и прочих удобств в едином флаконе, их надо довинчивать.
1. staging area. В Mercurial ничего подобного нет и не планируют. А это (вместе с interactive rebase) практически единственное, что позволяет легко делать чистые коммиты, а не такие, в которых намешало 100500 разных типов правок.
Для меня любая VCS, в которой этого нет, непригодна.
2. Отсутствие зажима на определённые процессы разработки - который в Mercurial выглядит как множественные головы, тяжело изменяемый статус коммита вроде draft/public, и т.п.
Mercurial выглядит как "сэмулируем централизованную VCS на базе распределённой, но так, чтобы людям не надо было думать, что они делают".
Умеет. Вы, наверно, git clone запускали. Потому что если сделать init + fetch, то докачка работает с момента обрыва. Не идеально, некоторые мета-части передаются заново, но есть сохранение принятого.
Ну и ещё есть https://github.com/johnzeng/ResumableGitClone и наверняка ещё десяток похожих проектов.
Можно. Были даже примеры простых игр (уровня Pacman) как (U)EFI бинарей.
Проблема в том, что это отдельная платформа со своей спецификой, и что-то большое разрабатывать под неё тупо нет смысла. Вам придётся сделать свой R/W драйвер целевой FS, свою поддержку мультипроцессности в нужном стиле, достаточно богатое API для работы такого сервиса, сделать все нужные драйвера включая сетевой (EFI может его не предоставлять)... сама модель EFI ориентирована на простоту (ну, как её понимает Intel) и надёжность процесса, а не на скорость... с какого-то момента будет понятно, почему если "за морем телушка - полушка, да рубль перевоз", то грузить Linux с диска дешевле во всех смыслах:)
Если быть финально точным - бывали BIOS, которые пытались лезть в эту тему, особенно в районе конца 1990-х. Для них в загрузочных секторах файловых систем рисовали фиктивные FAT BPB, без которого могло молча отказаться грузить. Чем более "вендорский" комп, тем это вероятнее. Практически исчезло под давлением наличия альтернативных систем вроде Linux.
Этого не понял. Чем она небезопасна, если диски подключить по ATA/SCSI/etc. это явное действие, после которого надо пересчитать загрузку, а всякие USB требуют явного вызова boot menu?
Точно не я:) я считаю VAX чудовищно корявым и избыточным.
А вот что выбрать на универсальную машину для трансляции в целевую... сейчас вопрос в принципе отработан в куче сходных вариантов.
Моя сильно подозревать, что неосвоение адресной арифметики и ассемблера никак не происходит от какого-то "непонимания", а это заклин из-за боязни выйти из уютного мирка, защищённого от проблем с памятью. Кто преодолевает легко этот заклин - идёт дальше, пусть и с разумной осторожностью.
Именно поэтому "игрушки" системы "ну зависло - передёрнул по питанию" тут очень удобны.
И почему в PC перестали делать ROM Basic? Надо вернуть...
1) self должен присутствовать обязательным первым аргументом в методах, привязанных к объекту. (В принципе ничто не мешает назвать его при этом не self, а mamarama или хвостПитона, но все коллеги и статические анализаторы забьют ногами.) Для помеченных
@classmethodточно так же должен быть cls.2) Ссылка через self на поля объекта обязательна, такого, как в C++ с его "не нашли в локальных переменных - ищем в классе" нету и не предполагалось.
Оба пункта могут считаться и достоинством, и недостатком, кому как - но предмет для холивара дают по полной.
1. Объект это нечто, про что нам удобно думать, что у него есть граница, отделяющая от остального мира состояния программы, и есть более-менее чёткое определение, как он взаимодействует с остальным состоянием - и мы думаем и описываем это в коде так, что есть этот объект и есть взаимодействие с ним.
Это первично перед всем остальным, включая то, какие виды взаимодействия, явно ли присутствует слово object или class, и прочая и прочая и прочая.
2. Если у объекта есть собственный источник движения, это стиль Кея, Simula, Smalltalk и прочих. Это стиль "рыб в аквариуме", которые плавают, пускают пузырьки воздуха и перебрасываются данными в них. Сюда же следует включить 100500 агент-ориентированных сред, как, например, Erlang, где его внутренний процесс можно приравнять к объекту.
Если нет, а источник движения - внешний, как набор нитей (тредов) процессов, то это ООП стиля C++, Java, C#, VB, Pascal/Modula/Delphi/etc., Python, Ruby, тысячи их. Вот там вызываются методы, а не посылаются сообщения.
Это основное разграничение, по сравнению с которым остальные... ну не становятся совсем деталями, но менее заметны.
Дальнейшие рассказы автора статьи на 100% посвящены именно "пассивному" ООП со всей его спецификой. И при этом непонятны начальные намёки в сторону Кея, как ружьё, которое, несмотря на весь гнев Станиславского, провисело на стене всю пьесу без движения.
3. ООП предполагает инкапсуляцию - в принципе, потому что объекты, кроме самых примитивных, неизбежно имеют внутреннюю структуру.
Но защита инкапсуляции всеми private/protected/аналогами - вопрос не принципа, но уровня защиты от диверсий другими участниками в большом проекте, где невозможно следить за всем, что делает кодер за соседним столом. Поэтому "инкапсуляция" тут неоднозначна, роль защиты растёт со сложностью задач.
4. Полиморфизм наследования интерфейса - следующий критичный элемент, но он относится не к ООП самому по себе, а является неизбежным следствием необходимости контроля сложности. Посылка универсального сообщения "опиши себя текстом" в SmallTalk или вызов метода интерфейса в Java тут - перенос этой сложности с управляющего на управляемого. Разумеется, это не всегда в плюс (возможность вызвать в, к примеру, Python метод, которого нет, но который может быть добавлен или не добавлен в ходе жизни объекта назначением его "поля" - хорошо для всякой гибкости и плохо для отладки).
5. Наследование реализации - такой же метод справиться со сложностью, но там, где это полезно за счёт того, что большая часть общего кода собирается вместе. Есть задачи, где это в плюс, и есть где можно легко заабьюзить в минус. Пока что видим, что плюсов считается больше - потому что административно можно запретить наследование реализации в конкретном месте, но нельзя сделать, если язык её не поддерживает. Но есть языки, в которых её убрали намеренно.
Всё прочее - скорее местные особенности, чем принципы ООП.
С ними - ещё более:)
На HDD дискрет перезаписи - 512 байт на классических, 4KB на многих новых (даже если они рапортуют логический размер блока всё те же 512 байт). А вот на SSD минимальный перезаписываемый объём может быть, например, 128KB. Умный контроллер набивает такую порцию многими блоками и обновляет вслед карту распределения, но чем меньше его таким грузить, тем лучше. Поэтому большая страница тут полезнее.
Хотя, 128KB для страницы B-дерева это многовато. Для таких применений придумали Log-structured merge tree.
GPS - точно так же, TAI время. PTP - точно так же. Но это не счёт в ядрах.
Проблема в том, что база >99% систем реального времени, которые используются сейчас - это firm- и soft-realtime на базе чего-то Unix-подобного, в первую очередь Linux. Почему так - а потому что разработка на любом другом будет в разы дороже. А у Unix систем в принципе счёт в ядре в unixtime-без-вставных-секунд.
И тут при наличии багов лучше, кстати, подход BSD, которые вообще не пытаются эту секунду отрабатывать, возложив "растяжение" на длинные периоды (от 15 минут) средствами внешних NTP/etc. демонов. А вот Linux растягивает переходную секунду на две, и тут начинается полное ой.
5G это маленький пример. Не знаю, почему автор статьи взял его. И его можно решить очень грубо - да хоть порвать все разговоры в момент перехода.
Есть более серьёзные примеры. Все технологии непрерывного цикла с замером параметров, начиная с АЭС и химзаводов.
Вот такое вот IT. Которое экономит на тестировании, на сопровождении, всё, что можно и что нельзя. Я работал на таких проектах, где мы вводя мелкую новую фичу ломали фичи соседей и никто этого не видел до релиза, и они нам - точно так же:(
Картинка паники ядра от совсем другой проблемы чем вставная секунда:) ну и в 2015 паники не было, были безвыходные заклины таймеровнедора.
Воспроизводить ситуацию как лишней, так и удалённой секунды тривиально, и проблема в том, что никто не хочет это делать.
Ну а теперь немного "радости". Я поднял этот вопрос на SO: https://stackoverflow.com/q/58361491 (как тут ссылки в новом редакторе правильно вставлять? не понимаю) и в итоге получил ссылку на реальный пример, где вся эта логика не работает: https://stackoverflow.com/a/66265727/
Я её проверил на реальном ARM (нода на AWS - достаточно реально?) - получается, описанный реордеринг таки происходит. При цикле вокруг LDAXRB и парном к нему STLXRB.
(Чтобы проверить пример, пришлось делать отдельный ассемблерный исходник - в штатных atomic функциях оно пыталось в рантайме найти и применить SWPALB.)
Так что или вам что-то другое в реальном примере помогло... или всё плохо. Ну или автор ответа ошибся в логике, IMHO минимально вероятное.
Прокомментирую -
И да, и нет. Общим кодом можно в три команды определить разрядность и сделать jmp на нужный вариант, но что-то сложнее этого требует раздельного кода.
Так намеренно сделали. Но я не видел, например, двухархитектурных бинарников в ELF с компанией.
Хуже то, что архитектура подразумевает 100500 профилей, составляющих ориентированный граф добавления фич, некоторые из них можно получить стандартными средствами вроде чтения служебного регистра misa, но многие - нет, и надо выкапывать где-то отдельно (device tree, ACPI и тому подобное). Грануляция серьёзнее в разы чем с ARM. Но оно на 25-30 лет моложе, так что пока наблюдаем, что выживет из этих промежуточных уровней...
Давно реализовано (например в Olson TZ base так называемые right-зоны).
Только никому за пределами условных АЭС нахрен не нужно.
Не все.
Встречал немного софта, который генерировал 1900-й год. Встречал, который генерировал 19100-й - вот тут эффекты были поинтереснее. Например, в Usenet не ходили сообщения - сервер отказывался принимать правильные с 2000-м годом как слишком старые.
Через полтора года ещё взорвался переход через миллиард секунд Unixtime, тоже были последствия.