Есть ли способы гарантировать (желательно - в автоматическом режиме), что по пути в docker-образы, скачанные с зеркал, не добавилась какая-то вредоносная штука? Читай - что образы действительно соответствуют оным с докерхаба
В принципе, по GPLv2/v3 им не запрещено продавать, если по запросу покупателя они вышлют исходный код, включая свои изменения. Но я не в курсе, как реально с этим дела обстоят
Там, если вы добавляете сторонний репозиторий, то он может заменить вам любые файлы в системе, начиная от bash и заканчивая ядром.
Помимо распаковки пакета и запуска ручками, можно попробовать использовать каой-нибудь flatpak для того, чего нет в репозитории, ибо не всем подойдет вариант с распаковкой в условный /opt/. Зло? Да. Меньшее зло, чем third-party deb-пакет скриптами меняющий всё в системе? Да. Подойдет ли такая полумера каждому? Нет.
Наличие AUR в таком виде, когда из коробки есть условный pamac, который разрешает ставить софт из третьих источников (ред.: ладно, третьего источника — AUR) буквально в пару кликов, а человек не умеет/не хочет читать PKGBUILD, рано или поздно до добра не доведет.
Manjaro подойдет для опытного пользователя, которому, скажем, лень ковыряться с Arch ручками для начальной настройки, но для неопытного пользователя я бы поостерегся ее ставить
320 и 192 достаточно легко отличаются между собой на хорошо знакомом треке, в котором слушателю известна и слышима каждая мелочь, вроде нот на пэдах или легких ударов по хэту. Однако допускаю, что не на каждом хорошо знакомом треке это одинаково легко. Люди с более прокачанным слухом, может быть, могут и lossless от 320 отличить в подобной ситуации.
Вообще, по задумке, обработка вида if err != nil { return } не должна быть единственным способом обработки ошибки — ошибка иногда должна обрабатываться иначе (и не только на самом высоком уровне), реагировать на отдельный вид ошибок, или врапить ошибку в другую.
Например, слой бизнес-логики не должен ловить ошибки sql.ErrNoRows или mongo.ErrNoDocuments для того, чтобы произвести особую обработку, он должен отлавливать что-то наподобие repo.ErrNotFound.
В них я совершаю одну и ту же операцию — к слайсу дописываю новое значение и получаю новый слайс. При изменении значения в первом слайсе в первой программе второй слайс не изменится, во второй программе — изменится. По коду разница вроде бы лишь в способе инициализации изначального слайса. Я никогда не задумывался об этом нюансе, хотя знаю внутреннее устройство слайсов.
Почему программист, который пришел в Go из-за его простоты вообще должен заморачиваться о таких весьма неочевидных вещах?
И поэтому я не понимаю о какой простоте можно говорить в Го.
О простоте реализации. С логичностью мало общего имеет, что подтверждает комментарий AnthonyMikh с ссылкой на пост в соседней подветке.
Лично я не считаю дженерики злом. Более того, мне бы хотелось увидеть их в Go с привычным по другим языкам синтаксисом в виде угловых скобок. Но их мы не увидим, потому что "это сильно усложнит парсер". Скорее всего скобки будут квадратными
В таком случае - выглядит как огромная плоскость атаки для владельцев таких серверов
Есть ли способы гарантировать (желательно - в автоматическом режиме), что по пути в docker-образы, скачанные с зеркал, не добавилась какая-то вредоносная штука? Читай - что образы действительно соответствуют оным с докерхаба
Платится не подоходный, а НПД, который уже не вернуть через вычеты, через которые можно вернуть НДФЛ
В принципе, по GPLv2/v3 им не запрещено продавать, если по запросу покупателя они вышлют исходный код, включая свои изменения. Но я не в курсе, как реально с этим дела обстоят
deb-пакет для самого популярного браузера зачем-то прописывает свой репозиторий прямо в систему, хотя это вообще не задача deb-пакета.
Не стоит всех интровертов под одну гребёнку
"Миллионы мух не могут ошибаться"?
Это не совсем правда,
firefox-esrиchromiumследят по умолчанию. Максимум, что они предложат — это opt-out, но не opt-in.Помимо распаковки пакета и запуска ручками, можно попробовать использовать каой-нибудь flatpak для того, чего нет в репозитории, ибо не всем подойдет вариант с распаковкой в условный
/opt/. Зло? Да. Меньшее зло, чем third-party deb-пакет скриптами меняющий всё в системе? Да. Подойдет ли такая полумера каждому? Нет.Слишком уж часто это в third-party пакетах подается под соусом заботы о пользователях
Наличие AUR в таком виде, когда из коробки есть условный pamac, который разрешает ставить софт из третьих источников (ред.: ладно, третьего источника — AUR) буквально в пару кликов, а человек не умеет/не хочет читать PKGBUILD, рано или поздно до добра не доведет.
Manjaro подойдет для опытного пользователя, которому, скажем, лень ковыряться с Arch ручками для начальной настройки, но для неопытного пользователя я бы поостерегся ее ставить
320 и 192 достаточно легко отличаются между собой на хорошо знакомом треке, в котором слушателю известна и слышима каждая мелочь, вроде нот на пэдах или легких ударов по хэту. Однако допускаю, что не на каждом хорошо знакомом треке это одинаково легко. Люди с более прокачанным слухом, может быть, могут и lossless от 320 отличить в подобной ситуации.
Справедливости ради — во многом это не проблема убунту, а любого линукс-дистрибутива, где будет установлена GNOME и софт идентичный убунтовскому
Вообще, по задумке, обработка вида
if err != nil { return }не должна быть единственным способом обработки ошибки — ошибка иногда должна обрабатываться иначе (и не только на самом высоком уровне), реагировать на отдельный вид ошибок, или врапить ошибку в другую.Например, слой бизнес-логики не должен ловить ошибки
sql.ErrNoRowsилиmongo.ErrNoDocumentsдля того, чтобы произвести особую обработку, он должен отлавливать что-то наподобиеrepo.ErrNotFound.Спасибо
В Go очень многие вещи сложно понять, если не знаешь внутреннее устройство. Но с другой стороны, почему разработчик вообще должен об этом знать?
(наброс по теме пункта 44)
Есть два куска кода:
https://play.golang.org/p/HPBJGTstoRV
https://play.golang.org/p/HPBJGTstoRV
В них я совершаю одну и ту же операцию — к слайсу дописываю новое значение и получаю новый слайс. При изменении значения в первом слайсе в первой программе второй слайс не изменится, во второй программе — изменится. По коду разница вроде бы лишь в способе инициализации изначального слайса. Я никогда не задумывался об этом нюансе, хотя знаю внутреннее устройство слайсов.
Почему программист, который пришел в Go из-за его простоты вообще должен заморачиваться о таких весьма неочевидных вещах?
В любом случае, квадратные скобки лучше круглых, которые были предложены изначально
Будет повод попробовать — работа над дженериками уже ведется, через год может увидеть свет.
О простоте реализации. С логичностью мало общего имеет, что подтверждает комментарий AnthonyMikh с ссылкой на пост в соседней подветке.
Лично я не считаю дженерики злом. Более того, мне бы хотелось увидеть их в Go с привычным по другим языкам синтаксисом в виде угловых скобок. Но их мы не увидим, потому что "это сильно усложнит парсер". Скорее всего скобки будут квадратными