The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Создать новую тему
 - Свернуть нити
Пометить прочитанным
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | Архив | Избранное | Мое | Новое | | |  
Форум Разговоры, обсуждение новостей
Повышение производительности Btrfs в ядре Linux 6.17, opennews, 26-Июл-25, 10:17  [ | | | ] [линейный вид] [смотреть все]


Выпуск системной библиотеки Glibc 2.42 и набора утилит GNU Binutils 2.45, opennews, 29-Июл-25, 11:58  [ | | | ] [линейный вид] [смотреть все]


Лидера проекта OpenPrinting уволили из Canonical, opennews, 29-Июл-25, 14:24  [ | | | ] [линейный вид] [смотреть все]


Выпуск SVT-AV1 3.1.0, кодировщика для формата видео AV1 , opennews, 28-Июл-25, 00:11  [ | | | ] [линейный вид] [смотреть все]


В Android встроена возможность запуска графических Linux-приложений, opennews, 25-Июл-25, 09:10  [ | | | ] [линейный вид] [смотреть все]


Релиз ядра Linux 6.16, opennews, 28-Июл-25, 16:51  [ | | | ] [линейный вид] [смотреть все]


NPM-пакет Stylus был по ошибке заблокирован из-за подозрений в наличии вредоносного кода, opennews, 27-Июл-25, 10:27  [ | | | ] [линейный вид] [смотреть все]
  • мотивы ограбления не ясны предположительно, грабитель проводил исследования, с, Аноним (3), 11:54 , 27-Июл-25 (3) +9 [^]
  • Товарищи аминистраторы репозитория NPM, произошла чудовищная ошибка , 1 (??), 12:03 , 27-Июл-25 (4) –1
  • Как от этого спасаться package-lock json , Аноним (5), 12:17 , 27-Июл-25 (5)
    • Если у вас что-то важное, то поднимите свое зеркало пакетов, которые используютс, 1 (??), 12:34 , 27-Июл-25 (8) +2
    • Deno позволяет точечно регулировать праваРазрешить дёргать лишь определённые ком, morphe (?), 17:28 , 27-Июл-25 (30)
      Deno позволяет точечно регулировать права

      Разрешить дёргать лишь определённые команды/пускать только в определённые директории на диске/подключаться к заданному списку доменных имён

      сообщить модератору +/ответить
      • А еще что , Аноним (40), 03:54 , 28-Июл-25 (40)
      • Это на уровне юзерленда ограничения, которые очень легко обойти Настоящая изоля, Аноним (10), 07:07 , 28-Июл-25 (41)
        Это на уровне юзерленда ограничения, которые очень легко обойти. Настоящая изоляция -- это либо линукс-неймспейсы, либо виртуалка.
        сообщить модератору +/ответить
        • Ты их никак не обойдёшь, эти ограничения там стоят поверх всего уровня общения и, morphe (?), 15:31 , 28-Июл-25 (55)
          > Это на уровне юзерленда ограничения, которые очень легко обойти. Настоящая изоляция --
          > это либо линукс-неймспейсы, либо виртуалка.

          Ты их никак не обойдёшь, эти ограничения там стоят поверх всего уровня общения интерпрататора JS с системой

          Неймспейсы и виртуалки это хорошо, но как они защитят тебя от майнера/слива данных из той бд/фс куда процессу нужно ходить, туда куда его хождение не было предусмотрено (сервер злоумышленника)?
          Вот тут как раз только точечные ограничения помогут, будь то opensnitch или вот, ограничения Deno.

          сообщить модератору +/ответить
          • Чувак Если есть возможность вызова подпроцессов, то сетевые ограничения обходят, Аноним (10), 21:09 , 28-Июл-25 (56)
            > поверх всего уровня общения интерпрататора JS с системой

            Чувак. Если есть возможность вызова подпроцессов, то сетевые ограничения обходятся вызовом spawn("curl"), или что там у вас в дено. А если в дено бывают нативные модули (аналог .node-модулей), то движок JS будет не единственным, кто общается с системой. Всегда всё можно обойти, вопрос лишь -- насколько целенаправленно искать. Дено -- это вообще не продакшн-ready история, я вообще вначале думал, что его пишет подросток, а там оказывается аффтар нодежс так и не вырос из штанишек.

            сообщить модератору +/ответить
            • При условии что ты явно разрешишь запускать curlЕсть и node модули, и dlopen, morphe (?), 22:15 , 28-Июл-25 (57) +1
              >> поверх всего уровня общения интерпрататора JS с системой
              > Чувак. Если есть возможность вызова подпроцессов, то сетевые ограничения обходятся вызовом
              > spawn("curl")

              ...При условии что ты явно разрешишь запускать curl

              > А если в дено бывают нативные модули (аналог .node-модулей), то движок JS будет не единственным, кто общается с системой

              Есть и .node модули, и dlopen/dlsym, и собственные нативные модули. Для всех есть whitelistы

              > Дено -- это вообще не продакшн-ready история

              Гоняю deno в продакшене, он обслуживает сотни людей, и я не один такой.
              Правда не в исходном виде, а подключаю его как библиотеку, deno_core

              Это в целом намного более грамотно реализованная обёртка над v8 чем node.js, особенно если говорить о поддержке стандартов (В deno предпочтительным является использование web стандартов, а не node.js стандартной библиотеки, которая много где очень криво устроена)

              сообщить модератору +1 +/ответить
              • В Node js можно передавать буфер в качестве имени файла В дено считается, что и, Аноним (10), 22:53 , 28-Июл-25 (58)
                > node.js стандартной библиотеки, которая много где очень криво устроена

                В Node.js можно передавать буфер в качестве имени файла. В дено считается, что имя файла -- это либо UTF-8-строка, либо URL, конвертирующийся в UTF-8-строку. Про то, что имя файла может содержать невалидные UTF-8-последовательности, аффтар дено не слышал. А в ноде -- слышали. Как итог, если ты хочешь получить список файлов в папке, нода вернет список целиком, а дено вернет только те файлы, у которых имена -- UTF-8-валидные. Этого достаточно, чтобы заявить, что дено -- это лишь игрушка в компьютерном классе средней образовательной школы.

                сообщить модератору +/ответить
                • Да, это так Как я и сказал, в deno ориентируются на web api при проентировании , morphe (?), 03:04 , 29-Июл-25 (60) –1
                  > В дено считается,
                  > что имя файла -- это либо UTF-8-строка, либо URL, конвертирующийся в
                  > UTF-8-строку.

                  Да, это так. Как я и сказал, в deno ориентируются на web api при проентировании своих интерфейсов, а потому названия файлов должны быть валидными URL
                  Я бы не сказал что это недостаток, у deno просто несколько иные цели.
                  В Deno ты например можешь аналогично браузеру читать файлы в одной директории со скриптом через await fetch(new URL('file.txt', import.meta.url)). Так нельзя было бы поступать, если бы deno считал за валидные имена файлов что-то не URL-совместимое

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

                  Однако deno также поддерживает node.js api, и через node.js api Buffer принимается, и невалидный utf8 обрабатывается аналогично ноде (т.е можно передать encoding функциям производящим пути. Deno однако я так понял только binary и utf-8 тут поддерживает, но если кому надо чот большее - поддержка nodejs api в Deno развивается и улучшается).

                  сообщить модератору –1 +/ответить
                • BTW, просто интересно, как часто и где ты сталкиваешься с именами файлов что не , morphe (?), 03:10 , 29-Июл-25 (61)
                  BTW, просто интересно, как часто и где ты сталкиваешься с именами файлов что не utf-8 совместимые, и при этом с ними надо работать из JS?
                  Звучит как очень странный кейс для не системного ЯП
                  сообщить модератору +/ответить
                  • Речь не о том, как часто Речь о том, что стандартная библиотека языка врет В п, Аноним (10), 07:59 , 29-Июл-25 (63)
                    > как часто и где ты сталкиваешься с именами файлов что не utf-8 совместимые

                    Речь не о том, как часто. Речь о том, что стандартная библиотека языка врет. В папке может оказаться сто файлов, а стд библиотека скажет, что файлов там нет. Любой язык, системный или нет, должен давать возможность работать с реальным миром в полной мере. Питон такую возможность дает. Нода -- дает. А дено решил попробовать натянуть сову на глобус со своей концепцией "все есть урл". А это значит, что есть как минимум одно приложение, которое на дено ты написать не сможешь никогда: файловый менеджер вроде ls, exa, nnn, mc, ranger, да даже веб-сервис типа cockpit, в котором есть веб-версия файлового менеджера. Это разве "системные утилиты"? Нет, не системные, вполне юзерленд, вполне высокоуровневые. А на дено их принципиально не реализовать, потому что стд библиотека врет.

                    > Было бы хуже если бы его апи поддерживали одновременно URL и Buffer TBH, потому что в этом случае потребовалось бы вводить непонятно работающие конверсии между этим всем

                    Я тебе даже больше скажу: console.log(filenameAsString) может тебе испортить консоль UTF-8-корректными ANSI-последовательностями. Следовательно, у тебя уже как минимум должны быть две строки: реальное имя файла и имя файла, где ANSI-последовательности заэкранированы. Следовательно, как минимум одна конверсия должна быть. А там, где есть одна конверсия, будет и другая: try to convert to utf-8. В нормальных языках это понимают. В дено -- нет.

                    tldr: дено плох, потому что его стд библиотека допустила ошибки в самом апи. Имя файла -- это не строка, а буфер. Источник -- сходи в вики, Comparison of file systems.

                    сообщить модератору +/ответить
                    • Опять же, апи там соответствует спеке wintertc webapi, там имя файла - urlНадо б, morphe (?), 16:52 , 29-Июл-25 (64) –1
                      > tldr: дено плох, потому что его стд библиотека допустила ошибки в самом апи. Имя файла -- это не строка, а буфер. Источник -- сходи в вики, Comparison of file systems.

                      Опять же, апи там соответствует спеке wintertc/webapi, там имя файла - url
                      Надо большее - node.js api в дено реализованы, можешь использовать их

                      > Следовательно, как минимум одна конверсия должна быть. А там, где есть одна конверсия, будет и другая: try to convert to utf-8. В нормальных языках это понимают

                      Как раз таки конверсия в utf8 обычных путей это неверно, и в нормальных языках (Rust) это понимают, и для путей заводят отдельный тип - Path, который и не строка, и не массив байт

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

                      Опять же nodejs по дефолту тебе тоже ломает пути, потому что для правильного перечисления файлов в директории например нужно передавать {encoding: "binary"}

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

                      Кроме того это ещё не идёт речи про не-utf8 системные кодировки, где у тебя конверсия в utf8 будет lossy, и при roundtrip у тебя может получиться не исходный путь (e.g utf16 в винде)

                      Винда в этом плане ещё смешнее, потому что в зависимости от системной кодировки, ты через posix api не ко всем файлам можешь обращаться, надо либо конвертировать нормальный путь в short string "file-с-русскими-буквами-в-имени" => "FILE~1", либо использовать wstr варианты всех апи, которые явно принимают utf-16
                      Perl там тоже может не работать по той же причине, надо использовать Win32::Unicode::Dir->new
                      И таких приколов тут миллиард

                      В этом плане deno сэкономил кучу стрельбы себе в ноги, и с его стороны представление ФС вполне себе консистентное - он не видит ровно те файлы, которые через своё апи не позволяет создать

                      сообщить модератору –1 +/ответить
                      • Если прога исполняется не внутри песочницы браузера, вебапи тупо неприменим Это, Аноним (10), 17:43 , 29-Июл-25 (65)
                        > апи там соответствует спеке wintertc/webapi

                        Если прога исполняется не внутри песочницы браузера, вебапи тупо неприменим. Это и есть то самое натягивание совы на глобус. Со своим уставом в чужую церковь, как говорится. У тебя есть файловая система, и есть дено, которая с этой файловой системой работать _не умеет_. Ну и нахрена такая дено?

                        > для путей заводят отдельный тип - Path

                        Снова неверно. Path -- это просто обертка над массивом байт, предоставляющая более-менее удобный апи для работы с путями. А внутри все тот же массив байт.

                        > nodejs по дефолту тебе тоже ломает пути

                        Сделано видимо для совместимости с совсем уж древней нодой, в которой аффтар дено допустил ровно ту же ошибку. Потом за аффтаром прибирались, добавив binary. Н - Необучаемость.

                        > теперь вопрос - как много приложений это обрабатывают и не падают?

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

                        > Кроме того это ещё не идёт речи про не-utf8 системные кодировки, где у тебя конверсия в utf8 будет lossy, и при roundtrip у тебя может получиться не исходный путь (e.g utf16 в винде)

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

                        В GLib совсем уж шикарное апи: они различают name, display name, edit name и copy name. Название, которое годится для вывода в UI, может содержать в скобках " (неверная кодировка)" в конце имени. Именно это значение ты увидишь в гуе наутилуса. В дено тем временем делают вид, что кодировка всегда верна.

                        > он не видит ровно те файлы, которые через своё апи не позволяет создать

                        Таким образом ты признаешь, что аффтар дено -- непрофессионал, поскольку профессиональный разраб всегда думает над edge cases. Как ребенку объясняю, ей богу. Если твоя платформа не позволяет создать файл -- то твоя платформа фуфло, и для прода не годится. Если я не могу пролистать список файлов с использованием дено, то такая дено отправляется в shred(1).

                        сообщить модератору +/ответить
                      • [.... слишком большой тред, остальное см. в режиме смотреть все |+ ] (66)!!!
  • Удивительное королевство Не вредоносные банить, вредоносные не банить , Аноним (7), 12:26 , 27-Июл-25 (7) +3
  • Мы словили эту проблему через зависимости nx Добавили оверайд в package json на , Аноним (-), 13:20 , 27-Июл-25 (12) +1
  • тренировка прошла успешно, Аноним (20), 13:56 , 27-Июл-25 (15)
  • После NPM в новости или как там его ещё этого, у питона, сразу понятно, что прои, Tron is Whistling (?), 16:09 , 27-Июл-25 (26)
    После NPM в новости или как там его ещё этого, у питона, сразу понятно, что произошла какая-то феерическая фигня. Судьба у этих репозитариев такая.
    сообщить модератору +/ответить
  • Durilka Как это может быть вредоносным пакетом , Аноним (31), 17:57 , 27-Июл-25 (31) +3
    Durilka? Как это может быть вредоносным пакетом?
    сообщить модератору +3 +/ответить
  • Ну уж лучше так, чем если бы там на самом деле вредонос был и его бы не сразу уд, Саркофандр (?), 19:35 , 27-Июл-25 (33) +2
    Ну уж лучше так, чем если бы там на самом деле вредонос был и его бы не сразу удалили.
    сообщить модератору +2 +/ответить
  • Скрыто модератором, Аноним (51), 20:12 , 27-Июл-25 (34) –2 [---]
    Какой-то васянство... Никто не будет качать себе с репозиториев, поэтому что там сомнительные личности выкладывает сомнительный софт.
    А собирать это уже красноглазие и пердолинг с консолью в обнимку с бубеном.
    Вот по этому и 4 процента дисктопа у Линукс.
    сообщить модератору –2 +/ответить
  • Т е заблокировать автоматом пакет, у которого один из мантейнеров публикует вре, Аноним (49), 10:53 , 28-Июл-25 (49)
    Т.е. заблокировать автоматом пакет, у которого один из мантейнеров публикует вредоносные пакеты - это ошибка?
    сообщить модератору +/ответить


Обновление редактора кода CudaText 1.226.0, opennews, 25-Июл-25, 08:14  [ | | | ] [линейный вид] [смотреть все]


Из Mesa удалена поддержка DRI2, opennews, 13-Июл-25, 11:17  [ | | | ] [линейный вид] [смотреть все]


Первый выпуск Wayback, прослойки для запуска рабочих столов X11, используя компоненты Wayland, opennews, 24-Июл-25, 13:20  [ | | | ] [линейный вид] [смотреть все]


Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей SIGHUP всем процессам, opennews, 27-Июл-25, 08:07  [ | | | ] [линейный вид] [смотреть все]


Представлены правила для AI-ассистентов, применяемых при разработке ядра Linux, opennews, 26-Июл-25, 12:04  [ | | | ] [линейный вид] [смотреть все]


Выпуск дистрибутива Slackel 8.0, opennews, 27-Июл-25, 07:49  [ | | | ] [линейный вид] [смотреть все]


Google представил проект OSS Rebuild для выявления скрытых изменений в пакетах, opennews, 22-Июл-25, 09:52  [ | | | ] [линейный вид] [смотреть все]
  • Но OSS - это же open sound system , Аноним (1), 09:52 , 22-Июл-25 (1) +2
  • Не мог бы Xz написан на Си, а OSS не поддерживает его аудит , Аноним (3), 09:55 , 22-Июл-25 (3) +14 [^]
  • Полезная вещь Особенно для npm В идеале это должны реализовывать сами репозито, Аноним (138), 10:27 , 22-Июл-25 (6)
  • И что в итоге то проверяется Даже crates io с компилируемым Rust хранятся тольк, Аноним (11), 11:02 , 22-Июл-25 (11) +2
    • Так там не только бинарники тестируют Ещё и самые частые векторы атак У питона, Аноним (138), 11:09 , 22-Июл-25 (13)
    • аналитика как она есть, Аноним (49), 12:06 , 22-Июл-25 (18)
      • веб-синьоры как они есть, 12yoexpert (ok), 13:59 , 22-Июл-25 (25)
      • Просто сейчас появилось огромное количество случайных войтивойтишников Их даже , Аноним (27), 16:36 , 22-Июл-25 (27)
        • Это как-то отменяет тот факт, что Питон 8212 интерпретируемый язык , Аноним (115), 19:02 , 22-Июл-25 (35) +3
          • Интерпретируемой или компилируемой может быть реализация языка Язык может быть и, Аноним (43), 20:33 , 22-Июл-25 (43) –4 [V]
            Интерпретируемой или компилируемой может быть реализация языка.
            Язык может быть и тем и другим.

            Компиляция не означает преобразование в машинный код. Нельзя путать её с компилятором. Есть разные языки, которые компилируются в другие языки.
            Пример: dart -> js, ts -> ts, vala -> c и т.п.

            Преобразованием в любой другой код занимается трансляция.

            Что там компилируется перед интерпретацией?
            Компилируется питон.
            А что там интерпретируется?
            Интерпретируется байт-код, а питона уже нет.

            С чего бы тогда питону быть интерпретируемым, если от питона к моменту интерпретации ничего не осталось?

            И как бы наличие компиляции до интерпретации уже говорит, что питон не интерпретируемый язык. Как и наличие кучи компиляторов для python.

            сообщить модератору –4 +/ответить
        • говори себе это почаще, глядишь, и питон перестанет быть интерпретируемым языком, 12yoexpert (ok), 19:13 , 22-Июл-25 (38) –1
          > уже скомпилированный байт-код

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

          сообщить модератору –1 +/ответить
        • Он интерпретирует промежуточный не выполняемый аппаратным процессором код, то , Аноним (41), 14:26 , 23-Июл-25 (53)
          >вошедшие учат, что питон - интерпретируемый язык.

          Он интерпретирует промежуточный (не выполняемый аппаратным процессором) код, то есть ои интерпретатор. Читайте типы интерпретаторов.
          https://ru.wikipedia.org/wiki/%D0%98%D0%...

          сообщить модератору +/ответить
          • Так этот код уже не исходник на питоне Это байт-код среды выполнения Среда вып, Аноним (54), 00:20 , 24-Июл-25 (54)
            > Он интерпретирует промежуточный (не выполняемый аппаратным процессором) код, то есть ои
            > интерпретатор. Читайте типы интерпретаторов.
            > https://ru.wikipedia.org/wiki/%D0%98%D0%...

            Так этот код уже не исходник на питоне. Это байт-код среды выполнения. Среда выполнения не выполняет инструкции языка Python.

            Если ты интерпретируешь не питон, то интерпретируемым является не питон. Логично?
            Интерпретируемым в данном случае является язык байт-код - машинный язык виртуальной машины PVM, но не исходный код на языке Python.

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

            Кстати, а Java у вас тоже интерпретируемый язык?
            Или она компилируемая, хотя там выполняется всё тот же (промежуточный, не выполняемый аппаратным процессором) байт-код в виртуальной среде выполнения? Если она всё же - интерпретируемый язык, то что значит буква c в слове javac.
            А если она компилируемая, то почему питон интерпретируемый, если его интерпретация работает аналогично Java и есть та же буква в .pyc?

            Для Си тоже интерпретаторы пишут.

            Машинный код тоже интерпретируется процессором.

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

            А что в питоне происходит? Как раз анализируется и транслируется весь текст. Не построчно, а целиком.

            А что касается выполнения? Анализируется питоновская инструкция, или инструкция байт-кода?

            Вот поэтому придумали всякую ересь вроде интерпретаторов компилирующего типа, компиляторов интерпретирующего типа.
            Но это как раз и говорит о том, что язык не является ограниченным в одном типе.
            Поэтому питон не является интерпретируемым языком.
            Что касается реализации Питона, то она указывает на то, что он является компилируемым.

            Далее читаем:
            > Алгоритм работы простого интерпретатора:
            > 1. прочитать инструкцию;

            Интерпретатор Питона должен читать инструкцию на Питоне, чтобы интерпретировать язык Питон.
            Но PVM читает инструкцию уже на байт-коде. Байт-код это не Питон, это такой машинный код для виртуальной среды исполнения. Можете считать её упрощённым процессом-виртуальным процессором.

            И кому-то захотелось в статье сделать питон каким-то ограниченным языком, поэтому он добавил условие - "без выполнения"? Без выполнения чего? Инструкции чьей?

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

            А это определение в вики объявляет интерпретируемой только среду исполнения, поскольку команда запуска виртуальной машины (как и её прерывание) и передача на её виртуальный конвейер инструкций байт-кода могут быть выполнены лишь на её уровне. К языку непосредственно оно никакого отношения не имеет.

            Ну, я согласен, что интерпретатор питона является интерпретатором :), но причём тут питон, если произошла трансляция в другую форму?

            Автор статьи сам до конца не понимает, чем компиляция, интерпретация и трансляция отличаются друг от друга.

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

            С Питоном работает компилятор, интерпретатор Питона уже не видит. Но интерпретируемый - Питон. Замечательная логика.

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

            Ещё лучше. Мы будем анализировать и выполнять левый язык, в который сумели транслироваться, но будем называться интерпретатором того языка из которого транслировались путём компиляции.

            А чего ещё ждать в наше время. Перевернуть определения и подменить понятия - характерная черта современности.

            Хотите увидеть как работает настоящий интерпретатор? Типа "простой интерпретатор".
            Тогда скачайте его и проверьте как там анализируется одна строка кода и её параметры передаются подпрограмме (никогда не меняющейся). Меняются только данные в памяти, но не подпрограммы связанные с ключевыми словами языков, подпрограммам передаются адреса переменных. И, конечно же, там нет никакой компиляции.

            Скачайте, хоть Бейсик, хоть Фокал, или поставьте эмулятор старого бытового компьютера с прошитым в ПЗУ интерпретатором. Что угодно. А потом отладчиком пройдитесь.
            Только не называйте тормозной интерпретатор недоассемблера интерпретатором питона.

            "промежуточный (не выполняемый аппаратным процессором) код" кодом Питона не является.
            Допустим, ваш компилятор переводит Питон-код не в байт-код, а в си++ (чтобы было понятней, что он промежуточный и не выполняется), для аналогичной машины содержащей процедуры машинного кода, связанные с ключевыми словами си++, без компиляции. Он интерпретировался? Ещё нет. Только скомпилировался. Далее машина будет интерпретировать C++-код построчно. От этого C++ станет интерпретируемым языком? Или языки всё же не должны делиться жёстко на эти два типа?

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

            Не нравится c++, возьмите basic, pascal, c#...

            Никогда интерпретация не зависела от условия запускается ли интерпретатор автоматом после компилятора (даже звучит еретично). Главное условие интерпретации состояло в том - одна строка исходного кода обрабатывается за раз, или весь код сначала переводится в другую форму. В питоне не обрабатывается одна строка, а код переводится в другую форму.

            Вот лучше почитайте вместо википедии:
            https://leanpub.com/insidethepythonvirtualmachine/read#leanp...

            Прямо первое предложение.

            Как видите, на самом деле всё совсем наоборот. И оказывается, питон компилируемый. Только не сам язык, а его реализация. Язык же может быть и тем и другим.

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

            сообщить модератору +/ответить
            • Всё это форма казуистики Есть факт - исполняемый файл Си и полностью компилируе, Аноним (41), 16:18 , 24-Июл-25 (55)
              Всё это форма казуистики. Есть факт - исполняемый файл Си и полностью компилируемых языков ничего не требует. чтобы выполняться на другом компьютере. Исполняемый файл, созданный с помощью Python,  включает интерпретатор Python и все необходимые библиотеки (если вы собирали его правильно). Си на выходе дает нативный машинный код, python в довесок включает виртуальный процессор. Это как игры Unity, если их посмотреть с помощью CE, например, то увидим, что в памяти есть модуль Unity, который интерпретирует игру написанную разработчиками (она размещается в отдельном регионе памяти).  
              сообщить модератору +/ответить
              • Я как бы про это и говорил Си компилируется для аппаратного процессора И интерп, Аноним (57), 21:29 , 24-Июл-25 (57)
                Я как бы про это и говорил.
                Си компилируется для аппаратного процессора. И интерпретируется им.
                Питон компилируется для программного недопроцессора. И интерпретируется им.
                А вот при реализации настоящего интерпретатора исходник не компилируется в другой язык, он передаётся построчно на вход интерпретатора. Передал строку, выполнил, передал следующую, выполнил. Иначе это не интерпретатор.

                C-код (весь) -> машинный код (инструкция) -> аппаратный процессор (быстрый интерпретатор)
                Python-код (весь) -> байт-код (инструкция) -> PVM (тормозной интерпретатор) -> аппаратный процессор (быстрый интерпретатор)

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

                А вот как в обычном интерпретаторе:

                Basic-код (строка) -> Basic (тормозной интерпретатор) -> аппаратный процессор (быстрый интерпретатор).
                Перевода исходника на другой язык не происходит.

                Убираем аппаратный процессор, видим разницу между тормозами в обычном интерпретаторе, и в питоне.
                В Basic тормозит интерпретатор Basic, (тут всё сошлось)
                в Python тормозит интерпретатор байт-кода (а тут какая-то несостыковочка).

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

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

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

                Здесь простой выбор: либо быстро и удобно писать софт и надёжно и медленно работать (относительно, а с JIT так вообще не всем об этом надо думать), либо мучительно и долго разрабатывать надёжные и быстрые программы (тоже относительно, современные не динамические языки позволяют вполне удобно и быстро разрабатывать код).

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

                В принципе, в Nuitka поэтому и сделали трансляцию в си, чтобы заниматься только этими сложностями. Кто-нибудь пробовал насколько хорошо оно работает? Наверное не очень, раз народ делает исполняемые файлы с вшитым интерпретатором.

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

                Вот такая вот интерпретация в якобы Питоне, с двойной компиляцией.
                Отсюда и понятия типа компилирующего интерпретатора, который в реальности работает не с Питоном.

                > Всё это форма казуистики.

                Это такая же казуистика как "wine - не эмулятор".
                Wine эмулирует поведение винды для работы виндовых программ. С точки зрения обычного пользователя это самый натуральный эмулятор. А попробуй на опеннете забыть, что под капотом трансляция API, тебя тут же заминусуют. :)

                Вот и получается, что люди видят, что "питон интерпретирует свой код в интерпретаторе", но под капотом интерпретируется не питон, а интерпретатор по факту выполняет двойную компиляцию и исходного кода на питоне в глаза не видел.

                Так любой отладчик работает как интерпретатор.
                Мне что, теперь ассемблеры с сишками называть интерпретируемыми, только потому, что нашлась программа, которая позволяет выполнить язык построчно? :)

                Так и запишем: gdb - интерпретатор всех языков программирования, включая компилируемые и машинные.
                А что, неплохо. Инструкции выполнил, результат показал. Однозначно, интерпретатор.

                Трассировщики с дизассемблерами тоже к интерпретаторам отнесём? Ну конечно, пошагово же работают.

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

                Ну тогда и незачем сыр-бор разводить по поводу терминологии. Она не нужна.

                (смекалочка.jpg):
                Когда язык компилируют, он компилируемый. Когда язык интерпретируют, он интерпретируемый. С языком можно делать и то и другое.

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

                Казуистикой я бы посчитал компилирующий интерпретатор. Вы уж определитесь там.

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

                сообщить модератору +/ответить
    • Даже crates iohttps www opennet ru opennews art shtml num 59656, Аноним (26), 14:32 , 22-Июл-25 (26)
  • Где то я такое уже видел, Аноним (20), 12:19 , 22-Июл-25 (20) –1
  • Вот, а некоторые ещё тут пытаются троллить гентушников , Аноним (30), 18:34 , 22-Июл-25 (34) +1
  • Ого, ADinf изобрели , pda (ok), 19:40 , 22-Июл-25 (39) +1
    Ого, ADinf изобрели... :)
    сообщить модератору +1 +/ответить
  • а мд5 пакета хранить рядом с файлом если , ятупойтролль (ok), 21:46 , 22-Июл-25 (45)
    а мд5 пакета хранить рядом с файлом если?
    сообщить модератору +/ответить
  • Надеюсь это не для того, чтобы формально снять вопрос соответствия исходникам Т, Аноним (41), 14:06 , 23-Июл-25 (51)
    Надеюсь это не для того, чтобы формально снять вопрос соответствия исходникам. Типа, спите спокойно, качайте не глядя - всё контролируется нами.  ))
    сообщить модератору +/ответить


В AUR-репозитории Arch Linux выявлены вредоносные пакеты, opennews, 19-Июл-25, 09:33  [ | | | ] [линейный вид] [смотреть все]


Выпуск дистрибутива для создания межсетевых экранов OPNsense 25.7, opennews, 24-Июл-25, 12:43  [ | | | ] [линейный вид] [смотреть все]


Инициатива Maintenance Fee, предлагающая взимать плату за доступ к релизам открытых проектов, opennews, 25-Июл-25, 12:22  [ | | | ] [линейный вид] [смотреть все]


Каталог PyPI убрал блокировку регистрации с email-адресов inbox.ru, opennews, 25-Июл-25, 21:45  [ | | | ] [линейный вид] [смотреть все]


Релиз Firefox 141, opennews, 22-Июл-25, 20:05  [ | | | ] [линейный вид] [смотреть все]


Выпуск СУБД MySQL 9.4.0, opennews, 23-Июл-25, 07:46  [ | | | ] [линейный вид] [смотреть все]


Выпуск дистрибутива Альт Виртуализация 11.0, opennews, 11-Июл-25, 22:03  [ | | | ] [линейный вид] [смотреть все]


Выпуск Cozystack 0.33, открытой PaaS-платформы на базе Kubernetes, opennews, 17-Июл-25, 11:06  [ | | | ] [линейный вид] [смотреть все]


KDE перешёл на отрисовку окон со скруглёнными углами, opennews, 19-Июл-25, 11:50  [ | | | ] [линейный вид] [смотреть все]


В Fedora предложено задействовать FlatHub в атомарных редакциях дистрибутива, opennews, 23-Июл-25, 12:13  [ | | | ] [линейный вид] [смотреть все]


Проект XLibre интегрирует драйверы в основную ветку X-сервера, opennews, 23-Июл-25, 21:16  [ | | | ] [линейный вид] [смотреть все]


В http-сервере Apache 2.4.65 устранена проблема, ломающая работу mod_rewrite, opennews, 24-Июл-25, 11:16  [ | | | ] [линейный вид] [смотреть все]


GPUHammer - вариант атаки Rowhammer на память GPU, opennews, 14-Июл-25, 11:07  [ | | | ] [линейный вид] [смотреть все]


Выпуск игрового движка Open 3D Engine 25.05, открытого компанией Amazon, opennews, 19-Июн-25, 17:42  [ | | | ] [линейный вид] [смотреть все]


Выпуск дистрибутива Tails 6.18, opennews, 26-Июл-25, 00:14  [ | | | ] [линейный вид] [смотреть все]
В октябре в Переславле-Залесском состоится конференция разработчиков свободных программ, opennews, 03-Июл-25, 07:20  [ | | | ] [линейный вид] [смотреть все]


 
Пометить прочитанным Создать тему
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | Архив | Избранное | Мое | Новое | | |



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру