Желающие — пишите в приват

Кстати, интересующиеся могут в Twitter следить за @LF_Training, там будут публиковать все новости LinuxFoundation тренинг центра (в т.ч. по бесплатным событиям и материалам)

Как я уже писал, после того как допишем и перемонтируем то, что пропустили — выложим в общий доступ. Если Вы заинтересованы в изучении сабжа самостоятельно — начните с литературы (LDD3, ULK3,...), скачайте исходники ядра.

См. мой профиль, например (мы же вроде вживую уже общались, если я не ошибаюсь?). Я — организатор.

Если Вас пугает цена — LinuxFoundation иногда проводит часть тренингов online и бесплатно, зарегистрируйтесь и внимательно изучите условия. Если Вы хотите платно — то будьте готовы платить по расценкам LinuxFoundation, их тренинги уже доступны на Украине on demand.

Жаль что Вы не читали мои посты — ни о какой привязке речи не идёт.

Если у кого-то будут вопросы или предложения по сути топика — прошу писать мне в приват, здесь Петросяны утомляют.

Безплатні курси, це як або безплатний сир на яку ведешся або як халява, якій потім не складеш ціни.

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

Полностью отсутствует самомотивация

Несколько странное заявление для человека с опытом прохождения тренингов. Хотя я, вероятно, просто что-то неверно понял.

Linux Kernel Development

ИМХО для начинающего может быть весьма полезной

Linux Network Internals

Рекомендую хотя бы просмотреть LDD3, очень хорошая книга по механизмам работы ядра с железом.

для GL было бы больше пользы от видео уроков

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

Пункта 1 в списке более чем достаточно

Верно. +LKML +TLDP +lwn +lxr.

Задача тренинга — не «разжевать» слушателям сабж (зачитывать книги из секции 1 вслух), а помочь разобраться в нём, раскрывая ньюансы и помогая с практикой.

Communicating with Hardware и First kernel module одно и то-же время

Всё просто — “First kernel module” идёт в самом начале, нужно закрыть вопросы по kernel build system...

А в Днепре подобные лекции не планируются?

К сожалению, пока нет — просто не хватает ресурсов на это. Тренинги делаются сотрудниками GL в свободное от работы время, мотаться в Днепр 2 раза в неделю нам будет несколько напряжно... Может Вы к нам?

3. Материалы тренинга пока недоступны. Тренинги в других городах пока недоступны. Прохождение тренинга не обязывает идти работать в GL. Прохождение тренинга не гарантирует трудоустройство в GL. Задача тренинга — не “разжевать” слушателям сабж (зачитывать книги из секции 1 вслух), а помочь разобраться в нём, раскрывая ньюансы и помогая с практикой. По прохождению тренинга никаких сертификатов ни выдаём и не планируем выдавать. Пока что тренинг бесплатный.

Честно говоря, я так и не понял, почему outsourcing тормозит развитие ИТ Украины. Лично мне кажется, что развитие ИТ Украины (кстати, не только ИТ) тормозится совсем другими вещами, сейчас не о них. Аутсорсинг, как модель бизнеса, имеет право на жизнь в любой стране, в любом окружении — просто где-то стоимость труда выше, а где-то (Украина тому пример) ниже. Пока этот разрыв будет достаточным для операционной деятельности и получения прибыли — аутсорсинг будет работать, и не нужно говорить о торможении. Если уважаемый автор считает, что Украине не хватает «продуктовых» компаний и готов это исправить собственноручно — то я желаю ему всяческих успехов на этом поприще, буду первым аплодировать в случае успеха. Если же всё сводится к тому, что «аутсорсинг — это плохо, а продакшн — это хорошо», то это уровень младшего научного сотрудника, который я не готов принять от столь серьёзного человека. Давайте говорить о прибыли (по моему опыту ситуация немного отличается от приведенной в статье), рисках (сравним риски аутсорсера и продактера), обороте, и т.п. Давайте говорить о финансовом климате. Давайте говорить о перспективных направления работы продуктовых компаний (кроме web’а, мир на нём клином не сошёлся), о рынках, на которые мы можем выйти (Украина — практически не рынок). Пока этого нет — см. комментарий #1 от Владимира.

Грубо говоря, стартапы хотят нанять хорошего разработчика за мало денег, а нетути — в оутсорсе

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

Три набивших оскомину вопроса должны быть заданы каждому участнику проекта на каждом скрам-митинге

ИМХО, вопросы в прямой форме (особенно со стороны ScrumMaster) приблизят Daily Scrum к формальному отчёту и несколько разрушат командную атмосферу. Мне кажется, что вопросы действительно следует задавать только вначале внедрения Scrum, когда команда ещё «не привыкла» к новому формату митингов.

Да, собсно по сабжу — Об эффективных совещаниях. Как показывает практика, наиболее долгими, нудными, болтливыми и как следствие — бесполезными совещаниями являются не те, которые посвящены отчётности и планированию, а те, которые предназначены решить (обычно задача ставится «обсудить» ) какую-то конкретную проблему или набор оных. Это совещания, к которым приходят неподготовленными, совещания без продуманной повестки, совещания с участием непримиримых противников, заинтересованных в провале оппонентов, обсуждения технических деталей «плавающими» в теме участниками, доооолгие совещания и просто совещания, на которые приглашаются более 7−9 человек. Есть ряд простых правил, которые позволяют избежать непродуктивной траты времени; первый же запрос в гугле выдал Top 7 Strategies for Productive Meetings. Как мне кажется, решением проблемы «неэффективных совещаний» будет просто следование этому common sense, а не введение Scrum:)

В той же час сучасний розвиток мікроелектроніки, коли вартість кремнієвих чипів набагато порядків дешевша за програмне забезпечення

весьма сомнителен, нужно делать оценку по BOM, development effort + team composition, support, production, marketing и т.д.Вцелом, Андрею + за то, что пытается продвинуть HW идеи на developers, пусть и несколько неуклюже;)

Коллеги, давайте отделим мух от котлет (прошу прощения за случайный каламбур).Разработка программного обеспечения всего лишь часть усилий в разработке конечного продукта. Есть спектр задач, которые лучше (проще, дешевле, быстрее) решать FPGA/CPLD/ASIC, и есть задачи, которые лучше решить программно. Решение определяется кучей внешних и внутренних по отношению к проекту факторов. Вроде бы уже все согласились что это так. О чём разговор? Просто хочется поговорить о том, что лучше выносить в железо? Андрей, напишите ещё одну статью — о задачах, которые удобно решать на FPGA и о методах демаркации по функционалу:) Превратим Developers в украинскую версию Electronix!