🫡

Removal of (mostly Russian) email addresses from MAINTAINERS

Posted Oct 21, 2024 13:57 UTC (Mon) by paulbarker (subscriber, #95785)
Parent article: Kernel prepatch 6.12-rc4

This was merged for v6.12-rc4: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
"Remove some entries due to various compliance requirements. They can come
back in the future if sufficient documentation is provided."

I guess this is something to do with sanctions, but I think the folks removed from the MAINTAINERS file deserve a little more informative notice than that!

https://lwn.net/Articles/994868/

Коммит
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6e90b675cf942e50c70e8394dfb5862975c3b3b2

А теперь вопрос: каким образом эти действия помогут Украине в войне против России?

#bio #article

Репушко пишет про эксперимент, показавший у каракатиц наличие бинокулярного зрения.

Эта картинка ждала 4 года

#prog #go #suckassstory

Пусть есть вот такая простая программа на Go:

package main

import (
   "fmt"
   "net"
)

func main() {
   func() {
      f, err := net.Dial("tcp", "1.1.1.1:443")
      defer f.Close()

      fmt.Println(err)
   }()
}

Если запустить эту программу при отсутствии сетевого подключения (например, на Go playground), то программа печатает ошибку и... Валится с nil pointer dereference:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4d0adb]

goroutine 1 [running]:
main.main.func1()
  /tmp/sandbox1770654708/prog.go:11 +0x3b
main.main()
  /tmp/sandbox1770654708/prog.go:14 +0xf

Почему так — в Go же в целом методы обычно не паникуют с nil-ресивером? Функция net.Dial из стандартной библиотеки возвращает (Conn, error), где Conn — не конкретный тип, а интерфейс (почему он включает в себя методы Read и Write вместо включения интерфейсов io.Reader и io.Writer — отдельный вопрос).

Так вот, как пояснено в 50 shades of Go, у присваивания интерфейсам nil есть два значения. Если интерфейсу присваивается nil-значение некоего не-интерфейсного типа, который может быть nil (скажем, некий указатель), то значимая часть интерфейса также будет nil, но указатель на таблицу методов будет заполнен от типа присваиваемого значения. Такая переменная будет давать false при тестирование на равенство с nil. Если же значению интерфейсного типа присвоить литерал nil напрямую (или просто не инициализировать явно), то тип нижележащего значения вывести неоткуда, а потому и значимая часть интерфейса, и указатель на таблицу методов будут nil. Такое значение будет давать true при тестировании на равенство с nil.

net.Dial, как и большинство функций в Go, возвращают первым значением nil в случае ошибки. В коде выше в конце main после Println срабатывает код в defer, который пытается вызывать метод Close, и так как у nil-интерфейса указатель на таблицу методов является nil, рантайм паникует, так как вытащить метод из ниоткуда, очевидно, нельзя.

Да, это значит, что поведение может поменяться, если net.Dial начнёт возвращать первое значение при ошибке иначе.

(thanks @HowToGoWrong)

#meme про теорию заговора

Оу вау. Машина Тьюринга из лего! Все эти звёзды смерти и соколы тысячелетия просто встали и вышли.

#cs #lego

Что примечательно — вся конструкция работает от кручения одного вала, и при этом даёт достаточно мало сопротивления, чтобы её можно было приводить в действие вручную. Рекомендую посмотреть видео с объяснением и демонстрацией в действии

#algo #article

Пусть у нас есть n элементов, каждый из которых указывает сам на себя. Как мы можем поменять связи так, чтобы объединить эти элементы в некий один цикл, и при этом мы могли бы получить каждый из вариантов перестановки связей с одинаковой вероятностью?

Про это есть Sattolo's algorithm, про который пишет небезызвестный Dan Luu. Он рассказывает не только о самом алгоритме, но и о том, почему он достигает поставленной цели — и при этом не предполагает наличия знаний по комбинаторике (как про это рассказывают в других источниках). Как ни странно, алгоритм Саттоло является минимальной модификацией алгоритма Фишера-Йетса — алгоритма для построения случайной перестановки.

#prog #abnormalprogramming #article

Vim is Turing-Complete

No, not VIMSCRIPT. Vim KEYSTROKES are Turing-complete.

(thanks @devballet)

разрешаю нормализацию

#ml #suckassstory

Результат был опубликован ещё 2 июля, но сам кандидат на звание BB(5) был найден ещё в 1960-ых годах

Тут, оказывается, биг дил случился. Доказали, что BB(5) = 47,176,870. Практического смысла в Busy Beaver не очень много, прямо скажем, но всё равно интересно.
- Тут можно почитать хорошую статью с деталями, историей и т.п.
- Тут само объявление об успехе
- А тут хорошие посты про это же, но кратко и прямо в телеге

#cs #math #science

#prog #suckassstory про невообразимо глупую ошибку:
https://t.iss.one/avvablog/2317

Напомнило, кстати, про #prog #math #article Turns are Better than Radians, которая аргументирует, что использование радианов для тригонометрических функций не особо осмысленно. В качестве одного из аргументов автор приводит тот факт, что одна из реализаций синуса для AVX (как и "pretty much every fast trig library", но тут уже предлагается верить автору на слово) первым шагом в вычислениях фактически делит аргумент на π, что зачастую является немедленной отменой умножения на π на вызывающей стороне.

Харальд Вельте (Harald Welte), известный разработчик ядра Linux, лауреат премии за значительный вклад в развитие свободного ПО, основатель организации gpl-violations.org, создатель проекта Openmoko и один из разработчиков netfilter/iptables, опубликовал своё мнение относительно удаления участников из списка мэйнтейнеров ядра Linux на основании их предполагаемой работы в подсанкционных компаниях. По словам Харальда, он гордился вовлечённостью в работу сообщества разработчиков ядра, но нынешнее сообщество не похоже на то, которое он помнит, и ему больно видеть, что сейчас там происходит. По его мнению нет ничего хуже дискриминации людей только из-за их паспорта, места жительства или места работы.
. . .
Помимо дискриминации разработчиков на основе их имени, email или работодателя, удивление вызвало то, что удаление произведено без каких-либо объяснений. Последующие разъяснения дали понять, что дело в санкциях, и удаление выполнено на основе консультации с юристами, но при этом не было предоставлено полного юридического анализа и не были отмечены вовлечённые в необходимость выполнения санкций субъекты (Linux Foundation? разработчики из США? Создатели дистрибутивов?).

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

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

Харальд Вельте выразил сожаление о том, во что превратилось Linux-сообщество
https://www.opennet.ru/opennews/art.shtml?num=62112