Проект CoreOS (https://www.opennet.ru/opennews/art.shtml?num=40275), развивающий основанное идеях контейнерной изоляции серверное окружение, анонсировал (https://coreos.com/blog/rocket/) создание нового инструментария для управления созданием, запуском и выполнением изолированных контейнеров - Rocket (https://github.com/coreos/rocket), выступающего в качестве более безопасной, переносимой и адаптированной для серверного применения альтернативы Docker. Rocket нацелен на манипуляцию контейнерами, построенными в соответствии со спецификацией App Container (https://github.com/coreos/rocket/blob/master/app-container/S...), также предложенной проектом CoreOS и нацеленной на создание универсального переносимого формата контейнеров.Наиболее существенные отличия Rocket от Docker заключаются в использовании иной модели выполнения, позволяющей достигнуть значительно более высокого уровня защищённости. В Docker все операции проводятся с участием одного централизованного фонового процесса, что создаёт серьезные потенциальные проблемы с безопасностью, устранить которые можно лишь путём полной переработки организации работы. Также утверждается, что последнее время Docker отклонился от первоначальных задач и стал развивать функции, выходящие за рамки средств управления контейнерами, превращаясь в излишне усложнённую платформу.
Rocket сосредоточен только на управлении контейнерами и обеспечении их максимальной переносимости. В Rocket применяется многоуровневая модульная архитектура, разделяющая операции работы с контейнером, на отдельные стадии, отдельно обрабатывающие этапы настройки файловой системы, подготовки исполняемого окружения и запуска приложений в контейнере. Кроме безопасности подобный подход также позволяет добиться хорошей расширяемости за счёт возможности реализации дополнительных функций через подключение дополнений.Для создания контейнеров и организации их изолированного выполнения применяются те же штатные механизмы ядра Linux, что в Docker - пространства имён (namespaces) и группы управления (cgroups). При этом, для управления контейнером используются средства запуска изолированных окружений, предоставляемые системным менеджером systemd. Для управления предложена новая консольная утилита rkt, предоставляющая набор команд, похожий на docker.
URL: https://coreos.com/blog/rocket/
Новость: https://www.opennet.ru/opennews/art.shtml?num=41168
Ну и кто кого уже? :)
Хрен их разберет. Куча систем, ни одна нормально не поддерживается в популярных дистрах, все позиционируются как безопасные и переносимые в отличии друг от друга.
> Хрен их разберет. Куча систем, ни одна нормально не поддерживается в популярных
> дистрах, все позиционируются как безопасные и переносимые в отличии друг от
> друга.Ага.
% aptitude versions docker.io
Пакет docker.io:
p 1.3.1~dfsg1-2 testing 400
p 1.3.2~dfsg1-1 unstable 200
>Хрен их разберет. Куча систем, ни одна нормально не поддерживается в популярных дистрахНа презентации RH7 Тоттон больше получаса распинался о полной коммерческой поддержке докера.
Тоттон https://www.linkedin.com/pub/jim-totton/13/a58/b9b
С марта сертификация есть конкретно по докеру.
In March, Red Hat announced certification for containerised applications, with Docker as a primary supported container format.
> все позиционируются как безопасныеdocker изначально почему-то не вызывал особого доверия, а стопка детских дырок это ощущение превратила в уверенность, что это не те люди.
> и переносимые в отличии друг от друга.
Я думал на GO можно писать без дырок.
> Я думал на GO можно писать без дырок.Я бы скорее сказал, что на всём можно писать с дырками.
Реально то какая польза от всех этих докеров? Я почитал про эти контейнеры. Сплошные ограничения. Даже ssh нельзя. Ограничивать себя, непонятно зачем.
Так сказать, традиционный подход к развёртыванию приложений - более надёжен.
>Я почитал про эти контейнеры.Вы в конце 2014 года узнали о контейнерах?
>Так сказать, традиционный подход к развёртыванию приложений - более надёжен.Так сказать, после первой успешной SQL инъекции атакующий может читать, а иногда и писать по всей фс включая .ssh/authorized_keys. Поэтому каждый 50-тый сервер (на гугл ИО приводили такие цифры) работает не на своего владельца, а рассылает спам.
Ну для борьбы с этим, положим, контейнеры - overkill, обычного чрута достаточно...В общем и контейнеры в их текущем виде, когда root в контейнере == root во всей системе - это просто chroot на стероидах, и толку от них большого нет.
Вы знаете модное слово overkill, но не знаете что с точки зрения безопасности chroot бесполезен? lmgtfy://Breaking Out of a Chroot
> Вы знаете модное слово overkill, но не знаете что с точки зрения
> безопасности chroot бесполезен? lmgtfy://Breaking Out of a ChrootНе бесполезен, но рута в чруте лучше считать эквивалентом рута в хосте.
Как выражается альтовский security officer, "хороший чрут -- пустой read-only чрут" :)
Почему админы в РФ упорто считают срадствами безопасной изоляции, то средства виртуализации, то контейнеры на сигруп и наме спейсес запускаемай сЫстемд???Да, chroot со специальными "тюремными" ограничениями обеспечивает больше гарантий изоляции запущеных в нём процессов чем эти все виртуальные машины и контейнеры. Ибо разработан специалино для гарантированной безопасной изоляции!
$ grep CONFIG_GRKERNSEC_CHROOT /usr/src/linux-3.17.3-hardened/.config
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
CONFIG_GRKERNSEC_CHROOT_INITRD=y
# CONFIG_GRKERNSEC_CHROOT_EXECLOG is not setПравильно настроеный chroot гарантирует безопасную изоляцию процессов!!!
> Правильно настроеный chroot гарантирует безопасную изоляцию процессов!!!
>гарантирует безопаснуюГарантирует что атакующий не сможет исчерпать всю память или файловые дескрипторы или fs inode, вызвав, по меньшей, мере DoS?
· RES_CPU - CPU time in milliseconds
· RES_FSIZE - Maximum file size in bytes
- RES_DATA - Maximum data size in bytes
· RES_STACK - Maximum stack size in bytes
· RES_CORE - Maximum core size in bytes
· RES_RSS - Maximum resident set size
· RES_NPROC - Maximum number of processes
· RES_NOFILE - Maximum number of open files
· RES_MEMLOCK - Maximum locked–in–memory in bytes
- RES_AS - Address space limit in bytes
· RES_LOCKS - Maximum file locks
+ cgroups
chroot как таковой не нужен, т.к. есть возможность всякий объект запускать в строгой изоляции не городя сложные вещи.Изоляция на уровне контейнеров и виртуализации это лажа с точки зрения безопасности. Я из контейнера openvz роняю всю ноду хостера, уводя ядро в панику. Очень хороший DoS. Страдает куча клиентов.
>Chroot was never supposed to be used as a security mechanism - Alan Coxchroot
Разработан в 1982
Изоляция ФС - частичная
Copy on write - нет
Дисковые квоты - нет
Ограничение I/0 rate - нет
Ограничение потребления памяти - нет
Ограничение потребление CPU - нет
Изоляция сетевого стека - нет
Сохранение состояния и миграция - нет
http://en.wikipedia.org/wiki/Operating_systemБ─⌠level_virtualizationЕсли в этом треде отписываются реальные админы я не удивлен что каждый 50 сервер взломан.
http://en.wikipedia.org/wiki/Operating_systemБ─⌠level_virtualization
парсер лох
>[оверквотинг удален]
> Copy on write - нет
> Дисковые квоты - нет
> Ограничение I/0 rate - нет
> Ограничение потребления памяти - нет
> Ограничение потребление CPU - нет
> Изоляция сетевого стека - нет
> Сохранение состояния и миграция - нет
> http://en.wikipedia.org/wiki/Operating_systemБ─⌠level_virtualization
> Если в этом треде отписываются реальные админы я не удивлен что каждый
> 50 сервер взломан.Посмотрите посты выше. Большая часть этих механизмов в chroot уже реализована.
Не вижу. Покажите.
Это под рутом. Но имея рута, ты вылезешь и из LXC. А без рута ты и chroot не покинешь.
Особенно интересно узнать как chroot помешает атакующему открыть 25/110/etc порты и рассылать спам.
> Особенно интересно узнать как chroot помешает атакующему открыть 25/110/etc порты и рассылать
> спам.Правильной настройкой iptables.
Я верю что с помощью большого количества костылей можно превратить детскую коляску в танк, но зачем? Есть же готовые решения.
> Особенно интересно узнать как chroot помешает атакующему открыть 25/110/etc порты и рассылать спам.Что значит "открыть"? Как "открытие" поможет рассылке спама? И как к спаму вообще относится 110?
> Ну для борьбы с этим, положим, контейнеры - overkill, обычного чрута достаточно...chroot -- не средство безопасности.
> В общем и контейнеры в их текущем виде, когда root в контейнере == root во всей системе
Как минимум в openvz это сильно не так.
> chroot -- не средство безопасности.А что тогда?
>> chroot -- не средство безопасности.
> А что тогда?https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity...
Chroot это специально разработаное экспертами в области безопасности средство изоляции процесов!!!
Виртуализация, контейнеры разрабатывались людьми далёкими от безопасности и больше для решения задач администрирования.
>>> chroot -- не средство безопасности.
>> А что тогда?
> https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity...
> Chroot это специально разработаное экспертами в области безопасности средство изоляции
> процесов!!!
> Виртуализация, контейнеры разрабатывались людьми далёкими от безопасности и больше для
> решения задач администрирования.Не понял я, это был сарказм или вы серьёзно, но на всякий случай отвечу.
Если вы возьмёте обычный chroot и тупо начнёте закрывать проблемы безопасности одну за одной, то выйдет примерно следующая сборная солянка:
- chroot;
- mount,pivot_root,umount;
- capabilities drop;
- unshare;
- cgroups;
- seccomp(?);
- и т.п.В результате вы получите некоторое решение, которое работает со всем перечисленным с помощью малой userland утилиты. Чем и является LXC. Могу развивать дальше эту мысль, но надеюсь уже и так всё понятно.
> ...это был сарказм или вы серьёзно...Это слёзы... Укреплённые технологии chroot и jail сегодня дают больше гарантий безопасной изоляции https://www.opennet.ru/opennews/art.shtml?num=41168#24 чем дырявые новые:
https://www.opennet.ru/opennews/art.shtml?num=40724
https://www.opennet.ru/opennews/art.shtml?num=41124
Дай гарантии что Rocket от CoreOS не дырявый?
> дают больше гарантийПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПОСТАВЛЯЕТСЯ "КАК ЕСТЬ" ЕЕ ПОСТАВЩИКИ ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ
Осильте лицензию уже.
И все эти костыли в купе + еще современные плюшки как то виртуализация IP стека дает в итоге FreeBSDшный JAIL :)
>en.wikibooks.org/wiki/GrsecurityПри чем тут grsecurity? Это совершенно независимый набор патчей затыкающих кучку потенциальных дыр и уязвимостей, в том числе и в chroot.
https://grsecurity.net/
У вас есть статистика по его использованию? 100%?
Причем тут независимость? Разговор не об этом, а об контейнерах vs grsec/selinux/tomoyo/apparmor с точки зрения безопасности.
> Причем тут независимость? Разговор не об этом, а об контейнерах vs grsec/selinux/tomoyo/apparmor
> с точки зрения безопасности.В контейнерной виртуализации вас никто не ограничивает в применяемых технологиях. Selinux/Apparmor/etc вполне можно сделать частью какой-нибудь контейнерной системы.
В Linux контейнеры и делаются лишь за счёт комбинации всяких разных технологий. Выбирают наиболее подходящие (+удобные) и делают конкретное контейнерное решение. Можно взять другой набор и сделать другое решение.
Большинство так и делает:grsec + виртуализация
grsec + RBAC
...
grsec + chroot
...
grsec + ваши контейнеры
>grsec + chrootТолько для домашнего использования.
>>grsec + chroot
> Только для домашнего использования.https://www.opennet.ru/openforum/vsluhforumID3/100446.html#50
Правильно настроеный chroot гарантирует безопасную изоляцию процессов!!! -Аноним
Chroot was never supposed to be used as a security mechanism - Alan Cox
Для меня Алан более авторитетен.
Но он же... три восклицательных знака ...
> Большинство так и делает:
> grsec + виртуализация
> grsec + RBAC
> ...
> grsec + chroot
> ...
> grsec + ваши контейнерыIMHO, очень странная у вас выборка, если в ней большинство использует grsec.
>об контейнерах vs grsec/selinux/tomoyo/apparmor с точки зрения безопасности.Где? Я вижу только
>Chroot это специально разработаное экспертами в области безопасности средство изоляции процесов!!!Что полная чушь.
>контейнерах vs grsec/selinux/tomoyo/apparmorПочему vs? Why not both?
>grsec/selinux/tomoyo/apparmorне вижу ничего что предотвратило бы OutOfMemory или 100%CPUtime DoS.
> не вижу ничего что предотвратило бы OutOfMemory или 100%CPUtime DoS.man limits.conf
+
man ulimit
+
grsec
=
Dec 2 10:00:03 xxxxx kernel: grsec: denied resource overstep by requesting 135168 for RLIMIT_MEMLOCK against limit 65536 for /usr/lib64/firefox/plugin-container[plugin-containe:5487] uid/euid:1001/1001 gid/egid:1001/1001, parent /usr/lib64/firefox/firefox[Gecko_IOThread:5367] uid/euid:1001/1001 gid/egid:1001/1001
>grsec/selinux/tomoyo/apparmorТы видишь тут ulimit? Нет? А он есть.
>limits.conf
Why not cgroups ... LXC ... docker?
cgroups - значительно более гибкие.
>> chroot -- не средство безопасности.
> А что тогда?Это средство для смены корневой директории (не безвозвратно). IIRC, изначально создавалось и использовалось для работы с тестовыми окружениями (для проверки процессов сборки и установки).
chroot это средство безопасности. В той же мере как носок средство контрацепции.
> Как минимум в openvz это сильно не так.Вот именно - в OpenVZ-то это не так, а в LXC именно так.
Да, в 2014 году прочитал. Подумал, мало ли, может я чего-то упускаю? Что-то модное и проходит мимо меня. Выяснил, что ничего особо революционного там нет. Оказалось, что можно жить как и прежде, без всяких контейнеров. А с ними будут только новые проблемы, которые нужно будет решать. Нет смысла время тратить зря. Во всяком случае в таком виде, в каком они сейчас - мне не нужно.
> Да, в 2014 году прочитал. Подумал, мало ли, может я чего-то упускаю?
> Что-то модное и проходит мимо меня. Выяснил, что ничего особо революционного
> там нет. Оказалось, что можно жить как и прежде, без всяких
> контейнеров. А с ними будут только новые проблемы, которые нужно будет
> решать. Нет смысла время тратить зря. Во всяком случае в таком
> виде, в каком они сейчас - мне не нужно.А что вы используете для изоляции окружений? Гипервизорные виртуальные системы? Или просто голый chroot?
> Да, в 2014 году прочитал. Подумал, мало ли, может я чего-то упускаю?
> Что-то модное и проходит мимо меня. Выяснил, что ничего особо революционного
> там нет. Оказалось, что можно жить как и прежде, без всяких
> контейнеров. А с ними будут только новые проблемы, которые нужно будет
> решать. Нет смысла время тратить зря. Во всяком случае в таком
> виде, в каком они сейчас - мне не нужно.Замените 2014 на 1914 и вы получите типичные рассуждения интеллигенции начала века о электричестве
А замените 2014 на 2004, контейнеры на ява, и смысл сохранится, или если хотите больших масшатабов на временной шкале, вспомните сверхзвуковую гражданскую авиацию, или сверхтяжелые танки, или непотопляемый титаник, или любой другой "проект" который в масштабах истории оказался пшиком, и которых было гораздо больше, чем "стрельнувших".В системе должна быть некая песочница, чтобы можно было там всякое запускать без риска порушить систему, но глобального баланса между "конкретной копией процесса", "ОС" и "ограниченными аппаратными ресурсами" эти контейнеры не решают, то есть решают добавляя еще одну прослойку, но если _не_ рассматривать ее как часть ОС, но тогда это уйдет в ресурсы, то есть каждому контейнеру своя копия либы, свой корень.. ну так или иначе переопределение ОС и исполняемого формата. Будет у вас не elf исполняемым, а zip в котором лежит elf, либы, катинки, все подряд, вон на андроиде почти так и есть, только виртуализация на уровне явы, которую 10 лет назад обещали сделать надежнее, избавить нас от утечек памяти, блаблабла))
Только тут go, не асилили копирование файлов и монтирование на си)).
> Так сказать, после первой успешной SQL инъекции атакующий может читать, а иногда и писать по всей фс включая .ssh/authorized_keys.
> SQL-инъекция
> читать/писать ФСЩИТО?
MySQL SQL Injection Cheat Sheet
...UNION ALL SELECT LOAD_FILE(‘/etc/passwd’)
SELECT * FROM mytable INTO dumpfile ‘/.../file’;
Не?
> после первой успешной SQL инъекции атакующий может читать, а иногда и писать по всей фс включая .ssh/authorized_keys.бред
Этого следовало ожидать. Docker прибит гвоздями к их инфраструктуре, а это не может всех устраивать. Есть, правда, опасения, что и с этим Rocket будет то же самое, только с привязкой к другому вендору, но рано или поздно кто-нибудь положит этому конец. Так что конкуренция здесь - однозначно позитивное явление.
Переносимость и завязанность на systemd как-то противоречат друг лругу.
Переносимость и завязанность на linux как-то противоречат друг другу
Совершенно никак. Ни капельки.
Что за идиотская традиция писать системные утилиты на Go
> Что за идиотская традиция писать системные утилиты на GoА вы пробовали этот go [1, 2]? IMHO, он намного лучше подходит для системных задач, чем python или perl, которые уже давно в моде в данной области.
[1] http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
[2] http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
1) perl
появился для автоматизации обработки текста
позволяет легко прочитать файл/stdin, сделать преобразования (в первую очередь текстовые) в несколько строчек (максимум - несколько десятков) и вывести результаты, в этой нише (весьма узкой, к слову) - вне конкуренции
что-то большое писать противопоказано, код очень слабо читаем
интерпретируем (не требует компиляции, переносим между платформами)
популярность в администрировании во многом обрел из-за того что исторически появился первым более-менее подходящим2) python
приятный синтаксис, очень лаконичный, хорошо читаем
оптимален для небольших проектов (на любую тему - тяжело что-то найти, на чем можно накалякать быстрее и элегантней) да и для средних проектов своего класса (где не критично быстродействие, не нужны навороченные ооп возможности, да и в целом динамическая типизация не под ынтерпрайз)
также интерпретируем (уже удар по быстродействию), только формальная многопоточность (фактически интерпретатор всё выполняет в один поток), т.е. если что критическое к скорости выполнения и пишут, то только с обильными с/c++ вставками (интеграция в языке на уровне)3) go
это ж что-то как понимаю С-подобное - на замену (до недавнего времени считалось, что альтернативы С в системном программировании вообще нету), а это совершенно другой класс языков
ну тут да, системный софт писать самое то, но администрировать на нем в принципе невозможно (ведь ещё и скомпилить надо перед тем как запускать, и кода в исполняемом файле не видно, представьте что всеми любимые bash-простыни в init-e заменят на бинари)иначе говоря, разработчики если и выбирали, то скорее между с/с++ и go, python на мой вкус может и хорош, но область его применения похоже несколько другая
> 3) go
> это ж что-то как понимаю С-подобное - на замену (до недавнего времени
> считалось, что альтернативы С в системном программировании вообще нету), а это
> совершенно другой класс языков
> ну тут да, системный софт писать самое то, но администрировать на нем
> в принципе невозможно (ведь ещё и скомпилить надо перед тем как
> запускать, и кода в исполняемом файле не видно, представьте что всеми
> любимые bash-простыни в init-e заменят на бинари)при желании - можно писать скрипты на Go: https://wiki.ubuntu.com/gorun
неужели так все просто
в С/С++ уже целую пачку систем сборок понаписывали (autotools, cmake, scons, ..), чтобы компилять на различных платформах/дистрибутивах
Да, просто.
Именно для этого Go и проектировался.
Чтобы все было просто - крайне быстрая компиляция безо всяких configure и cmake с самыми минимальными завязками на конкретную платформу (разумеется, если вы в коде зашьете "C:\mydir\myfile" то это вы САМИ завязались на Win). Язык имеет всего лишь пару-тройку ограничений по платформе. Например, syslog из коробки не работает с Win и MacOSX.
1) perl код очень слабо читаемМИФ. Читаемость вода - вопрос криворукости, а не перла. Хотя говнокода на перле понаписано прилично, конечно. Но будем честны, не на нём одном.
2) python приятный синтаксис
ога, только всем кто на C писал противопоказан, потому что от форматирования блоков отступами вместо { } блевать будут
и типизация странная - недодинамическая, например строка+число не конкатенируется
и всяких стандартно-полезных для веба фич из коробки (как в php) нет
>Читаемость кода - вопрос криворукостиво многом это так
проблема в том, что в перле присутсвуют экстравагантные возможности, с которыми естественно перебирают>ога, только всем кто на C писал противопоказан, потому что от форматирования блоков отступами вместо { } блевать будут
после джавы в качестве разнообразия мне наоборот только понравилось, а ещё больше понравилось, что кода в 2 раза меньше становится
>и типизация странная - недодинамическая, например строка+число не конкатенируется
разве это необходимое условие динамической типизации?
мне кажется так было сделано умышленно, чтоб побыстрее ошибки отлавливать>и всяких стандартно-полезных для веба фич из коробки (как в php) нет
мне ещё тех же встроенных в синтаксис регулярных выражений не хватает, а также возможности получать результат внешних команд и тп не очень удобно
с точки зрения администрирования конечно минус
видать питон позиционируют как язык общего назвачения без каких-то компромиссов и все тут
> и типизация странная - недодинамическая, например строка+число не конкатенируетсяНе путайте приведение типов и динамичность типизации. Динамическая типизация тоже может быть строгой. Построже чем в C, который числовые типы приводит один к другому даже не считая это заслуживающим упоминания, а если попросить по хорошему, то и int к void* и обратно приведёт неявно. Правда тут, надо отметить, он всё же варнинг кинет.
Да, я не спорю, тут много путаницы -- статическая/динамическая типизация, неявное приведение типов, перегрузка функций/операторов (built-in или на стороне юзера, как в C++) -- всё это сбивает с толку. Но вы как-нибудь на досуге сядьте и подумайте такую мысль: статическая типизация -- это когда типизированы идентификаторы (переменные, имена функций...), динамическая типизация -- это когда типизированы значения (то есть когда заглянув в рандомное место памяти, вы можете отличить значение типа int от значения типа unsigned int, не глядя в код, работающий с этими значениями). 10 минут переваривания этой мысли в голове будет достаточно, для окончательного и бесповоротного избавления от бардака в голове на эту тему.
Да слышал я это, понты это гнилые, про "строгую" динамическую типизацию. Она строгая только в таких вот маразмах со строками. С объектами например всё точно то же что в других скриптовых языках. Нет проверок типов параметров функций. Какая тут нафиг строгая типизация может быть? Маркетинг только)
т.е. если "строгая типизация" = "отсутствие любых неявных преобразований типов" - чего это даёт в динамическом языке, кроме неудобства - непонятно.
> т.е. если "строгая типизация" = "отсутствие любых неявных преобразований типов" - чего
> это даёт в динамическом языке, кроме неудобства - непонятно.Ах пичаль-пичаль... Непонятно... Ознакомьтесь с каким-нибудь ЯП отличным от пэхапэ/пайтон. Лучше, не насилуя мозги, сразу с lisp'ом. Есть шансы, что поможет. Ну а если нет, то просто признайтесь, что программирование -- это не ваша стихия и смените место работы.
Ты на личности-то на переходи. Лучше по существу скажи чо-нить.
> Ты на личности-то на переходи. Лучше по существу скажи чо-нить.Что именно тебе сказать? Ссылку кинуть на учебник по лиспу? Гугл подойдёт, в качестве такой ссылки? Хотя, я вот тут подумал... Теоретически, быть может, подойдёт не только лисп, но любой язык с динамической типизацией, который позволяет также использовать и статическую типизацию. Сейчас, как я понимаю, таких языков наплодили довольно много, и в виде "крутых" js, которые компилируются в самый натуральный js, и просто так, тот же rust, если я правильно понимаю этим занимается. Это я к тому, что если есть отвращение к лисповскому синтаксису, то можно изучить вопросы типизации на языке с C-like синтаксисом.
Ты что ли серьёзно думаешь, что я на C и C++ не писал?По существу - это какие реально удобства даёт "отсутствие преобразования типов" в динамическом языке, при том, что о преобразованиях типов объектов там вообще речи не идёт, т.к. тебе же априори пофиг какой там у объекта тип. Раз объекты исключаются, остаются по сути строки, числа и boolean, и в чём реально удобство отсутствия автоматического приведения например числа к строке - ни фига не ясно...
> Ты что ли серьёзно думаешь, что я на C и C++ не
> писал?А какое это имеет отношение к динамической типизации? Но вообще, я не думаю, что ты писал на C -- слишком расхлябанное у тебя отношение к коду, на C++ -- может и писал, но вряд ли профессионально в течение более полугода.
> По существу - это какие реально удобства даёт "отсутствие преобразования типов" в
> динамическом языке, при том, что о преобразованиях типов объектов там вообще
> речи не идёт, т.к. тебе же априори пофиг какой там у
> объекта тип. Раз объекты исключаются, остаются по сути строки, числа и
> boolean, и в чём реально удобство отсутствия автоматического приведения например числа
> к строке - ни фига не ясно...Удобство/неудобство -- это-то здесь причём? Речь идёт о строгости типизации. Удобна она или не удобна -- это уже десятый вопрос, который я не вижу причин обсуждать. Если есть автоматическое преобразование типов, то ни о какой строгости системы типов речи идти не может. Строгость -- это когда значение либо принадлежит данному типа, либо не принадлежит, и нет третьего варианта, когда оно не принадлежит, и в то же время иногда (не всегда) принадлежит.
Ага, а то, что объект любого класса можно использовать как объект любого класса, если у него всего лишь оказался метод с определённым именем - это не противоречит строгой типизации?А удобство при том, что те или иные фичи языков программирования только для удобства (удобства выполнения каких-то задач) и нужны...
> Ага, а то, что объект любого класса можно использовать как объект любого
> класса, если у него всего лишь оказался метод с определённым именем
> - это не противоречит строгой типизации?Противоречит, наверное. Я хз, но это уже нерелевантные терминологические игрища. На всякий случай, также, отмечу что существуют языки у которых имена методов не могут совпасть, поскольку хранятся в глобальном пространстве имён. В качестве примеров, можешь глянуть на ООП реализацию для C из glib, которая во все поля используется в gtk+. Ну или на lisp -- в нём правда речь не совсем о глобальном пространстве имён, а о пространстве имён пакета.
> А удобство при том, что те или иные фичи языков программирования только
> для удобства (удобства выполнения каких-то задач) и нужны...Ну это твои личные сложности, которые меня не колышут никоим образом. Если строгая типизация тебе не удобна, то не пользуйся ею. Кто б заставлял. Или ты споришь потому, что тебе нравиться думать, что ты пишешь на языке со строгой типизацией, а я, объясняя тебе что такое строгость, лишаю тебя этой иллюзии? Но иллюзии вредны. Они не должны замутнять твой взгляд на мир.
> Что за идиотская традиция писать системные утилиты на GoНикто не хочет второго #Heartbleed
У Докера бабахнуло http://blog.docker.com/2014/12/initial-thoughts-on-the-rocke.../
Зоопарк, когда уже порядок наведут?