Вместо дополнений бойлерплейтов лучше бы занимались автоверификаторами. Нафига мне джуны, которые на пару с ИИ-джунами будут писать код, который потом вручную придется проверять на рейсы/дедлоки/кривую обработку исключений (в т.ч. с учетом взаимодействия с внешним миром)?
Описаны типичные рабочие сложности. И практика показывает, что даже в компаниях с развитым онбордингом и хелпдеском в какой-то момент возникают некомфортные задачи. И их решение - называется "работа".
В части про раздувание числа статей при ухудшении их качества автор, КМК, путает причину со следствием. Если оплачиваются хвосты вредителей, глупо расчитывать что люди не будут заводить фермы по размножению вредителей, а будут очищать пространство от них.
Spectre, Meltdown и т.д. это, во-первых, не закладки, а ошибки.
Классные такие "ошибки". Мне кажется, что когда обезьяна вынимает чеку из гранаты, которую ей вручили - она не ошибается (точнее, нельзя сказать, что "она ошибается"). Она просто "не думает". Именно это, если верить официальной информации, произошло при разработке фич, благодаря которым стали возможны подобные уязвимости.
Вопрос "ошибка это или уязвимость" требует анализа действий тех, кто поручал/контролировал такую разработку (аналогично тому, как расследование гипотетического инцидента с обезьяной подразумевает нахождение того, кто вручил ей эту гранату и выяснение его мотивов).
Как их использовать, если нет возможности прямого запуска кода не машине?
Для Spectre/Meltdown прямого запуска кода и не требовалось. Они эксплуатировались даже через javascript в браузере.
У нас практически вся инфраструктура в России (да что в России - в мире) построена на процах,где есть Spectre/Meltdown. Но что-то никаких массовых проблем не наблюдается.
Во всех современных ОС уязвимость закрыта на уровне ядер. Если где-то в критичных отраслях используются старые ядра или при загрузке передаётся флаг, отключающий фикс - то они ССЗБ.
Кстати, заодно отвечу на
Intel ME, Intel AMT - Не вдаваясь в рассуждения о том, насколько данные технологии безопасны, можно просто констатировать, что они реализованы на базе отдельного процессора на материнской плате и не являются частью CPU.
А современные ЦП разве могут нормально работать без технологий типа ME? Я вот тут разбирался с багом сетевой карты - фикс был как раз по направлению ME.
Почему-то прошивка телефонов такая сложная (всегда была). Не совсем понятно, почему нельзя прошивать отдельно драйвера/блобы из оригинальных прошивок и юзерспейс, собранный руками из проверенных сообществом исходников...
Или можно? Как васяны с колянами делают свои кастомные прошивки? Есть ли где-то цикл статей/инструкции/блогпосты?
Интересно, как с вашей точки зрения должен был бы бороться с таким положением вещей генеральный?
Т.е. получается, проблемы от того, что непонятны ответы на следующие вопросы. Это команда такая медленная (в описанном эпосе - платформы) или они реально чем-то сложным занимаются? Тот менеджер среднего звена приносит пользу или вред? Если у этой команды регулярно и с громким стуком падает система - это из-за криворукости, или просто у других команд системы не важные.
Да. Если бы этой информации не требовалось, то это была бы плохая строгая типизация. :)
Но ссылается только на общий объект контекста, а не на то, что в нём должен быть какой-то конкретный элемент c.
Иногда (в контексте DI) уже есть блоки, которые работают с более узким контекстом. Тогда их можно скомпозировать. К примеру, down можно ещё больше разбить:
// функция, которая умеет работать с общим контекстом
def down[F[_]: Applicative: WithContext[*[_], Ctx], A: Numeric: Extract[Ctx, *]](
y: A, z: A
) = {
// указываем способ работы с контекстом типа A
implicit val wc2: WithContext[F, A] =
WithContext[F, Ctx].extract(implicitly[Ctx Extract A])
bottom(y, z)
}
/* функция, которая умеет работать с более конкретным контектом. плюс используется синтаксис для
более компактного доступа к контексту
*/
def bottom[F[_]: Applicative: WithContext[*[_], A], A: Numeric](
y: A, z: A
) = {
val num = Numeric[A]
import num._
import tofu.syntax.context._
for {
c <- context
} yield (y + z) * c
}
Совсем кратко - это как в вашем примере со структурой k, только лениво - контекст (k) остается аргументом итоговой функции, складываемой в значение middleF в верхнем компоненте вычислений. Чуть более подробно - пояснено комментарием. Для ещё более подробного понимания, увы, придется изучить основы функционального программирования на Scala или Haskell
Выше в комментариях уже упоминали Scala. Но в той статье для передачи структуры контекста используется фича имплицитных параметров. Это совсем не то, что в моем примере.
И использовали, и боролись с последствиями активного использования этого способа. Разные люди выбирают совершенно разные объекты, где они считают допустимым временно похранить какое-то значение, которое они ленятся прокидывать нормально, поэтому при доработке подобного кода приходится анализировать чуть ли не всю кодовую базу.
На самом деле, современные языки стараются по возможности затруднить то, что вы описали с целью повышения понятности [чужого] кода. В частности, возможностью описывания неизменяемых переменных и структур. Вместо этого даются альтернативные области видимости объектов, развитые системы типов. Ну и возможности IDE по рефакторингу сейчас достаточно мощные.
И так или иначе, большинство языковых решений для решения обозначенной проблемы - это вариации на тему структуры-контекста (который вы назвали k), И обычно это используется для внедрения зависимостей (DI). Для передачи входных данных обычно используются аргументы функций/методов.
Вот, например, как страшноватенько подобный подход выглядит в Scala с использованием библиотек cats и tofu. Зато всё, что делает этот код понятно отражено в типах.
import cats.data.ReaderT
import cats.syntax.all._
import cats.{Applicative, Id}
import tofu.WithContext
import tofu.optics.Extract
import tofu.optics.macros.ClassyOptics
object ContextsAbuse extends App {
// Макроаннотация генерит линзы для выдирания членов структурыs
@ClassyOptics
// Собственно, описание структуры высокоуровнего контекста
final case class Ctx(
c: Int,
foo: String,
bar: Byte
)
/* Пояснение, какой тип в итоге имеют F в middle и down
по сути, это тип функции Ctx => A (т.е. f(ctx: Ctx): A)
*/
type RunF[A] = ReaderT[Id, Ctx, A]
def top(c: Int) = {
/* Получаем результат middle с погруженным в него результатом (зависящим от c,
которое внутри middle ещё неизвестно. По сути, здесь получается функция Ctx => Int,
с результатом частичного применения математической операции внутри down.
*/
val middleF = middle[RunF]
// На верхнем уровне формируем глобальный контекст нужного вида
val ctx = Ctx(c, "foo", 42)
// По сути, просто доприменяем частично-применённую middleF
middleF.run(ctx)
}
val get1 = 42
val get2 = 108
/* Здесь нет никакого знания того, что в контексте есть c: Int (но есть знание всей структуры контекста)
при разработке в промежуточном коде, которого может быть много, править ничего не потребуется
*/
def middle[F[_]: Applicative: WithContext[*[_], Ctx]] = {
val y = get1
val z = get2
down(y, z)
}
/* Страшненькая сигнатура говорит о том функция определена для любых типов-"эффектов" F,
инкапсулирующих понятие контекста Ctx, для любых типов A (с "числовыми" операциями) и
возможностью "выдрать" значение типа A из контекста Ctx
*/
def down[F[_]: Applicative: WithContext[*[_], Ctx], A: Numeric: Extract[Ctx, *]](y: A, z: A) = {
val num = Numeric[A]
import num._
/* Отображем выдираемое из контекста Int поле на результат операции, использующей
это значение. Результирующее значение остаётся "обрамлено" в типе эффекта F
Получено оно будет уже в top в .run
*/
WithContext[F, Ctx].extract(implicitly[Ctx Extract A]).context.map { c =>
(y + z) * c
}
}
println(top(19))
}
А где написано про $1000 у Тинькова? Я вчера облазил сайт и ничего не нашел. В FAQ у них устаревшая информация по валюте. Такое ощущение что только в Телеграм инфа была.
Просто у советского блока был в несколько раз меньше ресурс талантливых инженеров, тех, кого реально можно называть настоящим креативным классом.
Это гигантское упрощение, на которое можно найти сразу несколько контрагргументов:
1) А у разных Южных Корей, где население ещё меньше, где нашли талантливых инженеров? 2) Если речь о том, что этих талантливых инженеров можно было "закупить зарубежом", то почему этой закупкой не решили данную проблему (тем более, что за рубежом закупали, и в том числе инженеров?
Нет, увы, проблема не в этом и в своём рассказе про вашу личную историю в электронике вы как раз об этом говорили.
А причина в том, что [в особенности] после отмены такой формы собственности, как артели, без "человека из партии" любые предприятия существовать не могли. И непосредственной причины отсутствия инноваций или даже просто эффективного хозяйствования было отсутствие знающих и умеющих людей на руководящих постах, к которому, в своё время приводил запрет строя на приход таких людей к власти.
И отгрузка, и приёмка есть и у сервисных продуктов.
Отгрузка (деливери) определённой версии продукта, реализованного как сервис, - это когда конкретные пользователи начинают получать фичи, заявленные для этой версии (или без привязки к ней) в рамках согласованных пользовательских сценариев. Приёмка - это когда мы (или наше начальство или заказчик/эксплуатант сервиса) убеждаемся, что то, как эти фичи работают - это как раз то, что хотели в рамках реализации пользовательских сценариев.
Вот gitlab (CE/EE) - это сервис или продукт? С одной стороны это конкретный код, который доступен в рамках сервиса gitlab.com (совместно с другим кодом, который неотчуждаем). С другой стороны, это набор фич, который вы можете применять на своём собственном железе.
Согласен про непродуктивность споров о терминологии, но в эти частности закопались вы, утверждая что среди неотчуждаемых сервисов не может быть продуктов. :) По такой логике даже коробочная винда - это не продукт. Ведь при её "покупке" вам не дают ИАП или хотя бы лицензии делать с ней всё, что лично вы хотите - а дают лишь коробочку, CD и немного макулатуры. А для OEM инсталляций винды - и того меньше (и не давали бы вовсе, если бы M$ не приучила пользователей к красивым наклейкам).
В вашем примере office.com и hotmail - это один сервис? Нет. Это два разных продукта (хотя, конечно, какая-то взаимосвязанность там есть). Точнее, это - Product Service System (PSS), как это называется по научному, или PaaS, как не совсем правильно, но всё же в целом верно (т.к. P там - это скорее Platform, что несколько большее, чем продукт).
Или например, часто бывает так, что сервис есть (обычно бесплатный). Но нет ни доки на него, ни SLA. И когда, например, добавить ещё одного пользователя в нём - жуткий квест. Продуктом такой сервис сложно назвать. Скорее, это какой-то "витамин" для тех, кто им по какой-то причине вынужден пользоваться.
Можно себе представить платформенный продукт, который сложно или нельзя отчуждить - например из-за используемых NDA компонентов. Но его при этом можно продать - т.е. дать доку на сервис, физические изделия и т.д
Т.е. разделение простое:
Продукт - это набор фич, ценных для пользователя
Проект - набор согласованных бизнес-процессов (направленный на добавление или убирание фич, либо не связанный с ними)
если хочется производительности, то никак. лучше протянуть видео и USB кабель, если хочется прямо тихого решения.
а так - я пользовался xpra
Вместо дополнений бойлерплейтов лучше бы занимались автоверификаторами. Нафига мне джуны, которые на пару с ИИ-джунами будут писать код, который потом вручную придется проверять на рейсы/дедлоки/кривую обработку исключений (в т.ч. с учетом взаимодействия с внешним миром)?
Не заметил про "совок". Да и автор издалека.
Описаны типичные рабочие сложности. И практика показывает, что даже в компаниях с развитым онбордингом и хелпдеском в какой-то момент возникают некомфортные задачи. И их решение - называется "работа".
В части про раздувание числа статей при ухудшении их качества автор, КМК, путает причину со следствием. Если оплачиваются хвосты вредителей, глупо расчитывать что люди не будут заводить фермы по размножению вредителей, а будут очищать пространство от них.
Но его же (retpoline) в итоге починили? падме_анакин.jpg
Не сталкивались с проблемой производительности при большом количестве карточек на доске? https://github.com/kanboard/kanboard/issues/5036
У меня ощущение, что это в относительно поздних версиях появилось.
Классные такие "ошибки". Мне кажется, что когда обезьяна вынимает чеку из гранаты, которую ей вручили - она не ошибается (точнее, нельзя сказать, что "она ошибается"). Она просто "не думает". Именно это, если верить официальной информации, произошло при разработке фич, благодаря которым стали возможны подобные уязвимости.
Вопрос "ошибка это или уязвимость" требует анализа действий тех, кто поручал/контролировал такую разработку (аналогично тому, как расследование гипотетического инцидента с обезьяной подразумевает нахождение того, кто вручил ей эту гранату и выяснение его мотивов).
Для Spectre/Meltdown прямого запуска кода и не требовалось. Они эксплуатировались даже через javascript в браузере.
Во всех современных ОС уязвимость закрыта на уровне ядер. Если где-то в критичных отраслях используются старые ядра или при загрузке передаётся флаг, отключающий фикс - то они ССЗБ.
Кстати, заодно отвечу на
А современные ЦП разве могут нормально работать без технологий типа ME? Я вот тут разбирался с багом сетевой карты - фикс был как раз по направлению ME.
Почему-то прошивка телефонов такая сложная (всегда была). Не совсем понятно, почему нельзя прошивать отдельно драйвера/блобы из оригинальных прошивок и юзерспейс, собранный руками из проверенных сообществом исходников...
Или можно? Как васяны с колянами делают свои кастомные прошивки? Есть ли где-то цикл статей/инструкции/блогпосты?
Интересно, как с вашей точки зрения должен был бы бороться с таким положением вещей генеральный?
Т.е. получается, проблемы от того, что непонятны ответы на следующие вопросы. Это команда такая медленная (в описанном эпосе - платформы) или они реально чем-то сложным занимаются? Тот менеджер среднего звена приносит пользу или вред? Если у этой команды регулярно и с громким стуком падает система - это из-за криворукости, или просто у других команд системы не важные.
Да. Если бы этой информации не требовалось, то это была бы плохая строгая типизация. :)
Но ссылается только на общий объект контекста, а не на то, что в нём должен быть какой-то конкретный элемент c.
Иногда (в контексте DI) уже есть блоки, которые работают с более узким контекстом. Тогда их можно скомпозировать. К примеру, down можно ещё больше разбить:
Совсем кратко - это как в вашем примере со структурой k, только лениво - контекст (k) остается аргументом итоговой функции, складываемой в значение middleF в верхнем компоненте вычислений. Чуть более подробно - пояснено комментарием. Для ещё более подробного понимания, увы, придется изучить основы функционального программирования на Scala или Haskell
Выше в комментариях уже упоминали Scala. Но в той статье для передачи структуры контекста используется фича имплицитных параметров. Это совсем не то, что в моем примере.
И использовали, и боролись с последствиями активного использования этого способа. Разные люди выбирают совершенно разные объекты, где они считают допустимым временно похранить какое-то значение, которое они ленятся прокидывать нормально, поэтому при доработке подобного кода приходится анализировать чуть ли не всю кодовую базу.
На самом деле, современные языки стараются по возможности затруднить то, что вы описали с целью повышения понятности [чужого] кода. В частности, возможностью описывания неизменяемых переменных и структур. Вместо этого даются альтернативные области видимости объектов, развитые системы типов. Ну и возможности IDE по рефакторингу сейчас достаточно мощные.
И так или иначе, большинство языковых решений для решения обозначенной проблемы - это вариации на тему структуры-контекста (который вы назвали k), И обычно это используется для внедрения зависимостей (DI). Для передачи входных данных обычно используются аргументы функций/методов.
Вот, например, как страшноватенько подобный подход выглядит в Scala с использованием библиотек cats и tofu. Зато всё, что делает этот код понятно отражено в типах.
А где написано про $1000 у Тинькова? Я вчера облазил сайт и ничего не нашел. В FAQ у них устаревшая информация по валюте. Такое ощущение что только в Телеграм инфа была.
Это гигантское упрощение, на которое можно найти сразу несколько контрагргументов:
1) А у разных Южных Корей, где население ещё меньше, где нашли талантливых инженеров?
2) Если речь о том, что этих талантливых инженеров можно было "закупить зарубежом", то почему этой закупкой не решили данную проблему (тем более, что за рубежом закупали, и в том числе инженеров?
Нет, увы, проблема не в этом и в своём рассказе про вашу личную историю в электронике вы как раз об этом говорили.
А причина в том, что [в особенности] после отмены такой формы собственности, как артели, без "человека из партии" любые предприятия существовать не могли. И непосредственной причины отсутствия инноваций или даже просто эффективного хозяйствования было отсутствие знающих и умеющих людей на руководящих постах, к которому, в своё время приводил запрет строя на приход таких людей к власти.
И отгрузка, и приёмка есть и у сервисных продуктов.
Отгрузка (деливери) определённой версии продукта, реализованного как сервис, - это когда конкретные пользователи начинают получать фичи, заявленные для этой версии (или без привязки к ней) в рамках согласованных пользовательских сценариев. Приёмка - это когда мы (или наше начальство или заказчик/эксплуатант сервиса) убеждаемся, что то, как эти фичи работают - это как раз то, что хотели в рамках реализации пользовательских сценариев.
Вот gitlab (CE/EE) - это сервис или продукт? С одной стороны это конкретный код, который доступен в рамках сервиса gitlab.com (совместно с другим кодом, который неотчуждаем). С другой стороны, это набор фич, который вы можете применять на своём собственном железе.
Согласен про непродуктивность споров о терминологии, но в эти частности закопались вы, утверждая что среди неотчуждаемых сервисов не может быть продуктов. :) По такой логике даже коробочная винда - это не продукт. Ведь при её "покупке" вам не дают ИАП или хотя бы лицензии делать с ней всё, что лично вы хотите - а дают лишь коробочку, CD и немного макулатуры. А для OEM инсталляций винды - и того меньше (и не давали бы вовсе, если бы M$ не приучила пользователей к красивым наклейкам).
В вашем примере office.com и hotmail - это один сервис? Нет. Это два разных продукта (хотя, конечно, какая-то взаимосвязанность там есть). Точнее, это - Product Service System (PSS), как это называется по научному, или PaaS, как не совсем правильно, но всё же в целом верно (т.к. P там - это скорее Platform, что несколько большее, чем продукт).
Или например, часто бывает так, что сервис есть (обычно бесплатный). Но нет ни доки на него, ни SLA. И когда, например, добавить ещё одного пользователя в нём - жуткий квест. Продуктом такой сервис сложно назвать. Скорее, это какой-то "витамин" для тех, кто им по какой-то причине вынужден пользоваться.
Можно себе представить платформенный продукт, который сложно или нельзя отчуждить - например из-за используемых NDA компонентов. Но его при этом можно продать - т.е. дать доку на сервис, физические изделия и т.д
Т.е. разделение простое:
Продукт - это набор фич, ценных для пользователя
Проект - набор согласованных бизнес-процессов (направленный на добавление или убирание фич, либо не связанный с ними)
Здесь это не причём. Человек поделился своим опытом экономически-успешного (судя по статье) предприятия.
Вы критикуете этого человека. Логично предположить, что у вас есть более успешный кейс.
Расскажите о своем предприятии. Очень интересно узнать другой опыт
Верно. Не очень понял, что вы отвечаете на коммент чела который предлагат вносить баги, что бы потом их править. :)