Юмор

А что написано поверх картинки, нам было непонятно, и никак Google Translate нормально с русского на английский эти посты не хотел переводить.

Какая печаль за кордоном...

Блоггер (платформа для блогов) удаляет по требованию россиянских

Мы удалили этот блог в ответ на юридический запрос, поданный в Google. При желании можно подробнее узнать о запросе на сайте ChillingEffects.org.

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

Кого удалили-то, и за что, можно поподробнее?

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

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

NetBSD is more a culture of pure engineers and developers rather than of evangelists pushing an ideology of how the software industry should be run. As such, you or your company will never get flamed for not releasing source code modifications open-source.

A single talented developer is typically more effectively utilized in this arrangement, and is part of the reason NetBSD can do with a few hundred developers what Linux does with tens of thousands. The differences in each OS' development criteria is apparent even at startup in the kernel dmesg. Compare Linux's ad-hoc dmesg with NetBSD's more structured dmesg booting from the same hardware

In Linux, the mantra is that developer time is 0-cost and available in infinite quantities, which is not a method of thinking that lends itself well to commercial ventures with deadlines and schedules, or with people with other things to develop. Linus has traditionally been against including any mechanism in the kernel that makes the developer's life easier. (Reference: here)

Working with mainstream Linux often requires the involvement of so-called gatekeeper positions that may or may not have the political clout within a given open-source community to successfully lobby changes.

Теперь Linus:

Apparently, if you follow the arguments, not having a kernel debugger leads to various maladies:

• you crash when something goes wrong, and you fsck, and it takes forever, and you get frustrated.
• people have given up on Linux kernel programming, because it's too hard and too time-consuming.
• it takes longer to create new features.

And nobody has explained to me why these are bad things.

it's more than that. It's not that you have to look at the sources (of course you have to – and any good debugger will make that easy). It's that you have to look at the level above sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand what the program does. Not just that particular line.

I do realize that others disagree. And I'm not your Mom. You can use a kernel debugger if you want to, and I won't give you the cold shoulder because you have "sullied" yourself. But I'm not going to help you use one, and I would frankly prefer people not to use kernel debuggers that much. So I don't make it part of the standard distribution, and if the existing debuggers aren't very well known, I won't shed a tear over it.

Because I'm a bastard, and proud of it!

Linus

По-моему, в этой оупенсорсной тусовке они все друг друга стоят.

Сентенция Линуса: ядерный дебаггер упрощает жизнь ⇒ программисты могут менее ответственно программировать, им становится легче искать ошибки ⇒ среди кёнел-хакеров появляется стадо макак, и качество ядра падает ⇒ я категорически против дебаггера! Дебаггер — зло. Программирование ядра не должно быть доступно массам. Они всё испоганят. Порог на вхождение должен быть высоким. Иначе кому мы будем нужны?

А что, NetBSD не программеры кодят, а прямо такие CS-спецы? Пишут сначала теоретические работы, где обосновывают правильность всех алгоритмов, разрабатывают стандарты, утверждают массу документации и только затем переносят в код?

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

Нет, поэтому и сказано

в этой оупенсорсной тусовке они все друг друга стоят

В целом общее впечатление таково: люди никуда не торопятся, их не подстёгивает рынок, код делается в свободное время for fun. Есть время всё хорошо обдумать: что украсть, откуда украть, как переписать, как адаптировать, как организовать. Есть время подумать о том, стоит ли тянуть себе очередную новомодную фичу, действительно ли она нужна. Над людьми не висит требование популярности или лёгкости системы для непосвящённых. Главное требование — удобство для владеющих матчастью. Эти моменты позволяют делать в среднем более-менее взвешенный проект, не плодить форков, не раскалывать коммунити и кое-где даже идти в ногу со временем за счёт игры не количеством, а качеством, но иногда нужные фичи добавляются n лет спустя после того, как они появились в Linux.

Например, сейчас pivot_root нужен, а в коде его ещё нет; нужна загрузка с LVM, но штатная загрузка пока не использует рамдиск (хотя возможность его сделать вроде как есть). Впрочем, Debian штатно тоже с LVM не загрузить, хотя в арче, как пишут по последней ссылке, это уже сделали. Судя по рассылке, некоторые пилят NetBSD LiveCD с удобной системой сборки и уже сразу с Xen'ом на борту, это будет кул.

Как однажды было сказано, есть 3 стадии разработки софта: 1 — проприетарщики придумывают идеи и интерфейсы, пишут гнилой пропретарный код. 2 — приходит GNU-тусня и переписывает её на GPL. Как правило, получается коряво и без понимания. Наконец, стадия 3 — приходят BSD'шники и переписывают GPL-код уже начисто, с нуля, учитывая их ошибки, но под BSD-лицензией. Далее проприетарщики забирают BSD код к себе обратно, и цикл начинается снова.

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

evangelists pushing an ideology of how the software industry should be run

мы бы до сих пор сидели в полной проприетарной жопе. Это можно наблюдать сейчас по рынку смартфонов, телефонов и планшетов. Если б не GNU, сейчас так было бы со всей компьютерной индустрией. Даже то частично открытое, что есть на смартфонах — отголосок развития GNU на обычном железе. Кончно, когда пришёл Linux, открытая BSD уже была, и можно подумать о том, каков был бы мир с открытой BSD но без GNU, был ли бы успех и хоть какая-то популярность, поддержка распространённого железа... не знаю.

Кстати, могу подтвердить: как много раз грузивший обе системы на разном железе, не перестаю удивляться тому, насколько непонятен Linux'овый dmesg. Такое впечатление, что он вообще не для людей. В NetBSD сразу видно: что из оборудования опозналось, как опозналось, какие проблемы.

Ещё подумалось: есть такая мало кому известная система как DragonFlyBSD. Я застал те времена, когда впервые было объявлено о её форке от FreeBSD. Судя по документации и рассылке, DragonFly сейчас поддерживает: LVM, LUKS и запись на все ext вплоть до ext4(?). Т.е. Linux'овые диски можно на нём читать чуть ли ни искоробки. Паравиртуализации, правда, пока нет, но её пилят.

Наконец, коммент в юморе не должен быть без юмора, поэтому: DragonFlyDebian. Интересно, что бы про него сказал unknown... Впрочем, после всяких Debian GNU/Hurd и Gentoo/FreeBSD уже трудно чем-то удивить.

А тем временем в маленьком уютном мирке Gentoo...

Невнимание к безопасности _вообще_ свойственно Gentoo-сообществу.
Например, никого по большему счёту не интересует ни аутентичность
дистфайлов (да и как её проверить?), ни тем более аудит изменений в
новых версиях. Обновления в основном тестируются вслепую, попадают в
portage и теструются вслепую уже пользователями. В код заглядывают
редко и избирательно – для решения конкретных проблем. Безопасность
машин разработчиков обеспечивается по самому минимуму, в рамках
ретроактивного подхода и часто с опозданием. В такой ситуации, даже
если все файлы portage будут подписаны и аутентичность ключей
удостоверена, лишь чуть-чуть уменьшится поверхность атаки. И ничего с
этим не поделаешь: или понимать и осознанно принимать риски, или искать
другой дистрибутив, с другой командой, и осваивать другие практики
работы.

© Pavel Labushev. gentoo-user-ru@lists.gentoo.org

Линус где-то писал, что самое неблагодарное дело — поддержка железа. Когда производитель этому не помогает, а активно противодействует. Вроде он ещё добавлял, что если бы знал, во что это выльется по затратам усилий, то не взялся бы в своё время за этот труд вообще.

Т.е., никакого фана, один гемор. Перефразируя от себя: пытаясь поддерживать кривые закрытые проприетарные индусо-китае-протоколы для железа, приходится опускаться до уровня их кодинга.

В последнее время появилась третья сила, которая откровенно за рынок и против фана. Самые циничные прагматики продвижения с целью извлечения коммерческой выгоды (Леннарт) уже и архитектуру системы под это всё пытаются подстроить.

Вроде относительно давно есть. Пусть будет на всякий случай про запас, также как и HURD. Если мэйнстрим совсем загнётся или зайдёт далеко не туда, полезно иметь альтернативы, которые могут получить стимул развиваться.

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

Кривые проприетарные аппаратные протоколы строгают не индусо-китае, их строгает западная фирмА.

Так выглядят практически все проприетарные драйвера и API (пример из области видеокарт, только с точки зрения разработчика прикладного софта, но сути это не меняет). Если не поддерживать их, на такое принципиальное и не совместимое ни с чем ядро все положат с глубоким чувством.

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

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

Если аппаратура открыто реализует RISC команды, можно написать свои драйвера и API, на проприетарные забить. Если проприетарные драйвера и API имеют малый набор простых команд – нужно использовать только их, на прочее забить. В видеокартах можно использовать только примитивную работу с пикселями или линиями, и реализовать на этом весь функционал, на остальной аппаратный функционал забить.

Так что все будет работать, и звуковухи и веб-камеры, но на своем открытом API, на своих драйверах.

И кому оно по нынешним временам будет нужно без аппаратного ускорения 3D и декодирования видео, без поддержки OpenGL? :) Разве что двум с половиной параноикам для голых иксов. Но два с половиной параноика вряд ли найдут даже небольшую команду системных программистов для написания минималистичного драйвера. Ресурсы ограничены, так что естественное желание FOSS-программистов — писать код типа "one size fits all".