#prog #article
Xz format inadequate for long-term archiving
There are several reasons why the xz compressed data format should not be used for long-term archiving, specially of valuable data. To begin with, xz is a complex container format that is not even fully documented. Using a complex format for long-term archiving would be a bad idea even if the format were well-designed, which xz is not.
Xz format inadequate for long-term archiving
There are several reasons why the xz compressed data format should not be used for long-term archiving, specially of valuable data. To begin with, xz is a complex container format that is not even fully documented. Using a complex format for long-term archiving would be a bad idea even if the format were well-designed, which xz is not.
👍4👎4
Forwarded from Jem
This media is not supported in your browser
VIEW IN TELEGRAM
делайте выводы
😁34😐1
Участвую в двух еженедельных ролёвках по D&D
@
Обе на этой неделе отменили
😢
@
Обе на этой неделе отменили
😢
😢23🤬2😭2❤1😁1🎉1🤡1🥴1
Forwarded from Технологический Болт Генона
Это бесконечно прекрасно
Linux запущен на Intel 4004, первом коммерческом микропроцессоре
https://www.opennet.ru/opennews/art.shtml?num=61904
Оригинальный пост
Linux/4004
Slowly booting full Linux on the intel 4004 for fun, art, and absolutely no profit
https://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004
В оригинальной посте куча подробностей и всякого интересного. Категорически рекомендую.
Продемонстрирован успешный запуск ядра Linux с rootfs-окружением из Debian на разработанном в 1971 году 4-разрядном процессоре Intel 4004, который считается первым коммерчески выпускаемым микропроцессором на одном кристалле. Процессор содержит всего 2300 транзисторов, поддерживает 46 инструкций и обеспечивает производительность на уровне 60 тысяч операций в секунду.
Так как архитектура Intel 4004 имеет серьёзные ограничения и может адресовать лишь 4 КБ постоянной памяти, вместо прямого запуска Linux была использована идея написания эмулятора процессора MIPS R3000, на котором может работать Linux. Работу усложняло то, что для Intel 4004 не существует и не может быть создано компиляторов для языка Си, поэтому эмулятор пришлось создавать на ассемблере. Таким образом, работа была организована так, что непосредственно на чипе Intel 4004 запускался эмулятор, который в свою очередь выполнял окружение на базе ядра Linux.
MIPS выбран как оптимальный вариант для эмуляции, укладывающийся в ограничения Intel 4004 и размер доступной памяти. Например, созданию эмулятора ARM мешал возникающий сдвиг операндов, RISCV - запутанные режимы адресации, x86 - большой расход памяти на декодирование инструкций, PPC - общая усложнённость эмуляции при небольшом размере памяти.
Для запуска программ на реальной системе Intel 4004 вначале была сформирована простейшая плата, состоящая из микропроцессора Intel 4004, тактового генератора Intel 4201, чипа оперативной памяти Intel 4002-1, размером 20 байтов, контроллера постоянной памяти Intel 4289 и микроконтроллера ATMEGA48, симулирующего постоянную память. В процессе развития проекта была подготовлена более сложная плата, дополнительно включающая память для размещения запускаемого в эмуляторе Linux-окружения и поддерживающая симуляцию постоянной памяти, используя SD-карту. Кроме того, для проведения экспериментов и упрощения разработки на современных системах был написан эмулятор чипа Intel 4004.
. . .
После внесения оптимизаций загрузка Linux в подготовленной конфигурации заняла более 8 дней.
Linux запущен на Intel 4004, первом коммерческом микропроцессоре
https://www.opennet.ru/opennews/art.shtml?num=61904
Оригинальный пост
Linux/4004
Slowly booting full Linux on the intel 4004 for fun, art, and absolutely no profit
https://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004
В оригинальной посте куча подробностей и всякого интересного. Категорически рекомендую.
🔥12❤🔥3🤯2👍1🎉1🤩1
Программирование — это вообще не просто!
Коллекция #suckassstory про #prog раммирование от @blog_pogromista
(алсо половина проблем — из-за динамической типизации)
Коллекция #suckassstory про #prog раммирование от @blog_pogromista
(алсо половина проблем — из-за динамической типизации)
🌚5👍4
В #rust нельзя использовать
(#prog)
#[cfg(false)]
для безусловного отключения блока кода. Чтобы исправить это, есть RFC. А пока что можно использовать #[cfg(any())]
(#prog)
GitHub
RFC: Allow boolean literals as `cfg` predicates by clubby789 · Pull Request #3695 · rust-lang/rfcs
This RFC proposes allowing boolean literals as cfg predicates, e.g. cfg(true) and cfg(false).
Rendered
Tracking:
Tracking issue for RFC 3695: Allow boolean literals as cfg predicates rust#131204
Rendered
Tracking:
Tracking issue for RFC 3695: Allow boolean literals as cfg predicates rust#131204
👍6🤮1
#prog #article
State of Text Rendering 2024
Внимание, текст очень большой, читайте, когда у вас будет свободное время.
TL;DR
In this survey paper, I cover advances in the OpenType standard and the Open Source text stack and applications since 2009. I also discuss the future advances currently underway.
In broad strokes, OpenType added support for color fonts, variable fonts, and the Universal Shaping Engine. The Free & Open Source stack supports all of these advances at the lower level, but application UI support has been slower to arrive. The Open Source text stack also gained enormous market-share when Android and Google Chrome fully embraced it. Adobe now integrates parts of the Open Source stack for OpenType shaping in their flagship applications Photoshop, Illustrator and InDesign.
Looking forward, there is a Rust migration of the text stack underway, which will unify font compilation and consumption under a safe programming language. Incremental Font Transfer will stream fonts to web browsers. And my proposed Wasm-fonts will finally enable correct rendering of the most complex writing systems that are not (and inherently can not be!) fully supported by the OpenType Shaping model, and more expressive fonts for simple writing systems like Latin.
State of Text Rendering 2024
Внимание, текст очень большой, читайте, когда у вас будет свободное время.
TL;DR
In this survey paper, I cover advances in the OpenType standard and the Open Source text stack and applications since 2009. I also discuss the future advances currently underway.
In broad strokes, OpenType added support for color fonts, variable fonts, and the Universal Shaping Engine. The Free & Open Source stack supports all of these advances at the lower level, but application UI support has been slower to arrive. The Open Source text stack also gained enormous market-share when Android and Google Chrome fully embraced it. Adobe now integrates parts of the Open Source stack for OpenType shaping in their flagship applications Photoshop, Illustrator and InDesign.
Looking forward, there is a Rust migration of the text stack underway, which will unify font compilation and consumption under a safe programming language. Incremental Font Transfer will stream fonts to web browsers. And my proposed Wasm-fonts will finally enable correct rendering of the most complex writing systems that are not (and inherently can not be!) fully supported by the OpenType Shaping model, and more expressive fonts for simple writing systems like Latin.
🤮1