Давно тут меня не было...
|
Надо замутить порт бубунтутача на Redmi 6a, а то 4,5 и 7 есть, а то и в разновидностях, а этого что-то никому не удалось добыть что-ли, хз
|
|
|
Я пропатчил KDE,
Провертивши на х..хосте, Закоммитив во все щели, Приближаюсь уже к цели. Максимально за..заигравшись, По коммитам пробежавшись, Замечаю баг сякой, Вот скотина же, отстой.. 
|
|
|
Мысль #2
Динамическая линковка и как прийти к подобию совершенства в архитектуре Как известно, после получения объектного кода наступает этап линковки и тут у нас два возможных сценария: линковаться статически или динамически. И оба метода вполне актуальны и имеют свои кейсы, вопрос только в рациональности использования. Небольшой экскурс до "начала времени" Unix: изначально в system lll использовалась статическая линковка в формат а.out, который в душе не чаял, что такое эти ваши динамические библиотеки, от чего, да и не только, у разработчиков весьма подгорало, и сели они и айда думать, как же решить эту беду и придумали они как один из вариантов формат исполняемых файлов ELF, исполняемый линкуемый файл, привычный, но не единственный, в разновидностях *NIX'ов, позволявший подгружать символы вне сегментов загруженного в память бинарника, а уже посредством другой статической сущности передавать управление или принимать данные из других таких же объектов, что с одной стороны, позволяет не загружать повторно уже имеющиеся функции в память, а делить их между приложениями, от чего их так же называют shared object'ами в заморской литературе, но с другой, усложнило загрузку самих программ и вероятность ошибок при их обработке, в лице отсутствия нужных точек входа/символов, что есть синонимы, DLL hell, когда каждое приложение тащит одну и ту же библиотеку много раз и они плодятся как кролики по всей системе, ошибок сегментирования, так как что-то вне бинарника могло измениться и так далее. Есть системы где статических бинарников по сути нет и они не разрешены в документации, в таких системах все приложения являются по сути своей библиотеками или же обьектами, способными быть загруженными другими объектами, в частности к таким относятся Mac OS X и Haiku, где из статических объектов существуют только непосредственно сущности, связанные с разбором динамических объектов, dyld и runtime-loader соответственно. И динамическая линковка так же дала возможность более гибко работать с софтом, ибо теперь у вас нет необходимости держать строго одну версию ПО, поскольку если совместимость по символам есть, вы без проблем можете обновиться и для программ это будет максимально незаметно в большинстве случаев. А теперь, главный вопрос всея опеннета, вечный, как мем про патченные кеды в FreeBSD: зачем? Динамическая линковка хороша если ваша программа часто обновляется, в ней нет специфичных функций из сторонних библиотек или выкинутого из их новых версий функционала. Но это вам может и помешать, к примеру, когда у вас есть конкретные требования к версиям библиотек или функциям, и они не приняты в апстриме, или же ваша программа с закрытыми исходниками(упаси Линус вас такое делать), то вам прямая дорога включать такие библиотеки статически в ваше приложение. Так что, анализируйте, делайте выводы, линкуйте с умом и будет вам Nirvana А на этом у меня всё, до следующей дельной мысли!?? (Пы.$ы.:правки и замечания приветствуются) |
|
|
Мысль #1
Solaris zones vs KVM Многие, кто сталкивался с VDS/VPS, скорее всего, знают об технологиях виртуализации на серверах, таких как KVM (kernel virtual machine) и openVZ, немногие помнят о такой технологии как зоны(zone) в Solaris. У каждой технологии есть свои преимущества и недостатки, а так же особенности работы с ней. OpenVZ хороша тогда, когда у вас планируется исключительно Linux, просто потому что кроме него с этой технологией никто более не работает, поскольку эта разновидность виртуализации предполагает, что все виртуалки будут использовать ядро хоста и не будут иметь доступа к оборудованию "напрямую" с помощью системных вызовов, отличается гибкостью в плане разделения ресурсов, если одной виртуалке не будет хватать памяти или ресурсов ЦП, то она может "одолжить" у соседей простаивающие ресурсы(хотя возникает риск получить ситуацию, когда ресурсы могут понадобиться виртуалке, у которой ресурсы взяли, и может возникнуть весьма неприятное положение), KVM, как можно понять из названия, работает на уровне ядра ОС и предоставляет работу с инструкциями аппаратной виртуализации, имеет возможность запуска любой ОС и проброс физического оборудования благодаря доступу через блочные устройства, очень не гибкая технология в плане памяти, можно только увеличить объем, но из достоинств этот подход даст больше возможностей для гибкой настройки работы с аппаратной частью сервера, что бывает полезно, к примеру, при обработке данных на DSP, или GPU. Зоны же сочетают в себе преимущества двух предыдущих подходов, это и разграничение доступа к оборудованию (для каждого отдельного устройства может существовать своя зона), может иметь свои независимые от хоста виртуальные интерфейсы для связи с другими зонами, имеется возможность запуска других ОС, к примеру, FreeBSD, тогда мы получим аналог jail, и при этом у нас остаётся гибкость в выделении ресурсов хоста и их распределении между зонами. Но увы, в linux и других unix-like ОС эта технология за пределами соляр распространения не получила. |
OpenVK Altair Preview (0aecc299-nightly) | PHP: 8.2.7 | DB: 8.0.34-26
время подавать напитки и вершить судьбы
Mastodon | Telegram | GitHub | Discord | Email
