Обьясните пожалуйста логику названий сетевых интерфейсов в новых убунтах

Возможно, я что-то пропустил, но давно ли ядро и core-utils стали собирать с помощью питона?

я думаю, до такого позора кернел не дойдёт :)

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

он просто ненужен. нигде. тут даже обсуждать нечего

Настолько не нужен, что входит в пятерку самых популярных языков (в декабре прошлого года был 4)? Да-да, охотно верю. Кстати, как там с переполнением буфера дела обстоят в C и в Питоне?

популярный - не значит, нужный. ламеров миллиарды. самое тупое есть самое популярное.

переполнение буфера - проблема в голове программиста, а не в языке программирования. у ламеров оно случается постоянно.

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

Я думаю, всё с питоном хорошо. Свою нишу нового Васика он занимает идеально. Лишь бы не высовывался.

Вы опять хотите сказать, что есть универсальный язык, одинаково подходящий для десктопа, чайников, шаттлов и веба?

В треде остро не хватает лисперов. Куда катится ЛОР? Где лисперы?

При этом я еще ни разу не видел *слишком* медленных программ на Питоне

Я видел.

А так и Васика на БК-0011 хватало, чтобы математическое выражение посчитать.

Есть Java + куча языков, компилирующихся в жабский байт-код. Есть PHP. Есть LuaJIT для встраиваемых решений.

Есть хоть и медленный, но доступный даже на кофеварках Perl.

Есть Ruby, если уж хочется почувствовать себя хипстером.

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

А buffer overflow, нулевые указатели в C

Это не проблема, а суть фоннеймановской архитектуры. Код с автоматической сборкой мусора и принудительным контролем границ никогда не сможет использоваться в действительно критичных точках программной системы. Ядро ОС и основные библиотеки — это Си и только Си.

Ни скорости. Ни легковесности. Ни удобства.

Все это субъективно. Как по мне, Питон все 3 критерия соблюдает. И да, он тоже компилируется в байт-код.

Код с автоматической сборкой мусора и принудительным контролем границ никогда не сможет использоваться в действительно критичных точках программной системы. Ядро ОС и основные библиотеки — это Си и только Си.

Я уже писал, что перед Питоном никогда и не стояло задачи быть системным ЯП с высокой степенью отклика. Гвидо даже не рассчитывал заменить им Си. Он хотел получить прослойку между С и шеллом, чтобы она была проще 1-й и эффективнее 2-й. Что вы все время пытаетесь натянуть сову на глобус... Вон, математики, к примеру, успешно используют те же Octave, Matlab, R (и Python, кстати, тоже). Прикажете им на голом C кодить?

популярный - не значит, нужный. ламеров миллиарды. самое тупое есть самое популярное.

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

переполнение буфера - проблема в голове программиста, а не в языке программирования.

Нет, это как раз-таки проблема языка. Питон разруливает такие тупые моменты, и эксплуатировать в нем переполнение буфера можно только в системных библиотеках, написанных на C, но не в производном коде.

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

ламеры могут писать на чём угодно. если у них нет мозга

Есть ситуации, когда писать на голом C просто неэффективно. Тот же пример с математиками. Мозг как раз-таки и дан для того, чтобы уметь применять средства *в зависимости* от ситуации. То, что средства могут быть разные, говорит о гибкости мышления, а никак не о тугоумии.

Да, но таковых сейчас 98% :-(

Ядро ОС и основные библиотеки — это Си и только Си.

У тебя ограниченный кругозор.

это не повод для грусти. 2% профессионалов легко уделают толпу говнокодеров, если только они захотят.

Если подвернется случай. Кроме того довольно часто для достижения цели не хватает напарника :-(

Все это субъективно.

Вон там выше по треду были тесты скорости исполнения кода. Очень субъективные, да.

И да, он тоже компилируется в байт-код.

Дада, пилили мы pypy, пилили... Которого V8 обгоняет влёт, ну а luajit просто уделывает как бог — черепаху. Про каноническую реализацию питона и вспоминать стыдно — там питонистам остаётся только сесть, закрыть голову руками и заплакать. От безысходности.

Гвидо даже не рассчитывал заменить им Си. Он хотел получить прослойку между С и шеллом, чтобы она была проще 1-й и эффективнее 2-й.

Одно можно сказать точно: проще не получилось. Язык, в котором нужно считать пробелы, чтобы писать синтаксически корректный код, не имеет права на существование в этой вселенной. Я думал, после студенческой поделки make (реально студенческой) хуже придумать уже нельзя. Оказалось, льзя.

Что касается «эффективнее», то сравнивать ЯП общего назначения с shell, чтобы говорить «у нас код эффективнее» — это я не знаю... Сильно надо опуститься. Надо еще с Tcl сравнить, ага. Или с command.com.

это всё отмазки, на самом деле :) если не лениться, можно много чего успеть сделать и в одну каску. а там, глядишь, и соратники подтянутся. правда, в последнее время я больше вижу, как «активные помощники» загаживают хорошие в прошлом проекты своим говнокодом. так что тут надо быть очень аккуратным в выборе тех, кого можно допустить к коду.

Вон там выше по треду были тесты скорости исполнения кода. Очень субъективные, да.

Я посмотрел 2 примера решения Фибоначчи на Питоне. Ваш код

def fib(n):
	if n < 2:
		return 1 
	return fib(n - 2) + fib(n - 1)

def fib2(n):
	from math import sqrt # Да-да, импорт вставлен в счетчик. Это не намного влияет :-)
	return ((1+sqrt(5))**n-(1-sqrt(5))**n)/(2**n*sqrt(5))

def fib3(n):
    """Fibonacci numbers generator, first n"""
    a, b, counter = 0, 1, 0
    while True:
        if (counter > n): return
        yield a
        a, b = b, a + b
        counter += 1

f = fib3(34)
for x in f:
    print(x,)
print()

Язык, в котором нужно считать пробелы

Шта? Вы пишите в блокноте? IDE после Enter ставит нужный отступ автоматически.

писать синтаксически корректный код, не имеет права на существование в этой вселенной.

Да-да, лучше каша в фигурных скобочках.

Что касается «эффективнее», то сравнивать ЯП общего назначения с shell, чтобы говорить «у нас код эффективнее» — это я не знаю... Сильно надо опуститься.

Эффективнее - это значит эффективнее. Это не значит, что результирующий код обязательно быстрее. Это значит, что в определенных случаях эффективнее работать с python, а не shell. Что вас тут так поражает? Да, многотысячная замена по .replace сработает намного быстрее sed.

выдает 9227465, хотя должно быть 5702887.

Там в примерах была ошибка < vs <=. Поскольку она копипастой проникла во все примеры, на суть измерений она не влияет.

Шта? Вы пишите в блокноте? IDE после Enter ставит нужный отступ автоматически.

Питонисты полностью оторваны от реальности. Код может писаться в IDE, в блокноте, хоть в чёрте лысом — лишь бы чёрт умел ASCII. Вы даже не представляете, где и в каких условиях случается править код, особенно если «всё пропало, это надо сделать вчера». Нет, надо везде иметь православно настроенную IDE. Спасибо, не надо.

Да-да, лучше каша в фигурных скобочках.

Вон недавно 8 страниц обсуждали, почему nginx не приводит домен к нижнему регистру. Всем не мешало, а кому-то вдруг помешало. Скобочки — из того же разряда. Что-то очень личное, видимо.

Скобочки, в отличие от, каши из пробелов и табуляций, видны в любом редакторе одинаково.

Это значит, что в определенных случаях эффективнее работать с python, а не shell. Что вас тут так поражает?

Поражает полное непонимание собеседником того факта, что это инструменты в разных нишах. «Мясорубка эффективнее топора при изготовлении фарша». Почему-то мясорубку модели X сравнивают не с мясорубкой модели Y, а с торопом. Поражает.

Нет, надо везде иметь православно настроенную IDE.

Нет, не надо. Я первые 10.000 строк в Питоне написал в nano. Пару раз нажать на Tab - ничего не отвалится.

каши из пробелов и табуляций

Ставьте только пробелы или только табуляцию, кто ж мешает. По крайней мере, это прочитать можно, не сломав глаза, в отличие от.

Поражает полное непонимание собеседником того факта, что это инструменты в разных нишах.

Я это с самого начала твержу. Iron_Bug удивляется, с чего вдруг php медленный в математических тестах (у него задача другая, блджад), вы тоже какие-то надуманные синтетические тесты предлагаете, хотя, когда все делается по уму, получается все достаточно неплохо. Да, действительно, у этих языков разные сферы применения, нахрена их в числодробилке гонять? Ну гоняйте Cython, если очень надо, есть же отдельные реализации, заточенные под скорость.

А что касается python и shell, то тут тоже ничему удивляться не надо. Один, естественно, не служит заменой другому. Имелось в виду, что один может быть эффективнее другого в *определенных задачах*. Я думал, что контекст очевиден. Видимо, нет.

Посоны, есть проблема.

Есть девайс, apu2c4.

Для тех кто не в курсе - это x86_64 платка, со встроенной памятью, mSATA и тд, без видео.

Так исторически сложилось, что единственным способом запустить там ОС - это снять ССД, поставить Убунточку\Дебиан на стационарном ПеКа, и возвернуть ССД обратно. Раньше так и было. И раньше я юзал простой bash-скрипт с вызовом iwconfig\dhclient для wlan0 для подключения к вафле. И для pppoe.

Теперь я в душе не гребу как называется мой сетевой интерфейс, как беспроводной, так и проводные (там их три).

По какой закономерности эта уйня вообще придумывает имена?

Опциональный вопрос: накуя надо было ломать мою сеть?

- - -

Пажалста, не советуйте мне ставить Генту, юзать эти юниты с удевами и прочие костыли, просто подскажите мне КАК Я МОГУ УГАДАТЬ НАЗВАНИЕ МОЕГО СЕТЕВОГО ИНТЕРФЕЙСА?

Спасибо!

накуя надо было ломать мою сеть

Вопросы к Поттерингу мейнтейнерам дистрибутива.

Пажалста, не советуйте мне ставить Генту

И не надо генту - ставь слаку.

КАК Я МОГУ УГАДАТЬ НАЗВАНИЕ МОЕГО СЕТЕВОГО ИНТЕРФЕЙСА

Погадай на /dev/unrandom А треде разбирали принцип присваивания.

Не страдай гадая, а напиши в автозапуске ip l/ifconfig > /some/file, а потом посмотри в него глазами (такие штуки на голове) в файл и не имей мозг.

Да, многотысячная замена по .replace сработает намного быстрее sed.

Врядли. Sed/grep утилиты постоянно оптимизируют.

во-первых, можно вернуть старые названия интерфейсов. Например, прописав net.ifnames=0 в параметрах загрузки ядра.

во-вторых, в конфигах networkd можно прописать match не по названию интерфейса, а по MAC-адресу, что я и сделал на своей системе. Читайте маны systemd, там все написано.

Это одна из причин, почему рабочие скрипты пришлось перетащить на python. У bash очень высокий IO и замена через sed выполняется намного медленнее.

Так себе бенч. Точнее — никак.

Никак - напиши свой. То, что в баше выполнялось 5 минут, в питоне выполнилось за секунду. Это мой личный опыт. Не веришь - убеждать не собираюсь.

Но ведь тест действительно никакой. В первом случае файл обрабатывается через mmap, во втором даже обратного позиционирования не возможно. sed, конечно, весьма быстр, но это почти ЯП, парсер его скрипта довольно громоздок, он его компилит, а потом по сути вызывает библиотечный regexp() и в зависимости от результата выполняет действия по дереву скомпиленного кода инструкций. По этому, простой тест на другом ЯП, где скрипт простой может заметно обогнать sed, а уж если надо вызывать несколько раз из bash fork()+exec(/bin/sed) то и разговора быть не может.

а уж если надо вызывать несколько раз из bash fork()+exec(/bin/sed) то и разговора быть не может

В том-то и дело. Когда надо несколько тысяч раз сделать sed, скорость замены падает в разы. Даже если sed в контейнере, а не получает файл на входе.

Отчасти эта точка зрения мне понятна. Но мне не понятно зачем тратить свое время и нервы на выпиливание чего-то. Если вам не нравится systemd/gnome/python/gtk/etc, то не проще ли сразу уйти на OpenBSD и получить отсутсвие всего этого «из коробки»?

Тут проблема в том, что это BSD.

не проще. я программист и для меня важно, на какой системе сидеть.

Мне просто интересно - чем так не угодил Python?

единственный минус - С и плюсы требуют наличия мозга.

Не лопни от самомнения. На С может писать любая макака, осилившая адресную арифметику. А наличие мозга нужно проектировщикам и тем, кто пишет в специфических областях.

генту
генту
генту

расскажи ещё.

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