LINUX.ORG.RU
решено ФорумAdmin

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

 


2

5

Пришлось тут поставить две убунты 16.04. Если раньше сетевые интерфейсы обозначались как eth0, eth1 и т.д. что вполне логично, то недавно поставив на один комп с двумя сетевыми картами я получил enp1s0 и enp2s0. Ну ладно, поменяли обозначения, если я воткну третью карту, я скорее всего получу enp3s0. Но когда я поставил её же на второй комп, я внезапно получил enp2s0 и enp3s2. Что значат эти сокращения и эти цифры? откуда она их берет?

★★

Последнее исправление: null123 (всего исправлений: 1)

Ответ на: комментарий от Iron_Bug

ибо я видела, как он работает, на реальных серверах

И что же такого страшного ты видела?

потому что пистон - язык для обучения школоты

Я даже не знаю как на такие вбросы реагировать.

King_Carlo ★★★★★
()
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от templarrr

А если бы systemd был только инитом все было бы хорошо.

Инкрементирую. Юниты таки удобные. Всё остальное, правда, омерзительно.

sand_circle
()
Ответ на: комментарий от King_Carlo

Хуже пистона может быть только извращение вроде си-диеза или гуглоГО.

anonymous
()
Ответ на: О, про перл тоже соглашусь. от Deleted

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

luajit

вы не можете выделить больше 1Гб памяти в 64битной системе, потому что... потому что зачем выделять больше 1гб памяти в серверных приложениях в 2k17, действительно.

Ip0 ★★★★
()
Ответ на: комментарий от Ip0

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Ip0

вы не можете выделить больше 1Гб памяти в 64битной системе, потому что... потому что зачем выделять больше 1гб памяти в серверных приложениях в 2k17, действительно.

Учитывая его нишу, ему это не мешает.

Я тут делал на коленке тестирование скорости реализаций всяких языков, и получается как-то так:

=> gcc-O2          fib                 0.04 s,    1484 KB,   124197766 Refs
=> clang-O2        fib                 0.04 s,    1484 KB,   173367019 Refs
=> nwcc            fib                 0.09 s,    1456 KB,   387784001 Refs
=> tcc             fib                 0.11 s,    1476 KB,   304732061 Refs
=> clang-O0        fib                 0.12 s,    1484 KB,   332412223 Refs
=> gcc-O0          fib                 0.13 s,    1480 KB,   313935719 Refs
=> luajit          fib                 0.18 s,    2160 KB,   586297310 Refs
=> nodejs          fib                 0.28 s,   19912 KB,  1095571416 Refs
=> pypy            fib                 0.57 s,   62304 KB,  1194800405 Refs
=> neko            fib                 0.67 s,    2860 KB,           - Refs
=> php             fib                 1.42 s,   10508 KB,  4556506419 Refs
=> ruby            fib                 2.26 s,    7392 KB,  7197054652 Refs
=> lua             fib                 3.27 s,    2196 KB,  9966924319 Refs
=> python2         fib                 6.12 s,    5240 KB, 17615211508 Refs

3-й столбец — время исполнения сэмпла на реальном железе, 4-й — потребление памяти, 5-й — количество исполненных инструкций под valgrind.

Картина получается неутешительная: для пыхтона всё очень и очень печально. Писать на нем что-то требующее интенсивных вычислений явно не стоит.

luajit единственный может по скорости приблизиться к неоптимизированному коду на Си.

Deleted
()
Ответ на: комментарий от Deleted

Я тут делал на коленке тестирование скорости реализаций всяких языков

С методикой тестирования можно ознакомиться? И код, на каждом из представленных языков, неплохо бы показать.

King_Carlo ★★★★★
()
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от Ip0

Привет путешественникам из будущего, кстати

2k17

2170?

Deleted
()
Ответ на: комментарий от Deleted

где perl?)

...а также java, python3 и прочие. Не доделаны. Действительно, надо бы доделать да залить на гитхаб.

Deleted
()
Ответ на: комментарий от O02eg

Это результаты от свежего руби, 2.3.

Deleted
()
Ответ на: комментарий от Deleted

Ого, питон уже и рубям сливает, кто бы мог подумать. Правда есть же пипи) Но чего это он столько памяти выжрал? Жаба покусала?

bread
()
Ответ на: комментарий от King_Carlo

С методикой тестирования можно ознакомиться?

Методика: «а хрен его знает, я код полтора года назад писал». Многократно запускается выполнение примера через /usr/bin/time и берётся меньшее из всех полученных значений для времени выполнения процесса.

И код, на каждом из представленных языков, неплохо бы показать.

Си:

#include <stdio.h>

static unsigned int fib(unsigned int n) {
    if (n < 2) return 1;
    return fib(n - 2) + fib(n - 1);
}

int main()
{
    printf("%u\n", fib(34));
    return 0;
}

Луа:

function fib(n)
    if n < 2 then
        return 1
    end
    return fib(n - 2) + fib(n - 1)
end

print(fib(34));

Питон:

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


print (fib(34))

Остальное лень копировать, в целом везде то же самое.

Deleted
()
Ответ на: комментарий от Deleted

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonymous

A ты еще один наркоман на пару с этим чудиком ширяетесь

anonymous
()
Ответ на: комментарий от King_Carlo

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от bread

Правда есть же пипи) Но чего это он столько памяти выжрал?

Вот это меня вообще выморозило. Вроде весь из себя такой распиаренный, при этом по скорости работы не далеко ушел от nekovm, которая вообще-то (насколько я знаю, — но, может, я ошибаюсь?) обычный интерпретатор байткода без космических технологий. И — 62 мегабайта на программу из 4 строк.

ЧЯДНТ? Я поставил самый обычный pypy из реп дистрибутива и запустил как обычный питон. Может ему сначала жертву надо принести?

Deleted
()
Ответ на: комментарий от Iron_Bug

Питон + говнокодеры — это смертельное комбо.

У знакомого организация заказала изготовление новой версии корпоративного сайта у какой-то местной шарашкиной конторы. Те от большого ума взяли Django и приступили к творчеству. По договору должны были закончить за 4 месяца, а провозились почти год. А когда попытались запустить всё это на мощностях хостинга, где крутился старый сайт, уперлись в ограничения аппаратных ресурсов, выделенных аккаунту. Как только менеджер пытается залить на сайт новые товары с фоточками, всё встаёт раком, и хост прибивает процессы питона.

Пришлось разработчикам хостить своё творение на собственном железе, но оно и там умудряется тормозить и падать.

Deleted
()
Ответ на: комментарий от Deleted

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Ну, некоторые используют...

У меня знакомый результаты наблюдений обрабатывает в пхытоне. Но я пхытон за серьезный ЯП не считаю и предпочитаю на сях велосипедить.

Вот посмотрел: для работы с SBIG'овской all-sky кто-то написал пхытонокод. Да, компактно, но нихрена не понятно. Да и я собираюсь его в качестве демона на серваке запускать — ясен пень, пхытон тут никаким боком не подойдет!

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

anonymous
()
Ответ на: комментарий от Deleted

Ну кто так Фиббоначи пишет, это же позор джунглям. Будут дикие просадки в скорости выполнения алгоритма и потребление памяти на стеке как не в себя.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от anonymous

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Sunderland93

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

slapin ★★★★★
()
Ответ на: комментарий от AVL2

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

slapin ★★★★★
()
Ответ на: комментарий от Deleted

А если так?

import annotation.tailrec

def fibbonacci(n: Int): Int = {
  @tailrec
  def runFibonacci(comp1: Int, comp2: Int, acc: Int, n: Int) : Int = n match {
    case 0 | 1 => acc
    case _ =>
      runFibonacci(comp2, comp1 + comp2, comp1 + comp2, n - 1)
  }
  runFibonacci(0, 1, 1, n)
}


val result = fibbonacci(60)
Console.println(s"result = ${result}")
LongLiveUbuntu ★★★★★
()
Последнее исправление: LongLiveUbuntu (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

как говно в бочке мёда, системдэ моментально отравляет всё вокруг себя.

Как точно сказано!

Tanger ★★★★★
()
Ответ на: комментарий от Iron_Bug

Ну кому принадлежат все эти люди мы знаем, так что ничего удивительного нет. Из обычного Debian systemd выпиливается, но udev теперь часть systemd, а эта хрень захардкожена в нём и никакими методами кроме правки исходников не выпиливается. Можно конечно жить с хренью в коммандлайне, и конфигах, но лучше и надёжнее просто выпилить в исходниках. И эта возможность таки всё ещё является преимуществом Linux, не смотря на моровое поветрие. Поэтому пока живём.

slapin ★★★★★
()
Ответ на: комментарий от King_Carlo

Праздный интерес, на каком железе ты гонял тесты?

Celeron B800 1.50GHz. 32-битный Arch.

Надо бы на Core i5 проверить, да...

Deleted
()
Ответ на: комментарий от King_Carlo

Еще один тестовый набор на том же железе:

=> clang-O2        primes              0.03 s,    1480 KB,    44266299 Refs
=> gcc-O2          primes              0.03 s,    1484 KB,    44607130 Refs
=> gcc-O0          primes              0.04 s,    1480 KB,    57732986 Refs
=> clang-O0        primes              0.04 s,    1480 KB,    68600594 Refs
=> tcc             primes              0.04 s,    1484 KB,    79894185 Refs
=> nwcc            primes              0.04 s,    1488 KB,    92939429 Refs
=> luajit          primes              0.07 s,    2160 KB,   198219953 Refs
=> neko            primes              0.24 s,    7004 KB,           - Refs
=> php             primes              0.24 s,   10692 KB,   769834076 Refs
=> pypy            primes              0.45 s,   61316 KB,   885444477 Refs
=> lua             primes              0.47 s,    2324 KB,  1406182305 Refs
=> nodejs          primes              0.68 s,   26256 KB,  1205369345 Refs
=> pike            primes              1.38 s,    6136 KB,  3661687486 Refs
=> ruby            primes              1.38 s,    7328 KB,  4582683509 Refs
=> python2         primes              1.62 s,    5344 KB,  4733703535 Refs

Питонокод:

import math

def is_prime(n):
    if n < 2:
        return False
    elif n < 4:
        return True
    elif n % 2 == 0:
        return False
    elif (n + 1) % 6 != 0 and (n - 1) % 6 != 0:
        return False
    limit = int(math.sqrt(n));
    for i in xrange(3, limit + 1):
        if n % i == 0:
            return False;
    return True;


for n in xrange(0, 200000 + 1):
    if is_prime(n):
        print n

Deleted
()
Ответ на: комментарий от King_Carlo

Всё ж запилю на гитхаб сорцы, интересно собрать статистику с разных железок.

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

Deleted
()
Ответ на: комментарий от Deleted

shoutout

Скатился в нечто неюзабельное.

Deleted
()
Ответ на: комментарий от ZenitharChampion

О, значит туда и надо переползать, хотя я локально это оторвал и в Дебиане.

slapin ★★★★★
()
Ответ на: комментарий от Iron_Bug

Дык очень просто, это происки главного партнёра RedHat. Да и вообще, такое именование - костыль. Этим должно заниматься само ядро. Как оно девайсы в /dev создаёт теперь. Тогда эти костыли будут не нужны.

slapin ★★★★★
()
Ответ на: комментарий от slapin

Они предсказуемые в том смысле, что если ты узнал имя интерфейса на одной железке, оно будет таким же (т.е. предсказуемым) на другой идентичной железке.

А в более широком смысле это, конечно, вранье. Ну то есть, маркетинг. %)

Deleted
()
Ответ на: комментарий от slapin

Этим должно заниматься само ядро. Как оно девайсы в /dev создаёт теперь.

Стоп, поподробнее отсюда. Файл-устройства в /dev создаёт udev, а не ядро.

Deleted
()
Ответ на: комментарий от Deleted

«откусишь с одной стороны гриба...» (С).

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от slapin

Точно.

Блин, уже в третий раз за неделю ЛОР мне напоминает то, что я и так должен бы помнить. Провалы в памяти. Старею, что ли...

Deleted
()

зри в корень - на чем основана новая убунта, на тестовом ядре дебиан, давно наблюдаю такую картину в финале 3.16 eth0, eth1 и тд, а в тестовой версии ядра 4.х изначально enp?s? всякие были, с виду логики никакой - но определенную сетевуху каждый раз называет по старому, сколько бы раз система не переустанавливалась...

amd_amd ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.